Každá aplikácia, ktorú ste vytvorili pomocou desktopovej aplikácie WebCatalog, doteraz na macOS zaberala približne 320 MB miesta na disku. Pri aplikácii založenej na Electrone to nie je nič nezvyčajné, no WebCatalog je určený ľuďom, ktorí používajú veľa webových aplikácií ako desktopové aplikácie. Ak ste si ich nainštalovali desať, mohli zaberať viac než 3 GB, hoci väčšina dát v nich bola úplne rovnaká.
Nedávno sme zmenili spôsob, akým desktopová aplikácia WebCatalog vytvára aplikácie na macOS. Prvá aplikácia teraz využíva približne 340 MB fyzického miesta na disku vrátane lokálne uloženej pripravenej kópie aplikačného jadra. Každá ďalšia aplikácia potom zvyčajne pridá len 1 – 2 MB skutočne využitého miesta na disku. Pri našom testovaní klesla spotreba miesta pri desiatich aplikáciách z viac než 3 GB na približne 360 MB.
Dosiahli sme to pomocou funkcie, ktorá je už súčasťou macOS: klonov APFS. Nešlo však len o samotné klonovanie súborov. Výzvou bolo zabezpečiť, aby klonovanie fungovalo a zároveň každá aplikácia zostala nezávislá, mala platný kódový podpis a fungovala rovnako ako aplikácia vytvorená pôvodným postupom.
Prečo každá aplikácia zaberala ďalších 320 MB
Desktopová aplikácia WebCatalog mení webové stránky na samostatné desktopové aplikácie. Každá vytvorená aplikácia beží na Photone, našom aplikačnom jadre postavenom na Electrone. Na macOS má každá podobu bežného balíka .app, ktorý obsahuje Electron (Chromium a Node.js), Photon a súbory špecifické pre danú aplikáciu.
Vezmime si napríklad dve aplikácie: Slack a Discord. Líšia sa názvom, ikonou, identifikátorom balíka a konfiguráciou, ale rozsiahly framework Electron a väčšina Photonu sú v oboch rovnaké.
Doteraz sa každá aplikácia vytvárala ako úplne samostatná kópia.
Slack.app
Electron
Photon
Súbory špecifické pre Slack
Discord.app
Electron
Photon
Súbory špecifické pre Discord
Framework Electron a Photon mohli byť v oboch aplikáciách zhodné do posledného bajtu, macOS však pre každú aplikáciu ukladal ďalšiu fyzickú kópiu. Desať aplikácií teda znamenalo približne desať kópií takmer rovnakého aplikačného balíka s veľkosťou 320 MB.
Táto architektúra mala jednu vlastnosť, ktorú sme chceli zachovať: každá aplikácia bola úplne nezávislá. Odstránenie jednej nemohlo ovplyvniť ostatné a nainštalované aplikácie neboli závislé od toho, či desktopová aplikácia WebCatalog zostane v systéme.
Chceli sme odstrániť zbytočné duplikovanie dát, ktoré sa za tým skrývalo.
APFS už malo funkciu, ktorú sme potrebovali
Moderné Macy používajú súborový systém APFS od spoločnosti Apple. APFS podporuje klonovanie, mechanizmus kopírovania pri zápise, vďaka ktorému môžu dva nezávislé súbory zdieľať rovnaké fyzické dáta, kým sa jeden z nich nezmení.
Predstavte si, že kopírujete 300 MB súbor. Pri bežnom kopírovaní macOS zapíše na disk ďalších 300 MB, takže oba súbory spolu zaberajú približne 600 MB.
Pri klone APFS nový súbor stále vyzerá a funguje ako úplný 300 MB súbor, no spočiatku odkazuje na rovnaké fyzické bloky ako originál.
Súbor A ───┐
├── zdieľané fyzické bloky
Súbor B ───┘
Ak sa neskôr zmení časť súboru B, APFS zapíše nové bloky iba pre zmenené dáta. Všetko, čo zostane rovnaké, môže naďalej zdieľať pôvodné bloky.
Súbor A ──────── zdieľané bloky
Súbor B ──────── zdieľané bloky
└─────── zmenené bloky
Z pohľadu aplikácie sú súbory A a B oddelené. Z pohľadu SSD stačí rovnaké dáta uložiť iba raz.
Presne takéto správanie sme potrebovali.
Vytváranie aplikácií zo spoločného základu
Desktopová aplikácia WebCatalog teraz pripravuje základ pre každú kombináciu verzií Electronu a Photonu. Základná aplikácia Photon obsahuje časti, ktoré sú vo všetkých aplikáciách rovnaké, vrátane Electronu, Photonu, štruktúry frameworku a spoločných podpisov.
Keď desktopová aplikácia vytvára ďalšiu aplikáciu s rovnakými verziami, už nerozbaľuje a nevytvára od začiatku ďalšiu úplnú kópiu. Namiesto toho vytvorí klon APFS základnej aplikácie Photon a upraví iba časti, ktoré sa musia líšiť.
Patrí medzi ne názov a ikona aplikácie, identifikátor balíka, nastavenia, názvy spustiteľných súborov, identifikátor zostavenia a ďalšie metadáta špecifické pre aplikáciu.
Keďže väčšina balíka zostáva nezmenená, APFS naďalej zdieľa fyzické bloky obsahujúce Electron a Photon. Nové miesto zaberá len pomerne malé množstvo dát špecifických pre aplikáciu.
Prečo jednoducho nezdieľať Electron?
Zjavnejším riešením by bolo nainštalovať Electron iba raz a nechať naň odkazovať všetky aplikácie.
Zvažovali sme to, ale zásadne by to zmenilo spoľahlivosť aplikácií. Ak by zdieľaná inštalácia Electronu zmizla, všetky aplikácie, ktoré od nej závisia, by mohli prestať fungovať. Mohol by ju odstrániť nástroj na čistenie vyrovnávacej pamäte alebo odinštalovanie desktopovej aplikácie WebCatalog; presúvanie či obnova jednotlivej aplikácie by sa tiež skomplikovali.
Vyžadovalo by si to aj sledovanie toho, ktoré nainštalované aplikácie závisia od ktorých verzií runtime prostredia, aby bolo možné staré verzie bezpečne odstrániť.
Ďalší problém predstavuje podpisovanie kódu v macOS. Prísne overovanie podpisu odmieta symbolické odkazy smerujúce mimo aplikačného balíka.
Klony APFS nám poskytujú výhody zdieľania bez zavedenia takejto závislosti. Nainštalované aplikácie môžu zdieľať fyzické bloky na disku a pritom zostať úplnými, nezávislými aplikačnými balíkmi.
Odstránenie základnej aplikácie Photon nenaruší aplikácie, ktoré z nej vznikli. Odstránenie jednej nainštalovanej aplikácie neovplyvní ostatné. O zdieľanie sa stará súborový systém, zatiaľ čo architektúra aplikácií zostáva nezávislá.
Podpisovanie kódu takmer zrušilo úsporu miesta
Klonovanie aplikácie bolo len časťou problému. Aplikácie pre macOS musia byť aj podpísané.
Náš pôvodný postup zostavovania po úpravách znova podpisoval celý aplikačný balík vrátane vnorených súčastí. Pri bežnej kópii to neprekáža. Pri úložisku využívajúcom kopírovanie pri zápise však môže zmena veľkého binárneho súboru spôsobiť, že APFS preň vyhradí nové fyzické bloky.
Počas vývoja sme namerali, že opätovné podpísanie frameworku Electron pridalo na každú aplikáciu približne 194 MB fyzicky využitého miesta. Pri vytváraní aplikácie sme sa úspešne vyhli kopírovaniu Electronu, len aby sme veľkú časť z neho znova duplikovali pri podpisovaní.
Museli sme preto zmeniť aj postup podpisovania.
Veľký spoločný framework sa teraz podpisuje ako súčasť základnej aplikácie Photon. Keď desktopová aplikácia tento základ naklonuje, veľké zdieľané binárne súbory nemeníme a znova podpisujeme iba menšie časti, ktoré sa medzi aplikáciami musia líšiť.
Keď je aplikácia hotová, spustíme prísne overenie podpisu celého balíka, aby sme sa uistili, že všetko zostalo platné.
Vďaka tomu zachovávame záruky podpisovania kódu v macOS aj úsporu miesta, ktorú prináša APFS.
Keď požiadavka na klonovanie v Node.js neviedla ku klonovaniu
Narazili sme ešte na jeden nečakaný problém: samotné vytvorenie klonu.
Node.js ponúka príznaky kopírovania určené na vyžiadanie správania typu kopírovanie pri zápise vrátane COPYFILE_FICLONE a COPYFILE_FICLONE_FORCE. Na papieri vyzerali presne ako rozhrania API, ktoré sme potrebovali.
Pri testovaní v Node.js 24 sme skopírovali tú istú 288 MB aplikáciu Electron niekoľkými spôsobmi a merali sme, koľko ďalšieho fyzického miesta na disku každá operácia zabrala:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Oba režimy klonovania v Node.js v našom teste aj tak vytvorili úplnú fyzickú kópiu. Dokonca ani variant FORCE neohlásil chybu, keď k očakávanému klonovaniu nedošlo.
Natívny príkaz macOS cp -c sa správal podľa očakávania, preto desktopová aplikácia WebCatalog používa priamo tento mechanizmus.
Zároveň nám to pripomenulo, že optimalizácie súborového systému treba overovať meraním samotného súborového systému. Zavolanie rozhrania API, ktoré požaduje kopírovanie pri zápise, ešte neznamená, že výsledné súbory skutočne zdieľajú fyzické úložisko.
Bezpečný postup aj v prípade zlyhania optimalizácie
Úspora miesta na disku je optimalizácia. Úspešná inštalácia aplikácie je nevyhnutnosť.
Nový postup sme navrhli tak, aby zlyhanie klonovania nebránilo inštalácii aplikácie. Ak zlyhá príprava základnej aplikácie Photon, ak je základ uložený vo vyrovnávacej pamäti poškodený, ak zlyhá klonovanie alebo ak aplikácia neprejde overením podpisu, desktopová aplikácia sa vráti k pôvodnému postupu zostavovania s úplným rozbalením a podpísaním.
V najhoršom prípade teda aplikácia zaberie rovnako veľa miesta ako predtým; inštalácia nezlyhá.
Museli sme zohľadniť aj súbežné operácie. Základná aplikácia Photon sa najprv pripraví v dočasnom priečinku a na konečné miesto sa presunie až po dokončení. Dve súčasne prebiehajúce zostavenia tak nemôžu omylom použiť nedokončený základ.
Staršie základy možno bezpečne odstrániť. Nainštalovaný klon APFS nie je závislý od toho, či pôvodný základ naďalej existuje. Ak sa základ odstráni, klonu zostanú fyzické bloky, ktoré stále používa.
Funguje to na APFS, predvolenom súborovom systéme každého moderného Macu. Ak máte aplikácie na disku, ktorý klonovanie nepodporuje, napríklad na externom disku s HFS+ alebo exFAT, desktopová aplikácia WebCatalog použije bežné kopírovanie. Aplikácie tak fungujú ako predtým, ale miesto nešetria. Na Windowse a Linuxe sa zatiaľ nič nemení.
Logická a fyzická veľkosť nie sú to isté
Mierne mätúcim vedľajším dôsledkom je, že Finder môže pri každej aplikácii stále uvádzať veľkosť okolo 320 MB.
Toto číslo predstavuje logickú veľkosť aplikácie. Aplikácia skutočne obsahuje súbory s celkovou veľkosťou približne 320 MB. Ak by sa skopírovali niekam bez klonovania, približne toľko dát by bolo treba zapísať.
Zmenila sa fyzická veľkosť, teda počet jedinečných blokov, ktoré tieto súbory skutočne zaberajú na disku.
Ak dve aplikácie obsahujú rovnaký 300 MB framework a APFS im umožní zdieľať tie isté fyzické bloky, každá z nich môže logicky obsahovať 300 MB, no druhá pridá takmer nulové množstvo nových fyzických dát.
Zobrazenie Informácie vo Finderi ani nástroje ako du nemusia toto zdieľanie ukazovať. Úspora je najviditeľnejšia na množstve voľného miesta, ktoré na disku skutočne zostáva.
Overili sme to na siedmich skutočných aplikáciách: Discorde, Facebooku, Instagrame, Messengeri, TikToku a dvoch vlastných aplikáciách. Pri tomto spôsobe zostavenia ušetrili oproti pôvodnému postupu približne 1,9 GB miesta na disku.
Skontrolovali sme aj fyzické pozície dát na disku a potvrdili, že aplikácie zdieľajú spoločné dáta Electronu a Photonu na úrovni blokov. Aplikácia vytvorená pôvodným postupom nezdieľala žiadny z týchto blokov, čo nám poskytlo užitočné porovnanie.
Výsledok
Ak si pomocou desktopovej aplikácie WebCatalog vytvoríte iba jednu aplikáciu, rozdiel je malý. Prvá aplikácia v skutočnosti zaberá o niečo viac miesta než predtým, pretože desktopová aplikácia si ponecháva aj základnú aplikáciu Photon na vytváranie ďalších klonov.
Pri ďalších aplikáciách však úspora rýchlo rastie.
Predtým
1 aplikácia ~320 MB
10 aplikácií >3 GB
S klonovaním APFS:
Teraz
1 aplikácia ~340 MB
10 aplikácií ~360 MB
Po vytvorení prvého základu pridá každá ďalšia aplikácia zvyčajne len 1 – 2 MB fyzicky využitého miesta na disku.
Dôležité je, že sme to dosiahli bez zavedenia závislosti od zdieľaného runtime prostredia. Každá aplikácia zostáva bežnou, samostatnou aplikáciou pre macOS, zatiaľ čo APFS ukladá rovnaké dáta Electronu a Photonu iba raz. Pri približne desiatich nainštalovaných aplikáciách to môže znížiť skutočné využitie miesta na disku viac než osemnásobne.
Táto funkcia je dostupná v najnovšej verzii desktopovej aplikácie WebCatalog pre macOS. Nemusíte nič zapínať: nové aplikácie ju používajú automaticky a aplikácie, ktoré už máte, začnú zaberať menej miesta pri najbližšej aktualizácii.