Fiecare aplicație pe care o creați cu aplicația desktop WebCatalog ocupa până acum aproximativ 320 MB de spațiu pe disc în macOS. Nu este ceva neobișnuit pentru o aplicație bazată pe Electron, dar WebCatalog este conceput pentru persoanele care folosesc multe aplicații web ca aplicații desktop. Dacă instalați zece, acestea pot ocupa peste 3 GB, deși majoritatea datelor din ele sunt identice.
Am schimbat recent modul în care aplicația desktop WebCatalog creează aplicații pe macOS. Prima aplicație folosește acum aproximativ 340 MB de spațiu fizic pe disc, incluzând o copie pregătită a motorului aplicațiilor, păstrată local. După aceea, fiecare aplicație suplimentară adaugă, de regulă, doar 1–2 MB de spațiu ocupat efectiv pe disc. În testele noastre, zece aplicații au trecut de la peste 3 GB la aproximativ 360 MB.
Am făcut acest lucru folosind o funcționalitate deja integrată în macOS: clonele APFS. Partea interesantă nu a fost doar clonarea fișierelor, ci folosirea ei astfel încât fiecare aplicație să rămână independentă, să aibă o semnătură de cod validă și să fie echivalentă funcțional cu una creată prin vechiul proces.
De ce fiecare aplicație ocupa încă 320 MB
Aplicația desktop WebCatalog transformă site-urile web în aplicații desktop de sine stătătoare. Fiecare aplicație pe care o creați rulează pe Photon, motorul nostru pentru aplicații construit pe Electron. Pe macOS, fiecare este un pachet .app obișnuit, care conține Electron (Chromium și Node.js), Photon și fișierele specifice aplicației respective.
Să luăm, de exemplu, două aplicații: Slack și Discord. Numele, pictogramele, identificatorii de pachet și configurațiile lor diferă, dar cadrul software voluminos Electron și cea mai mare parte din Photon sunt identice.
Până acum, fiecare aplicație era creată ca o copie complet separată.
Slack.app
Electron
Photon
Fișiere specifice Slack
Discord.app
Electron
Photon
Fișiere specifice Discord
Cadrul software Electron și Photon puteau fi identice octet cu octet în ambele aplicații, dar macOS stoca totuși încă o copie fizică pentru fiecare aplicație. Zece aplicații însemnau, așadar, aproximativ zece copii ale unui pachet de aplicație de 320 MB aproape identic.
Această arhitectură avea totuși o proprietate pe care voiam să o păstrăm: fiecare aplicație era complet independentă. Ștergerea uneia nu putea afecta alta, iar aplicațiile instalate nu depindeau de prezența în continuare a aplicației desktop WebCatalog în sistem.
Ceea ce voiam să eliminăm era duplicarea inutilă din spatele lor.
APFS avea deja mecanismul de bază de care aveam nevoie
Mac-urile moderne folosesc sistemul de fișiere APFS de la Apple. APFS acceptă clonarea, un mecanism de copiere la scriere care permite ca două fișiere independente să folosească aceleași date fizice până când unul dintre ele se modifică.
Imaginați-vă că copiați un fișier de 300 MB. În cazul unei copii obișnuite, macOS scrie încă 300 MB pe disc, astfel încât cele două fișiere ocupă în total aproximativ 600 MB.
În cazul unei clone APFS, noul fișier arată și se comportă în continuare ca un fișier complet de 300 MB, dar inițial indică spre aceleași blocuri fizice ca originalul.
Fișierul A ─────┐
├── blocuri fizice partajate
Fișierul B ─────┘
Dacă o parte din Fișierul B se modifică ulterior, APFS scrie blocuri noi doar pentru datele modificate. Tot ce rămâne identic poate continua să folosească blocurile originale.
Fișierul A ───────── blocuri partajate
Fișierul B ───────── blocuri partajate
└──────── blocuri modificate
Din perspectiva aplicației, Fișierul A și Fișierul B sunt fișiere separate. Din perspectiva SSD-ului, datele identice trebuie stocate o singură dată.
Acesta este aproape exact comportamentul de care aveam nevoie.
Crearea aplicațiilor pornind de la o bază comună
Aplicația desktop WebCatalog pregătește acum o bază pentru fiecare combinație de versiuni Electron și Photon. Aplicația de bază Photon conține componentele identice între aplicații, inclusiv Electron, Photon, structura cadrelor software și semnăturile comune.
Când aplicația desktop creează o altă aplicație folosind aceleași versiuni, nu mai extrage și nu mai construiește de la zero încă o copie completă. În schimb, creează o clonă APFS a aplicației de bază Photon și personalizează doar elementele care trebuie să fie diferite.
Printre acestea se numără numele aplicației, pictograma, identificatorul de pachet, setările, numele executabilelor, identificatorul versiunii construite și alte metadate specifice aplicației.
Deoarece cea mai mare parte a pachetului rămâne neschimbată, APFS continuă să partajeze blocurile fizice care conțin Electron și Photon. Doar cantitatea relativ mică de date specifice aplicației ocupă spațiu nou.
De ce să nu partajăm pur și simplu Electron?
O abordare mai evidentă ar fi instalarea Electron o singură dată și configurarea fiecărei aplicații să îl folosească din acel loc.
Am luat în considerare această variantă, dar ar schimba fundamental modelul de fiabilitate. Dacă instalarea partajată a Electron ar dispărea, toate aplicațiile care depind de ea ar putea înceta să funcționeze. Un utilitar de curățare a cache-ului ar putea să o elimine, dezinstalarea aplicației desktop WebCatalog ar putea să o elimine, iar mutarea sau restaurarea unei aplicații individuale ar deveni mai complicată.
Ar fi necesar și să urmărim ce aplicații instalate depind de fiecare versiune a mediului de execuție, pentru a putea elimina în siguranță versiunile vechi.
Semnarea codului în macOS creează o altă problemă. Verificarea strictă a semnăturii respinge legăturile simbolice care indică spre fișiere din afara pachetului aplicației.
Clonele APFS ne oferă avantajul partajării fără să introducă această dependență. Aplicațiile instalate pot partaja blocuri fizice de pe disc, rămânând în același timp pachete de aplicații complete și independente.
Ștergerea aplicației de bază Photon nu strică aplicațiile create din ea. Ștergerea unei aplicații instalate nu afectează alta. Sistemul de fișiere gestionează partajarea, în timp ce arhitectura aplicațiilor rămâne independentă.
Semnarea codului aproape că a anulat economiile
Clonarea aplicației a fost doar o parte a problemei. Aplicațiile macOS trebuie și să fie semnate digital.
Vechiul nostru proces de construire resemna în profunzime fiecare pachet de aplicație după personalizare. Pentru o copie obișnuită, acest lucru este în regulă. Însă, în cazul stocării cu copiere la scriere, modificarea unui fișier binar mare poate determina APFS să aloce blocuri fizice noi pentru el.
În timpul dezvoltării, am constatat că resemnarea cadrului software Electron adăuga aproximativ 194 MB de spațiu fizic ocupat pentru fiecare aplicație. Evitaserăm cu succes copierea Electron la crearea aplicației, doar pentru a duplica din nou o mare parte din el la semnare.
Așadar, a trebuit să schimbăm și procesul de semnare.
Cadrul software comun, de mari dimensiuni, este acum semnat ca parte a aplicației de bază Photon. Când aplicația desktop clonează acea bază, evităm modificarea acelor fișiere binare mari și partajate și resemnăm doar componentele mai mici care chiar trebuie să difere între aplicații.
După finalizarea aplicației, efectuăm o verificare strictă a semnăturii pachetului rezultat, pentru a ne asigura că totul rămâne valid.
Astfel, păstrăm atât garanțiile oferite de semnarea codului în macOS, cât și economiile de spațiu datorate APFS.
Când cererea de clonare adresată Node.js nu a produs, de fapt, o clonă
A mai apărut o problemă neașteptată: realizarea clonei în sine.
Node.js oferă opțiuni de copiere concepute pentru a solicita comportamentul de copiere la scriere, inclusiv COPYFILE_FICLONE și COPYFILE_FICLONE_FORCE. În teorie, acestea păreau exact API-urile de care aveam nevoie.
În testele noastre cu Node.js 24, am copiat aceeași aplicație Electron de 288 MB folosind mai multe metode și am măsurat cât spațiu fizic suplimentar pe disc a ocupat fiecare operațiune:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Ambele moduri de clonare din Node.js au produs tot o copie fizică integrală în testul nostru, iar nici măcar varianta FORCE nu a raportat o eroare atunci când clonarea așteptată nu a avut loc.
Comanda nativă cp -c din macOS s-a comportat conform așteptărilor, așa că aplicația desktop WebCatalog folosește direct acest mecanism.
A fost și o reamintire utilă că optimizările sistemului de fișiere trebuie verificate prin măsurarea sistemului de fișiere însuși. Apelarea unui API care solicită copierea la scriere nu înseamnă neapărat că fișierele rezultate partajează efectiv spațiul fizic de stocare.
Cum am făcut ca optimizarea să poată eșua în siguranță
Economisirea spațiului pe disc este o optimizare. Instalarea cu succes a unei aplicații este o necesitate.
Am proiectat noul proces astfel încât clonarea să poată eșua fără a împiedica instalarea aplicației. Dacă pregătirea aplicației de bază Photon eșuează, dacă baza păstrată în cache este deteriorată, dacă clonarea eșuează sau dacă verificarea semnăturii nu trece, aplicația desktop revine la vechiul proces de construire, cu extragere completă și semnare completă.
Prin urmare, în cel mai rău caz, spațiul ocupat pe disc este același ca înainte, nu avem o instalare eșuată.
A trebuit să ținem cont și de operațiunile simultane. O aplicație de bază Photon este pregătită mai întâi într-un director temporar și mutată în locația finală abia după ce este completă. Astfel, două aplicații construite în același timp nu pot folosi din greșeală o bază neterminată.
Și bazele mai vechi pot fi eliminate în siguranță. O clonă APFS instalată nu depinde de existența în continuare a bazei originale. Dacă baza este ștearsă, clona păstrează blocurile fizice pe care încă le folosește.
Acest lucru funcționează pe APFS, sistemul de fișiere implicit pe toate Mac-urile moderne. Dacă aplicațiile dvs. se află pe un disc care nu permite clonarea, cum ar fi o unitate externă HFS+ sau exFAT, aplicația desktop WebCatalog revine la copierea obișnuită. Astfel, aplicațiile funcționează ca înainte, dar nu economisesc spațiu. Pentru moment, pe Windows și Linux nu se schimbă nimic.
Dimensiunea logică și dimensiunea fizică nu sunt același lucru
Un efect secundar care poate crea puțină confuzie este că Finder poate afișa în continuare aproximativ 320 MB pentru fiecare aplicație.
Această valoare reprezintă dimensiunea logică a aplicației. Aplicația chiar conține fișiere care însumează aproximativ 320 MB, iar dacă acele fișiere ar fi copiate undeva fără clonare, cam atât de multe date ar trebui scrise.
Ceea ce s-a schimbat este dimensiunea fizică, adică numărul de blocuri unice pe care acele fișiere le ocupă efectiv pe disc.
Dacă două aplicații conțin același cadru software de 300 MB, iar APFS le permite să partajeze aceleași blocuri fizice, fiecare aplicație poate conține, logic, 300 MB, în timp ce a doua adaugă foarte puține date fizice noi.
Fereastra Obține informații din Finder și instrumente precum du nu arată neapărat această partajare. Economiile se observă cel mai bine în spațiul liber rămas efectiv pe disc.
Am verificat acest lucru cu șapte aplicații reale: Discord, Facebook, Instagram, Messenger, TikTok și două aplicații personalizate. Construite astfel, ele au economisit aproximativ 1,9 GB de spațiu pe disc față de vechiul proces de construire.
Am verificat și pozițiile fizice ale datelor pe disc și am confirmat că aplicațiile partajau la nivel de bloc datele comune din Electron și Photon. O aplicație creată prin vechiul proces nu partaja niciunul dintre acele blocuri, oferindu-ne un termen de comparație util.
Rezultatul
Pentru cineva care creează o singură aplicație cu aplicația desktop WebCatalog, diferența este mică. Prima aplicație folosește, de fapt, puțin mai mult spațiu pe disc decât înainte, deoarece aplicația desktop păstrează și aplicația de bază Photon utilizată pentru crearea clonelor ulterioare.
După aceea, avantajul crește rapid.
Înainte
1 aplicație ~320 MB
10 aplicații >3 GB
Cu clonarea APFS:
După
1 aplicație ~340 MB
10 aplicații ~360 MB
După crearea bazei inițiale, fiecare aplicație suplimentară adaugă, de regulă, doar 1–2 MB de spațiu fizic ocupat pe disc.
Important este că am obținut acest rezultat fără a introduce o dependență de un mediu de execuție partajat. Fiecare aplicație rămâne o aplicație macOS obișnuită și autonomă, în timp ce APFS stochează o singură dată datele identice din Electron și Photon. Cu aproximativ zece aplicații instalate, spațiul ocupat efectiv pe disc poate fi redus de peste opt ori.
Această funcționalitate este disponibilă în cea mai recentă versiune a aplicației desktop WebCatalog pentru macOS. Nu trebuie să activați nimic: aplicațiile noi o folosesc automat, iar cele pe care le aveți deja vor ocupa mai puțin spațiu la următoarea actualizare.