A WebCatalog asztali alkalmazással létrehozott alkalmazások korábban egyenként körülbelül 320 MB lemezterületet foglaltak macOS-en. Ez egy Electron-alapú alkalmazásnál nem szokatlan, a WebCatalogot azonban azoknak terveztük, akik sok webes alkalmazást használnak asztali alkalmazásként. Tíz ilyen alkalmazás telepítve már több mint 3 GB-ot foglalhatott, pedig az alkalmazásokban található adatok nagy része pontosan ugyanaz volt.
Nemrég megváltoztattuk, hogyan készít alkalmazásokat a WebCatalog asztali alkalmazás macOS-en. Az első alkalmazás most körülbelül 340 MB tényleges lemezterületet használ; ebbe beletartozik az alkalmazásmotor egy helyben tárolt, előkészített példánya is. Ezután minden további alkalmazás jellemzően mindössze 1–2 MB tényleges lemezhasználatot jelent. Tesztjeinkben tíz alkalmazás helyigénye több mint 3 GB-ról körülbelül 360 MB-ra csökkent.
Ehhez a macOS egyik meglévő funkcióját, az APFS-klónozást használtuk. A kihívás nem pusztán a fájlok klónozása volt, hanem annak biztosítása is, hogy az alkalmazások továbbra is függetlenek és megfelelően kódaláírtak maradjanak, valamint működésükben megegyezzenek a régi eljárással készült alkalmazásokkal.
Miért foglalt minden alkalmazás újabb 320 MB-ot?
A WebCatalog asztali alkalmazás a webhelyekből önálló asztali alkalmazásokat készít. Minden létrehozott alkalmazás a Photonon, az Electronra épülő alkalmazásmotorunkon fut. macOS-en mindegyik egy szokványos .app alkalmazáscsomag, amely tartalmazza az Electront (Chromiumot és Node.js-t), a Photont és az adott alkalmazás saját fájljait.
Vegyünk például két alkalmazást, a Slacket és a Discordot. A nevük, az ikonjuk, az alkalmazáscsomag-azonosítójuk és a beállításaik különböznek, de a nagy méretű Electron-keretrendszer és a Photon nagy része azonos.
Eddig minden alkalmazás teljesen különálló másolatként készült el.
Slack.app
Electron
Photon
A Slack saját fájljai
Discord.app
Electron
Photon
A Discord saját fájljai
Az Electron-keretrendszer és a Photon a két alkalmazásban akár bájtról bájtra azonos lehetett, a macOS mégis újabb fizikai példányt tárolt belőlük minden egyes alkalmazáshoz. Tíz alkalmazás így nagyjából tíz példányt jelentett a szinte teljesen azonos, 320 MB-os alkalmazáscsomagból.
Ennek a felépítésnek volt egy tulajdonsága, amelyet meg akartunk őrizni: minden alkalmazás teljesen független volt. Az egyik törlése nem érinthette a többit, és a telepített alkalmazások működése nem függött attól, hogy a WebCatalog asztali alkalmazás továbbra is megtalálható-e a rendszeren.
Az alattuk megbújó felesleges többszörözést szerettük volna megszüntetni.
Az APFS már rendelkezett a szükséges megoldással
A modern Macek az Apple APFS fájlrendszerét használják. Az APFS támogatja a klónozást: ez egy másolás íráskor elven működő mechanizmus, amely lehetővé teszi, hogy két független fájl ugyanazokat a fizikai adatokat használja, amíg valamelyik meg nem változik.
Képzeljük el, hogy lemásolunk egy 300 MB-os fájlt. Hagyományos másoláskor a macOS újabb 300 MB-ot ír a lemezre, így a két fájl összesen körülbelül 600 MB-ot foglal.
APFS-klónozás esetén az új fájl továbbra is teljes értékű, 300 MB-os fájlnak látszik, és úgy is viselkedik, de kezdetben ugyanazokra a fizikai blokkokra hivatkozik, mint az eredeti.
A fájl ────┐
├── közösen használt fizikai blokkok
B fájl ────┘
Ha később a B fájl egy része megváltozik, az APFS csak a módosult adatokhoz ír új blokkokat. Minden változatlan adat továbbra is használhatja a közös eredeti blokkokat.
A fájl ──────── közös blokkok
B fájl ──────── közös blokkok
└─────── módosult blokkok
Az alkalmazás szempontjából az A és a B két külön fájl. Az SSD szempontjából az azonos adatokat csak egyszer kell tárolni.
Pontosan ilyen működésre volt szükségünk.
Alkalmazások készítése közös alapból
A WebCatalog asztali alkalmazás mostantól minden Electron–Photon-verziópárhoz előkészít egy alapot. A Photon-alapalkalmazás tartalmazza az alkalmazásokban közös részeket, köztük az Electront, a Photont, a keretrendszer struktúráját és a közös aláírásokat.
Amikor az asztali alkalmazás ugyanezekkel a verziókkal hoz létre egy másik alkalmazást, már nem csomagol ki és állít össze a semmiből egy újabb teljes másolatot. Ehelyett APFS-klónt készít a Photon-alapalkalmazásról, és csak azokat a részeket szabja testre, amelyeknek különbözniük kell.
Ilyen az alkalmazás neve, ikonja, alkalmazáscsomag-azonosítója, beállításai, a futtatható fájlok neve, a buildazonosító és az alkalmazásspecifikus metaadatok.
Mivel az alkalmazáscsomag nagy része változatlan marad, az APFS továbbra is közösen használja az Electront és a Photont tartalmazó fizikai blokkokat. Csak az alkalmazásspecifikus adatok viszonylag kis mennyisége foglal új helyet.
Miért nem osztjuk meg egyszerűen az Electront?
Kézenfekvőbb megoldásnak tűnhetne egyszer telepíteni az Electront, majd minden alkalmazással arra hivatkozni.
Fontolóra vettük ezt, de alapvetően megváltoztatná a megbízhatósági modellt. Ha a közös Electron-telepítés eltűnne, az összes tőle függő alkalmazás működésképtelenné válhatna. Eltávolíthatná egy gyorsítótár-tisztító, eltűnhetne a WebCatalog asztali alkalmazás eltávolításakor, és egy-egy alkalmazás áthelyezése vagy visszaállítása is bonyolultabbá válna.
Emellett nyilván kellene tartani, hogy mely telepített alkalmazások mely futtatókörnyezeti verzióktól függenek, hogy a régi verziókat biztonságosan lehessen eltávolítani.
A macOS kódaláírása újabb problémát jelent. A szigorú aláírás-ellenőrzés elutasítja az alkalmazáscsomagon kívülre mutató szimbolikus hivatkozásokat.
Az APFS-klónozás a megosztás előnyeit nyújtja anélkül, hogy ilyen függőséget hozna létre. A telepített alkalmazások közösen használhatnak fizikai lemezblokkokat, miközben teljes, független alkalmazáscsomagok maradnak.
A Photon-alapalkalmazás törlése nem teszi tönkre a belőle készült alkalmazásokat. Egy telepített alkalmazás törlése sem érinti a többit. A megosztást a fájlrendszer kezeli, miközben az alkalmazások felépítése független marad.
A kódaláírás majdnem lenullázta a megtakarítást
Az alkalmazás klónozása csak a feladat egyik része volt. A macOS-alkalmazásokat kódaláírással is el kell látni.
A régi összeállítási folyamatunk a testreszabás után az egész alkalmazáscsomagot, annak beágyazott elemeivel együtt, újra aláírta. Hagyományos másolatnál ez nem gond. Másolás íráskor elven működő tárolásnál viszont egy nagy bináris fájl módosítása miatt az APFS új fizikai blokkokat foglalhat le hozzá.
A fejlesztés során azt mértük, hogy az Electron-keretrendszer újbóli aláírása alkalmazásonként körülbelül 194 MB fizikai tárhelyet igényelt. Az alkalmazás létrehozásakor ugyan elkerültük az Electron lemásolását, az aláírás során azonban jelentős részét ismét lemásoltuk.
Ezért az aláírási folyamaton is változtatnunk kellett.
A nagy, közös keretrendszert most a Photon-alapalkalmazás részeként írjuk alá. Amikor az asztali alkalmazás klónozza ezt az alapot, nem módosítjuk a nagy, közösen használt bináris fájlokat, és csak azokat a kisebb részeket írjuk alá újra, amelyeknek különbözniük kell az alkalmazások között.
A kész alkalmazáscsomagon szigorú aláírás-ellenőrzést futtatunk, hogy meggyőződjünk róla: minden érvényes maradt.
Így a macOS kódaláírása nyújtotta garanciákat és az APFS révén elért tárhelymegtakarítást is megtarthatjuk.
Amikor a Node.js-től kért klónozás valójában nem klónozott
Egy másik váratlan problémába is ütköztünk: magának a klónozásnak a végrehajtásába.
A Node.js másolási kapcsolókkal teszi lehetővé a másolás íráskor működés kérését; ilyen a COPYFILE_FICLONE és a COPYFILE_FICLONE_FORCE is. Elméletben pontosan ezekre az API-kra lett volna szükségünk.
A Node.js 24 használatával végzett tesztjeinkben ugyanazt a 288 MB-os Electron-alkalmazást több módszerrel másoltuk le, majd megmértük, hogy az egyes műveletek mennyi további fizikai lemezterületet foglaltak:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Tesztünkben a Node.js mindkét klónozási módja teljes fizikai másolatot hozott létre, és még a FORCE változat sem jelzett hibát, amikor a várt klónozás elmaradt.
A macOS natív cp -c művelete a vártnak megfelelően működött, ezért a WebCatalog asztali alkalmazás közvetlenül ezt használja.
Ez arra is emlékeztetett bennünket, hogy a fájlrendszer-optimalizálásokat magán a fájlrendszeren végzett mérésekkel kell ellenőrizni. Attól, hogy egy API-tól másolás íráskor működést kérünk, a létrejövő fájlok még nem feltétlenül használnak közös fizikai tárhelyet.
Biztonságos visszaállás, ha az optimalizálás nem sikerül
A lemezterület megtakarítása optimalizálás. Az alkalmazás sikeres telepítése viszont alapkövetelmény.
Az új folyamatot úgy terveztük meg, hogy a klónozás hibája ne akadályozza meg az alkalmazás telepítését. Ha a Photon-alapalkalmazás előkészítése nem sikerül, a gyorsítótárazott alap sérült, a klónozás meghiúsul, vagy az aláírás-ellenőrzés sikertelen, az asztali alkalmazás visszatér a korábbi összeállítási folyamathoz, teljes kicsomagolással és teljes aláírással.
A legrosszabb eset tehát a korábbival azonos lemezhasználat, nem pedig sikertelen telepítés.
A párhuzamos működéssel is számolnunk kellett. A Photon-alapalkalmazást először egy ideiglenes könyvtárban készítjük elő, és csak akkor helyezzük át a végleges helyére, amikor már teljesen elkészült. Így két egyidejű alkalmazás-összeállítás sem találkozhat véletlenül egy félkész alappal.
A régebbi alapok is biztonságosan eltávolíthatók. Egy telepített APFS-klón működése nem függ attól, hogy az eredeti alap továbbra is létezik-e. Ha az alapot törlik, a klón megtartja az általa továbbra is használt fizikai blokkokat.
Ez az APFS-en működik, amely minden modern Mac alapértelmezett fájlrendszere. Ha az alkalmazások olyan lemezen vannak, amely nem támogatja a klónozást, például egy külső HFS+ vagy exFAT meghajtón, a WebCatalog asztali alkalmazás hagyományos másolásra tér vissza. Az alkalmazások így a korábbiak szerint működnek, de nem takarítanak meg helyet. A Windows és a Linux működése egyelőre változatlan.
A logikai méret és a fizikai méret nem ugyanaz
Az egyik kissé megtévesztő mellékhatás, hogy a Finder továbbra is körülbelül 320 MB-osnak mutathatja az egyes alkalmazásokat.
Ez a szám az alkalmazás logikai méretét jelenti. Az alkalmazás valóban nagyjából 320 MB-nyi fájlt tartalmaz, és ha ezeket klónozás nélkül másolnánk valahová, körülbelül ennyi adatot kellene kiírni.
Ami megváltozott, az a fizikai méret: az, hogy ezek a fájlok ténylegesen hány egyedi blokkot foglalnak a lemezen.
Ha két alkalmazás ugyanazt a 300 MB-os keretrendszert tartalmazza, és az APFS lehetővé teszi, hogy ugyanazokat a mögöttes blokkokat használják, akkor logikailag mindkettő tartalmazhat 300 MB-ot, miközben a második szinte semennyi új fizikai adatot nem foglal.
A Finder Információ megjelenítése nézete és az olyan eszközök, mint a du, nem feltétlenül teszik láthatóvá ezt a megosztást. A megtakarítás leginkább a lemezen ténylegesen megmaradó szabad területen látszik.
Ezt hét valódi alkalmazással ellenőriztük: a Discorddal, a Facebookkal, az Instagrammal, a Messengerrel, a TikTokkal és két egyéni alkalmazással. Ezzel a módszerrel elkészítve körülbelül 1,9 GB lemezterületet takarítottak meg a régi összeállítási folyamathoz képest.
A mögöttes fizikai lemezpozíciókat is megvizsgáltuk, és megerősítettük, hogy az alkalmazások blokkszinten közösen használják az Electron és a Photon közös adatait. Egy, a régi eljárással készült alkalmazás egyik ilyen blokkon sem osztozott velük, ami hasznos összehasonlítási alapot adott.
Az eredmény
Aki csak egyetlen alkalmazást hoz létre a WebCatalog asztali alkalmazással, annak kicsi a különbség. Az első alkalmazás valójában valamivel több lemezterületet használ, mint korábban, mert az asztali alkalmazás a későbbi klónok létrehozásához használt Photon-alapalkalmazást is tárolja.
Ezután viszont gyorsan nő az előny.
Korábban
1 alkalmazás ~320 MB
10 alkalmazás >3 GB
APFS-klónozással:
Most
1 alkalmazás ~340 MB
10 alkalmazás ~360 MB
A kezdeti alap létrehozása után minden további alkalmazás jellemzően mindössze 1–2 MB fizikai lemezhasználatot jelent.
A lényeg az, hogy ezt közös futtatókörnyezettől való függőség bevezetése nélkül értük el. Minden alkalmazás szokványos, önálló macOS-alkalmazás marad, miközben az APFS az azonos Electron- és Photon-adatokat csak egyszer tárolja. Körülbelül tíz telepített alkalmazásnál ez több mint nyolcadára csökkentheti a tényleges lemezhasználatot.
Ez a WebCatalog asztali alkalmazás legújabb macOS-verziójában érhető el. Semmit sem kell bekapcsolni: az új alkalmazások automatikusan használják, a már meglévő alkalmazások helyigénye pedig a következő frissítésükkor csökken.