Setiap aplikasi yang anda cipta dengan aplikasi desktop WebCatalog sebelum ini menggunakan sekitar 320 MB ruang cakera pada macOS. Itu bukan sesuatu yang luar biasa bagi aplikasi berasaskan Electron, tetapi WebCatalog direka untuk orang yang menggunakan banyak aplikasi web sebagai aplikasi desktop. Pasang sepuluh aplikasi dan semuanya boleh menggunakan lebih daripada 3 GB, walaupun kebanyakan data dalam aplikasi tersebut sebenarnya sama.
Baru-baru ini, kami mengubah cara aplikasi desktop WebCatalog membina aplikasi pada macOS. Aplikasi pertama kini menggunakan sekitar 340 MB ruang cakera fizikal, termasuk salinan enjin aplikasi yang telah disediakan dan disimpan secara setempat. Selepas itu, setiap aplikasi tambahan biasanya menambah hanya 1–2 MB penggunaan cakera sebenar. Dalam ujian kami, penggunaan ruang bagi sepuluh aplikasi turun daripada lebih 3 GB kepada sekitar 360 MB.
Kami melakukannya dengan menggunakan ciri yang sedia ada dalam macOS: klon APFS. Bahagian yang menarik bukan sekadar mengklon fail. Cabarannya ialah memastikan pengklonan berfungsi sambil mengekalkan kebebasan setiap aplikasi, memastikan setiap aplikasi ditandatangani kod dengan betul, dan mengekalkan fungsi yang setara dengan aplikasi yang dibina melalui proses lama.
Mengapa setiap aplikasi menggunakan 320 MB lagi
Aplikasi desktop WebCatalog menukar laman web menjadi aplikasi desktop kendiri. Setiap aplikasi yang anda cipta berjalan pada Photon, enjin aplikasi kami yang dibina berasaskan Electron. Pada macOS, setiap satunya ialah berkas .app biasa yang mengandungi Electron (Chromium dan Node.js), Photon, serta fail khusus untuk aplikasi tersebut.
Ambil dua aplikasi sebagai contoh, Slack dan Discord. Nama, ikon, pengecam berkas dan konfigurasi kedua-duanya berbeza, tetapi rangka kerja Electron yang besar dan sebahagian besar Photon adalah sama.
Sehingga kini, setiap aplikasi dibina sebagai salinan yang berasingan sepenuhnya.
Slack.app
Electron
Photon
Fail khusus Slack
Discord.app
Electron
Photon
Fail khusus Discord
Rangka kerja Electron dan Photon mungkin sama sepenuhnya hingga ke setiap bait dalam kedua-dua aplikasi, tetapi macOS tetap menyimpan satu lagi salinan fizikal bagi setiap aplikasi. Oleh itu, sepuluh aplikasi bermakna kira-kira sepuluh salinan berkas aplikasi 320 MB yang hampir sama.
Namun, seni bina itu mempunyai satu ciri yang ingin kami kekalkan: setiap aplikasi bebas sepenuhnya. Memadam satu aplikasi tidak akan menjejaskan aplikasi lain, dan aplikasi yang dipasang tidak bergantung pada aplikasi desktop WebCatalog untuk terus wujud dalam sistem.
Apa yang ingin kami hapuskan ialah pertindihan data yang tidak perlu di sebalik aplikasi-aplikasi tersebut.
APFS sudah menyediakan asas yang kami perlukan
Mac moden menggunakan sistem fail APFS Apple. APFS menyokong pengklonan, iaitu mekanisme salin semasa tulis yang membolehkan dua fail bebas berkongsi data fizikal yang sama sehingga salah satu daripadanya berubah.
Bayangkan anda menyalin fail 300 MB. Dengan salinan biasa, macOS menulis 300 MB lagi ke cakera, jadi kedua-dua fail menggunakan sekitar 600 MB secara keseluruhan.
Dengan klon APFS, fail baharu masih kelihatan dan berfungsi seperti fail 300 MB yang lengkap, tetapi pada mulanya ia merujuk kepada blok fizikal yang sama seperti fail asal.
Fail A ────┐
├── blok fizikal yang dikongsi
Fail B ────┘
Jika sebahagian daripada Fail B berubah kemudian, APFS menulis blok baharu hanya untuk data yang berubah. Semua data yang kekal sama boleh terus berkongsi blok asal.
Fail A ───────── blok yang dikongsi
Fail B ───────── blok yang dikongsi
└──────── blok yang berubah
Dari sudut pandang aplikasi, Fail A dan Fail B ialah fail yang berasingan. Dari sudut pandang SSD, data yang sama hanya perlu disimpan sekali.
Itulah hampir tepat tingkah laku yang kami perlukan.
Membina aplikasi daripada asas yang sama
Aplikasi desktop WebCatalog kini menyediakan satu asas bagi setiap gabungan versi Electron dan Photon. Aplikasi asas Photon mengandungi bahagian yang sama merentas aplikasi, termasuk Electron, Photon, struktur rangka kerja dan tandatangan yang dikongsi.
Apabila aplikasi desktop mencipta aplikasi lain menggunakan versi yang sama, ia tidak lagi mengekstrak dan membina satu lagi salinan lengkap dari awal. Sebaliknya, ia mencipta klon APFS daripada aplikasi asas Photon dan menyesuaikan hanya bahagian yang perlu berbeza.
Bahagian tersebut termasuk nama aplikasi, ikon, pengecam berkas, tetapan, nama fail boleh laksana, pengecam binaan dan metadata lain yang khusus untuk aplikasi.
Oleh sebab kebanyakan kandungan berkas tidak berubah, APFS terus berkongsi blok fizikal yang mengandungi Electron dan Photon. Hanya sejumlah kecil data khusus aplikasi menggunakan ruang baharu.
Mengapa tidak berkongsi Electron sahaja?
Pendekatan yang lebih jelas ialah memasang Electron sekali dan membuat setiap aplikasi merujuk kepadanya.
Kami mempertimbangkannya, tetapi tindakan itu akan mengubah model kebolehpercayaan secara asas. Jika pemasangan Electron yang dikongsi hilang, setiap aplikasi yang bergantung padanya mungkin berhenti berfungsi. Alat pembersih cache boleh membuangnya, menyahpasang aplikasi desktop WebCatalog boleh membuangnya, dan memindahkan atau memulihkan aplikasi secara individu akan menjadi lebih rumit.
Pendekatan itu juga memerlukan kami menjejak aplikasi terpasang yang bergantung pada setiap versi persekitaran masa jalan supaya versi lama boleh dibersihkan dengan selamat.
Penandatanganan kod macOS menimbulkan satu lagi masalah. Pengesahan tandatangan yang ketat menolak pautan simbolik yang menunjuk ke luar berkas aplikasi.
Klon APFS memberikan manfaat perkongsian tanpa mewujudkan kebergantungan tersebut. Aplikasi yang dipasang boleh berkongsi blok cakera fizikal sambil kekal sebagai berkas aplikasi yang lengkap dan bebas.
Memadam aplikasi asas Photon tidak akan merosakkan aplikasi yang dicipta daripadanya. Memadam satu aplikasi yang dipasang tidak akan menjejaskan aplikasi lain. Sistem fail mengendalikan perkongsian itu sementara seni bina aplikasi kekal bebas.
Penandatanganan kod hampir menghapuskan penjimatan
Mengklon aplikasi hanyalah sebahagian daripada cabarannya. Aplikasi macOS juga perlu ditandatangani kod.
Aliran kerja binaan lama kami menandatangani semula setiap berkas aplikasi secara menyeluruh selepas penyesuaian. Untuk salinan biasa, itu tidak menjadi masalah. Namun, dengan storan salin semasa tulis, mengubah binari yang besar boleh menyebabkan APFS memperuntukkan blok fizikal baharu untuknya.
Semasa pembangunan, kami mendapati bahawa menandatangani semula rangka kerja Electron menambah kira-kira 194 MB storan fizikal bagi setiap aplikasi. Kami berjaya mengelakkan penyalinan Electron semasa penciptaan aplikasi, tetapi kemudian menduplikasi sebahagian besarnya semula ketika penandatanganan.
Jadi, proses penandatanganan juga perlu diubah.
Rangka kerja besar yang dikongsi kini ditandatangani sebagai sebahagian daripada aplikasi asas Photon. Apabila aplikasi desktop mengklon asas tersebut, kami mengelakkan pengubahsuaian binari besar yang dikongsi itu dan menandatangani semula hanya bahagian lebih kecil yang sememangnya perlu berbeza antara aplikasi.
Setelah aplikasi siap, kami menjalankan pengesahan tandatangan yang ketat terhadap berkas akhir untuk memastikan semuanya kekal sah.
Dengan cara ini, kami dapat mengekalkan jaminan penandatanganan kod macOS serta penjimatan storan daripada APFS.
Apabila permintaan pengklonan melalui Node.js sebenarnya tidak menghasilkan klon
Terdapat satu lagi masalah yang tidak dijangka: menjalankan pengklonan itu sendiri.
Node.js menyediakan bendera penyalinan yang bertujuan meminta tingkah laku salin semasa tulis, termasuk COPYFILE_FICLONE dan COPYFILE_FICLONE_FORCE. Secara teori, kedua-duanya kedengaran seperti API yang tepat untuk keperluan kami.
Dalam ujian kami pada Node.js 24, kami menyalin aplikasi Electron 288 MB yang sama menggunakan beberapa kaedah dan mengukur jumlah ruang cakera fizikal tambahan 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-dua mod pengklonan Node.js masih menghasilkan salinan fizikal penuh dalam ujian kami, malah varian FORCE tidak melaporkan ralat apabila pengklonan yang dijangka tidak berlaku.
Operasi asli macOS cp -c berfungsi seperti yang dijangka, jadi aplikasi desktop WebCatalog menggunakan mekanisme itu secara langsung.
Ini juga mengingatkan kami bahawa pengoptimuman sistem fail harus disahkan dengan mengukur sistem fail itu sendiri. Memanggil API yang meminta salin semasa tulis tidak semestinya bermakna fail yang terhasil benar-benar berkongsi storan fizikal.
Memastikan pengoptimuman boleh gagal dengan selamat
Menjimatkan ruang cakera ialah satu pengoptimuman. Kejayaan pemasangan aplikasi pula bukan sesuatu yang boleh dikompromikan.
Kami mereka bentuk aliran kerja baharu supaya pengklonan boleh gagal tanpa menggagalkan pemasangan aplikasi. Jika penyediaan aplikasi asas Photon gagal, jika asas yang dicache rosak, jika pengklonan gagal, atau jika pengesahan tandatangan tidak lulus, aplikasi desktop akan kembali menggunakan proses binaan terdahulu dengan pengekstrakan penuh dan penandatanganan penuh.
Oleh itu, keadaan paling buruk ialah penggunaan cakera yang sama seperti dahulu, bukannya pemasangan yang gagal.
Kami juga perlu mengambil kira proses yang berjalan serentak. Aplikasi asas Photon mula-mula disediakan dalam direktori sementara dan hanya dipindahkan ke lokasi akhirnya setelah lengkap. Dengan cara itu, dua proses binaan aplikasi yang berlaku serentak tidak akan tersilap menggunakan asas yang baru separuh siap.
Asas lama juga boleh dibuang dengan selamat. Klon APFS yang telah dipasang tidak bergantung pada asas asal untuk terus wujud. Jika asas itu dipadam, klon tersebut mengekalkan blok fizikal yang masih digunakannya.
Kaedah ini berfungsi pada APFS, sistem fail lalai pada setiap Mac moden. Jika aplikasi anda berada pada cakera yang tidak menyokong pengklonan, seperti pemacu luaran HFS+ atau exFAT, aplikasi desktop WebCatalog akan kembali menggunakan salinan biasa. Jadi, aplikasi berfungsi seperti dahulu tetapi tidak menjimatkan ruang. Windows dan Linux tidak berubah buat masa ini.
Saiz logik dan saiz fizikal bukan perkara yang sama
Satu kesan sampingan yang mungkin sedikit mengelirukan ialah Finder masih boleh melaporkan saiz setiap aplikasi sekitar 320 MB.
Angka itu mewakili saiz logik aplikasi. Aplikasi tersebut sememangnya mengandungi fail berjumlah kira-kira 320 MB, dan jika fail itu disalin ke tempat lain tanpa pengklonan, lebih kurang sebanyak itulah data yang perlu ditulis.
Apa yang berubah ialah saiz fizikal, iaitu jumlah blok unik yang sebenarnya digunakan oleh fail tersebut pada cakera.
Jika dua aplikasi mengandungi rangka kerja 300 MB yang sama dan APFS membenarkan kedua-duanya berkongsi blok asas yang sama, setiap aplikasi boleh mengandungi 300 MB secara logik, sedangkan aplikasi kedua hampir tidak menambah data fizikal baharu.
Paparan Get Info dalam Finder dan alat seperti du tidak semestinya menunjukkan perkongsian ini. Penjimatan paling jelas dilihat pada jumlah ruang kosong yang sebenarnya masih ada pada cakera.
Kami mengesahkannya dengan tujuh aplikasi sebenar: Discord, Facebook, Instagram, Messenger, TikTok dan dua aplikasi tersuai. Apabila dibina dengan cara ini, aplikasi tersebut menjimatkan sekitar 1.9 GB ruang cakera berbanding proses binaan lama.
Kami juga menyemak ofset cakera fizikal yang mendasarinya dan mengesahkan bahawa aplikasi tersebut berkongsi data Electron dan Photon yang sama pada peringkat blok. Aplikasi yang dicipta menggunakan proses binaan lama tidak berkongsi mana-mana blok tersebut, sekali gus memberikan perbandingan yang berguna.
Hasilnya
Bagi seseorang yang mencipta hanya satu aplikasi dengan aplikasi desktop WebCatalog, perbezaannya kecil. Aplikasi pertama sebenarnya menggunakan sedikit lebih banyak ruang cakera berbanding dahulu kerana aplikasi desktop turut menyimpan aplikasi asas Photon yang digunakan untuk mencipta klon seterusnya.
Selepas itu, manfaatnya meningkat dengan cepat.
Sebelum
1 aplikasi ~320 MB
10 aplikasi >3 GB
Dengan pengklonan APFS:
Selepas
1 aplikasi ~340 MB
10 aplikasi ~360 MB
Selepas asas awal dicipta, setiap aplikasi tambahan biasanya menambah hanya 1–2 MB penggunaan cakera fizikal.
Yang penting, kami mencapai hasil ini tanpa mewujudkan kebergantungan pada persekitaran masa jalan yang dikongsi. Setiap aplikasi kekal sebagai aplikasi macOS biasa yang lengkap dengan sendirinya, sementara APFS menyimpan data Electron dan Photon yang sama hanya sekali. Dengan sekitar sepuluh aplikasi terpasang, penggunaan cakera sebenar boleh berkurang lebih daripada lapan kali ganda.
Ciri ini tersedia dalam versi terkini aplikasi desktop WebCatalog pada macOS. Anda tidak perlu mengaktifkan apa-apa: aplikasi baharu menggunakannya secara automatik, dan aplikasi sedia ada akan mengecil apabila dikemas kini kelak.