Setiap aplikasi yang Anda buat dengan aplikasi desktop WebCatalog sebelumnya menggunakan sekitar 320 MB ruang disk di macOS. Itu bukan hal yang tidak biasa untuk aplikasi berbasis Electron, tetapi WebCatalog dirancang untuk orang-orang yang menggunakan banyak aplikasi web sebagai aplikasi desktop. Jika Anda memasang sepuluh aplikasi, semuanya bisa menghabiskan lebih dari 3 GB, meskipun sebagian besar data di dalam aplikasi tersebut persis sama.
Baru-baru ini, kami mengubah cara aplikasi desktop WebCatalog membangun aplikasi di macOS. Aplikasi pertama kini menggunakan sekitar 340 MB ruang disk fisik, termasuk salinan mesin aplikasi yang telah disiapkan dan disimpan secara lokal. Setelah itu, setiap aplikasi tambahan biasanya hanya menambah 1–2 MB penggunaan disk yang sebenarnya. Dalam pengujian kami, penggunaan ruang untuk sepuluh aplikasi turun dari lebih dari 3 GB menjadi sekitar 360 MB.
Kami melakukannya dengan menggunakan fitur yang sudah tersedia di macOS: klon APFS. Bagian yang menarik bukan sekadar mengkloning berkas, melainkan membuat kloning itu berfungsi sambil menjaga setiap aplikasi tetap independen, ditandatangani dengan benar menggunakan tanda tangan kode, dan setara secara fungsional dengan aplikasi yang dibangun melalui proses lama.
Mengapa setiap aplikasi menggunakan 320 MB lagi
Aplikasi desktop WebCatalog mengubah situs web menjadi aplikasi desktop yang berdiri sendiri. Setiap aplikasi yang Anda buat berjalan di atas Photon, mesin aplikasi kami yang dibangun dengan Electron. Di macOS, masing-masing merupakan bundel .app biasa yang berisi Electron (Chromium dan Node.js), Photon, serta berkas khusus untuk aplikasi tersebut.
Ambil dua aplikasi sebagai contoh, Slack dan Discord. Nama, ikon, pengenal bundel, dan konfigurasinya berbeda, tetapi kerangka kerja Electron yang besar dan sebagian besar Photon identik.
Sebelumnya, setiap aplikasi dibangun sebagai salinan yang sepenuhnya terpisah.
Slack.app
Electron
Photon
Berkas khusus Slack
Discord.app
Electron
Photon
Berkas khusus Discord
Kerangka kerja Electron dan Photon mungkin identik sampai ke setiap byte di kedua aplikasi, tetapi macOS tetap menyimpan salinan fisik tambahan untuk setiap aplikasi. Jadi, sepuluh aplikasi berarti kira-kira sepuluh salinan bundel aplikasi berukuran 320 MB yang hampir sama.
Arsitektur tersebut memang memiliki satu sifat yang ingin kami pertahankan: setiap aplikasi sepenuhnya independen. Menghapus satu aplikasi tidak akan memengaruhi aplikasi lain, dan aplikasi yang terpasang tidak bergantung pada keberadaan aplikasi desktop WebCatalog di sistem.
Yang ingin kami hilangkan adalah duplikasi yang tidak perlu di baliknya.
APFS sudah memiliki mekanisme dasar yang kami butuhkan
Mac modern menggunakan sistem berkas APFS dari Apple. APFS mendukung kloning, mekanisme salin-saat-tulis (copy-on-write) yang memungkinkan dua berkas independen berbagi data fisik yang sama sampai salah satunya berubah.
Bayangkan Anda menyalin berkas berukuran 300 MB. Dengan penyalinan biasa, macOS menulis 300 MB lagi ke disk, sehingga kedua berkas tersebut menggunakan total sekitar 600 MB.
Dengan klon APFS, berkas baru tetap terlihat dan berfungsi seperti berkas lengkap berukuran 300 MB, tetapi pada awalnya mengacu pada blok fisik yang sama dengan berkas aslinya.
Berkas A ──┐
├── blok fisik bersama
Berkas B ──┘
Jika sebagian Berkas B berubah kemudian, APFS menulis blok baru hanya untuk data yang berubah. Semua bagian yang tetap identik dapat terus berbagi blok aslinya.
Berkas A ──────── blok bersama
Berkas B ──────── blok bersama
└─────── blok yang berubah
Dari sudut pandang aplikasi, Berkas A dan Berkas B adalah berkas terpisah. Dari sudut pandang SSD, data yang identik hanya perlu disimpan sekali.
Itulah hampir persis perilaku yang kami butuhkan.
Membangun aplikasi dari basis yang sama
Aplikasi desktop WebCatalog kini menyiapkan basis untuk setiap kombinasi versi Electron dan Photon. Aplikasi dasar Photon berisi bagian-bagian yang identik di berbagai aplikasi, termasuk Electron, Photon, struktur kerangka kerja, dan tanda tangan yang sama.
Saat aplikasi desktop membuat aplikasi lain dengan versi yang sama, aplikasi tersebut tidak lagi mengekstrak dan membangun salinan lengkap dari awal. Sebagai gantinya, aplikasi desktop membuat klon APFS dari aplikasi dasar Photon dan hanya menyesuaikan bagian yang perlu berbeda.
Bagian-bagian itu mencakup nama aplikasi, ikon, pengenal bundel, pengaturan, nama berkas yang dapat dieksekusi, pengenal build, dan metadata lain yang khusus untuk aplikasi tersebut.
Karena sebagian besar bundel tetap tidak berubah, APFS terus berbagi blok fisik yang berisi Electron dan Photon. Hanya sejumlah kecil data khusus aplikasi yang menggunakan ruang baru.
Mengapa tidak berbagi Electron saja?
Pendekatan yang lebih jelas adalah memasang Electron sekali lalu membuat setiap aplikasi merujuk kepadanya.
Kami mempertimbangkan pendekatan itu, tetapi hal tersebut akan mengubah model keandalannya secara mendasar. Jika instalasi Electron bersama itu hilang, setiap aplikasi yang bergantung padanya bisa berhenti berfungsi. Pembersih cache bisa menghapusnya, mencopot pemasangan aplikasi desktop WebCatalog bisa menghapusnya, dan memindahkan atau memulihkan aplikasi secara terpisah akan menjadi lebih rumit.
Pendekatan itu juga mengharuskan kami melacak aplikasi terpasang mana yang bergantung pada versi runtime tertentu agar versi lama dapat dibersihkan dengan aman.
Penandatanganan kode macOS menimbulkan masalah lain. Verifikasi tanda tangan yang ketat menolak symlink yang mengarah ke luar bundel aplikasi.
Klon APFS memberi kami manfaat berbagi tanpa menimbulkan ketergantungan tersebut. Aplikasi yang terpasang dapat berbagi blok disk fisik sambil tetap menjadi bundel aplikasi yang lengkap dan independen.
Menghapus aplikasi dasar Photon tidak merusak aplikasi yang dibuat darinya. Menghapus satu aplikasi yang terpasang tidak memengaruhi aplikasi lain. Sistem berkas menangani pembagian data sementara arsitektur aplikasinya tetap independen.
Penandatanganan kode nyaris menghapus penghematan
Mengkloning aplikasi hanyalah sebagian dari persoalan. Aplikasi macOS juga perlu ditandatangani menggunakan tanda tangan kode.
Pipeline build lama kami menandatangani ulang seluruh bagian bundel aplikasi secara mendalam setelah penyesuaian. Untuk salinan biasa, hal itu tidak menjadi masalah. Namun, dengan penyimpanan salin-saat-tulis, mengubah biner berukuran besar dapat menyebabkan APFS mengalokasikan blok fisik baru untuk biner tersebut.
Selama pengembangan, kami mengukur bahwa penandatanganan ulang kerangka kerja Electron menambah sekitar 194 MB penyimpanan fisik per aplikasi. Kami berhasil menghindari penyalinan Electron saat pembuatan aplikasi, tetapi kemudian menduplikasi sebagian besar datanya lagi saat penandatanganan.
Jadi, proses penandatanganannya juga harus berubah.
Kerangka kerja besar yang dipakai bersama kini ditandatangani sebagai bagian dari aplikasi dasar Photon. Saat aplikasi desktop mengkloning basis tersebut, kami menghindari perubahan pada biner besar yang dibagikan dan hanya menandatangani ulang bagian-bagian lebih kecil yang memang perlu berbeda antar-aplikasi.
Setelah aplikasi selesai dibuat, kami menjalankan verifikasi tanda tangan yang ketat terhadap bundel final untuk memastikan semuanya tetap valid.
Dengan demikian, kami dapat mempertahankan jaminan penandatanganan kode macOS sekaligus penghematan ruang penyimpanan dari APFS.
Ketika permintaan kloning kepada Node.js ternyata tidak benar-benar mengkloning
Ada masalah tak terduga lainnya: melakukan kloning itu sendiri.
Node.js menyediakan flag penyalinan yang dimaksudkan untuk meminta perilaku salin-saat-tulis, termasuk COPYFILE_FICLONE dan COPYFILE_FICLONE_FORCE. Di atas kertas, keduanya terdengar persis seperti API yang kami butuhkan.
Dalam pengujian kami pada Node.js 24, kami menyalin aplikasi Electron berukuran 288 MB yang sama dengan beberapa metode dan mengukur berapa banyak tambahan ruang disk fisik yang digunakan oleh setiap operasi:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Kedua mode kloning Node.js tetap menghasilkan salinan fisik penuh dalam pengujian kami. Bahkan varian FORCE tidak melaporkan kesalahan ketika perilaku kloning yang diharapkan tidak terjadi.
Operasi cp -c bawaan macOS berperilaku sesuai harapan, jadi aplikasi desktop WebCatalog menggunakan mekanisme tersebut secara langsung.
Ini juga menjadi pengingat yang berguna bahwa optimalisasi sistem berkas perlu diverifikasi dengan mengukur sistem berkas itu sendiri. Memanggil API yang meminta mekanisme salin-saat-tulis tidak selalu berarti berkas hasilnya benar-benar berbagi penyimpanan fisik.
Memastikan kegagalan optimalisasi tidak mengganggu pemasangan
Menghemat ruang disk adalah sebuah optimalisasi. Berhasil memasang aplikasi bukanlah sesuatu yang bisa dikompromikan.
Kami merancang pipeline baru agar kegagalan kloning tidak menggagalkan pemasangan aplikasi. Jika penyiapan aplikasi dasar Photon gagal, jika basis dalam cache rusak, jika kloning gagal, atau jika verifikasi tanda tangan tidak lolos, aplikasi desktop akan kembali ke proses build sebelumnya, dengan ekstraksi penuh dan penandatanganan penuh.
Jadi, kemungkinan terburuknya adalah penggunaan ruang disk yang sama seperti sebelumnya, bukan kegagalan pemasangan.
Kami juga harus memperhitungkan proses yang berjalan bersamaan. Aplikasi dasar Photon mula-mula disiapkan di direktori sementara dan baru dipindahkan ke lokasi akhirnya setelah selesai. Dengan demikian, dua proses pembuatan aplikasi yang berlangsung pada saat yang sama tidak akan tanpa sengaja melihat basis yang belum selesai dibangun.
Basis lama pun dapat dihapus dengan aman. Klon APFS yang sudah terpasang tidak bergantung pada keberadaan basis aslinya. Jika basis dihapus, klon tetap mempertahankan blok fisik yang masih digunakannya.
Ini berfungsi pada APFS, sistem berkas bawaan pada setiap Mac modern. Jika aplikasi Anda berada di disk yang tidak mendukung kloning, seperti drive eksternal HFS+ atau exFAT, aplikasi desktop WebCatalog akan kembali menggunakan penyalinan biasa. Jadi, aplikasi tetap berfungsi seperti sebelumnya, tetapi tidak menghemat ruang. Untuk saat ini, Windows dan Linux tidak berubah.
Ukuran logis dan ukuran fisik tidaklah sama
Salah satu efek samping yang mungkin sedikit membingungkan adalah Finder mungkin masih melaporkan ukuran setiap aplikasi sekitar 320 MB.
Angka tersebut menunjukkan ukuran logis aplikasi. Aplikasi itu memang berisi berkas-berkas dengan ukuran total sekitar 320 MB, dan jika berkas-berkas tersebut disalin ke tempat lain tanpa kloning, kira-kira sebanyak itulah data yang perlu ditulis.
Yang berubah adalah ukuran fisik, yaitu jumlah ruang yang benar-benar ditempati oleh blok-blok unik dari berkas tersebut di disk.
Jika dua aplikasi berisi kerangka kerja 300 MB yang sama dan APFS memungkinkan keduanya berbagi blok dasar yang sama, masing-masing aplikasi secara logis dapat berisi 300 MB, sementara aplikasi kedua hampir tidak menambahkan data fisik baru.
Tampilan Dapatkan Info di Finder dan alat seperti du belum tentu memperlihatkan pembagian data ini. Penghematannya paling jelas terlihat dari jumlah ruang kosong yang benar-benar tersisa di disk.
Kami memverifikasi hal ini dengan tujuh aplikasi nyata: Discord, Facebook, Instagram, Messenger, TikTok, dan dua aplikasi kustom. Ketika dibangun dengan cara ini, ketujuh aplikasi tersebut menghemat sekitar 1,9 GB ruang disk dibandingkan dengan proses build lama.
Kami juga memeriksa offset disk fisik yang mendasarinya dan mengonfirmasi bahwa aplikasi-aplikasi tersebut berbagi data Electron dan Photon yang sama pada tingkat blok. Aplikasi yang dibuat dengan proses build lama tidak berbagi satu pun blok tersebut, sehingga menjadi pembanding yang berguna.
Hasilnya
Bagi seseorang yang hanya membuat satu aplikasi dengan aplikasi desktop WebCatalog, perbedaannya kecil. Aplikasi pertama justru menggunakan sedikit lebih banyak ruang disk daripada sebelumnya karena aplikasi desktop juga menyimpan aplikasi dasar Photon yang digunakan untuk membuat klon berikutnya.
Setelah itu, manfaatnya meningkat dengan cepat.
Sebelum
1 aplikasi ~320 MB
10 aplikasi >3 GB
Dengan kloning APFS:
Sesudah
1 aplikasi ~340 MB
10 aplikasi ~360 MB
Setelah basis awal dibuat, setiap aplikasi tambahan biasanya hanya menambah 1–2 MB penggunaan disk fisik.
Yang terpenting, kami mencapai ini tanpa memperkenalkan ketergantungan pada runtime bersama. Setiap aplikasi tetap merupakan aplikasi macOS biasa yang lengkap dan mandiri, sementara APFS hanya menyimpan data Electron dan Photon yang identik sekali saja. Dengan sekitar sepuluh aplikasi terpasang, penggunaan disk yang sebenarnya dapat berkurang lebih dari delapan kali lipat.
Fitur ini tersedia dalam versi terbaru aplikasi desktop WebCatalog di macOS. Anda tidak perlu mengaktifkan apa pun: aplikasi baru menggunakannya secara otomatis, dan aplikasi yang sudah Anda miliki akan menggunakan lebih sedikit ruang saat diperbarui berikutnya.