Jokainen WebCatalogin työpöytäsovelluksella luotu sovellus vei aiemmin macOS:ssä noin 320 Mt levytilaa. Se ei ole Electron-pohjaiselle sovellukselle epätavallista, mutta WebCatalog on suunniteltu ihmisille, jotka käyttävät monia verkkosovelluksia työpöytäsovelluksina. Kymmenen sovellusta saattoi viedä yli 3 Gt, vaikka suurin osa niiden sisältämästä datasta oli täsmälleen samaa.
Muutimme hiljattain tapaa, jolla WebCatalogin työpöytäsovellus rakentaa sovelluksia macOS:ssä. Ensimmäinen sovellus käyttää nyt noin 340 Mt fyysistä levytilaa. Siihen sisältyy paikallisesti säilytettävä, valmiiksi käsitelty kopio sovellusmoottorista. Sen jälkeen jokainen lisäsovellus kasvattaa todellista levynkäyttöä tyypillisesti vain 1–2 Mt. Testeissämme kymmenen sovelluksen levynkäyttö putosi yli 3 Gt:stä noin 360 Mt:uun.
Toteutimme tämän macOS:n sisäänrakennetulla ominaisuudella: APFS-klooneilla. Kiinnostavinta ei ollut pelkkä tiedostojen kloonaaminen, vaan se, miten kloonaus saatiin toimimaan niin, että jokainen sovellus pysyy itsenäisenä, sen koodin allekirjoitus on kunnossa ja se toimii samalla tavalla kuin vanhalla menetelmällä rakennettu sovellus.
Miksi jokainen sovellus vei toiset 320 Mt
WebCatalogin työpöytäsovellus muuntaa verkkosivustoja itsenäisiksi työpöytäsovelluksiksi. Jokainen luotu sovellus toimii Photonilla, Electroniin perustuvalla sovellusmoottorillamme. macOS:ssä jokainen niistä on tavallinen .app-sovelluspaketti, joka sisältää Electronin (Chromiumin ja Node.js:n), Photonin sekä kyseisen sovelluksen omat tiedostot.
Otetaan esimerkiksi kaksi sovellusta, Slack ja Discord. Niiden nimet, kuvakkeet, sovelluspakettien tunnisteet ja asetukset ovat erilaiset, mutta suuri Electron-kehys ja suurin osa Photonista ovat identtiset.
Tähän asti jokainen sovellus rakennettiin täysin erillisenä kopiona.
Slack.app
Electron
Photon
Slackin omat tiedostot
Discord.app
Electron
Photon
Discordin omat tiedostot
Electron-kehys ja Photon saattoivat olla molemmissa sovelluksissa identtisiä tavulleen, mutta macOS tallensi silti jokaiselle sovellukselle uuden fyysisen kopion. Kymmenen sovellusta tarkoitti siis noin kymmentä kopiota lähes samasta 320 Mt:n sovelluspaketista.
Tässä rakenteessa oli kuitenkin yksi ominaisuus, jonka halusimme säilyttää: jokainen sovellus oli täysin itsenäinen. Yhden poistaminen ei voinut vaikuttaa toiseen, eivätkä asennetut sovellukset riippuneet siitä, että WebCatalogin työpöytäsovellus pysyi järjestelmässä.
Halusimme poistaa niiden taustalla olevan tarpeettoman päällekkäisyyden.
APFS:ssä oli jo tarvitsemamme ominaisuus
Nykyaikaiset Macit käyttävät Applen APFS-tiedostojärjestelmää. APFS tukee kloonausta: kopioi kirjoitettaessa -mekanismia, jonka ansiosta kaksi itsenäistä tiedostoa voivat jakaa saman fyysisen datan, kunnes toista niistä muutetaan.
Kuvitellaan 300 Mt:n tiedoston kopioimista. Tavallisessa kopioinnissa macOS kirjoittaa levylle toiset 300 Mt, joten tiedostot vievät yhteensä noin 600 Mt.
APFS-kloonissa uusi tiedosto näyttää ja toimii edelleen kuin kokonainen 300 Mt:n tiedosto, mutta aluksi se viittaa samoihin fyysisiin lohkoihin kuin alkuperäinen.
Tiedosto A ─┐
├── jaetut fyysiset lohkot
Tiedosto B ─┘
Jos osaa tiedostosta B muutetaan myöhemmin, APFS kirjoittaa uusia lohkoja vain muuttuneelle datalle. Kaikki ennallaan pysyvä voi edelleen jakaa alkuperäiset lohkot.
Tiedosto A ───── jaetut lohkot
Tiedosto B ───── jaetut lohkot
└──── muuttuneet lohkot
Sovelluksen näkökulmasta tiedostot A ja B ovat erillisiä. SSD-levyn näkökulmasta identtinen data tarvitsee tallentaa vain kerran.
Se vastasi lähes täsmälleen tarvettamme.
Sovellusten rakentaminen yhteisestä pohjasta
WebCatalogin työpöytäsovellus valmistelee nyt pohjan kullekin Electron- ja Photon-versioiden yhdistelmälle. Photon-pohjasovellus sisältää eri sovelluksissa identtiset osat, kuten Electronin, Photonin, kehysrakenteen ja yhteiset allekirjoitukset.
Kun työpöytäsovellus luo uuden sovelluksen samoilla versioilla, se ei enää pura ja rakenna uutta täydellistä kopiota alusta asti. Sen sijaan se luo Photon-pohjasovelluksesta APFS-kloonin ja muokkaa vain niitä osia, joiden täytyy olla erilaisia.
Näitä ovat sovelluksen nimi, kuvake, sovelluspaketin tunniste, asetukset, suoritettavien tiedostojen nimet, koontitunniste ja muut sovelluskohtaiset metatiedot.
Koska suurin osa sovelluspaketista pysyy ennallaan, APFS jatkaa Electronin ja Photonin sisältävien fyysisten lohkojen jakamista. Vain suhteellisen pieni määrä sovelluskohtaista dataa vie uutta tilaa.
Miksei vain jaeta Electronia?
Ilmeisempi ratkaisu olisi asentaa Electron kerran ja ohjata kaikki sovellukset käyttämään sitä.
Harkitsimme sitä, mutta se muuttaisi toimintavarmuuden perustaa. Jos jaettu Electron-asennus katoaisi, kaikki siitä riippuvat sovellukset voisivat lakata toimimasta. Välimuistin siivoustyökalu voisi poistaa sen, WebCatalogin työpöytäsovelluksen poistaminen voisi poistaa sen, ja yksittäisen sovelluksen siirtämisestä tai palauttamisesta tulisi hankalampaa.
Lisäksi olisi seurattava, mitkä asennetut sovellukset riippuvat mistäkin ajoympäristön versiosta, jotta vanhat versiot voitaisiin poistaa turvallisesti.
macOS:n koodin allekirjoitus aiheuttaa vielä yhden ongelman. Tiukka allekirjoituksen tarkistus hylkää symboliset linkit, jotka osoittavat sovelluspaketin ulkopuolelle.
APFS-kloonit tarjoavat jakamisen hyödyt ilman tällaista riippuvuutta. Asennetut sovellukset voivat jakaa fyysisiä levylohkoja ja pysyä silti täydellisinä, itsenäisinä sovelluspaketteina.
Photon-pohjasovelluksen poistaminen ei riko siitä luotuja sovelluksia. Yhden asennetun sovelluksen poistaminen ei vaikuta toiseen. Tiedostojärjestelmä huolehtii jakamisesta, mutta sovellusten rakenne pysyy itsenäisenä.
Koodin allekirjoitus oli melkein vienyt tilansäästön
Sovelluksen kloonaaminen oli vain osa ongelmaa. macOS-sovellusten koodi on myös allekirjoitettava.
Vanha rakennusprosessimme allekirjoitti koko sovelluspaketin kaikkine sisäkkäisine osineen uudelleen mukauttamisen jälkeen. Tavallisen kopion tapauksessa se ei haittaa. Kopioi kirjoitettaessa -tallennuksessa suuren binaaritiedoston muuttaminen voi kuitenkin saada APFS:n varaamaan sille uusia fyysisiä lohkoja.
Kehitystyön aikana mittasimme, että Electron-kehyksen uudelleenallekirjoittaminen lisäsi fyysistä tallennustarvetta noin 194 Mt sovellusta kohden. Olimme onnistuneet välttämään Electronin kopioinnin sovellusta luotaessa, mutta vain monistaaksemme suuren osan siitä uudelleen allekirjoituksen yhteydessä.
Siksi myös allekirjoitusprosessia oli muutettava.
Suuri yhteinen kehys allekirjoitetaan nyt osana Photon-pohjasovellusta. Kun työpöytäsovellus kloonaa pohjan, emme muuta suuria jaettuja binaaritiedostoja. Allekirjoitamme uudelleen vain ne pienemmät osat, joiden täytyy erota sovellusten välillä.
Kun sovellus on valmis, tarkistamme valmiin paketin allekirjoituksen tiukasti varmistaaksemme, että kaikki on edelleen kunnossa.
Näin säilytämme sekä macOS:n koodin allekirjoituksen tarjoamat takeet että APFS:n tuoman tilansäästön.
Kun Node.js:ää pyydettiin kloonaamaan, mutta se ei kloonannutkaan
Vastaan tuli toinenkin odottamaton ongelma: itse kloonauksen suorittaminen.
Node.js tarjoaa kopiointilippuja, joilla on tarkoitus pyytää kopioi kirjoitettaessa -toimintaa, muun muassa COPYFILE_FICLONE ja COPYFILE_FICLONE_FORCE. Paperilla ne vaikuttivat juuri tarvitsemiltamme rajapinnoilta.
Testasimme Node.js 24:llä saman 288 Mt:n Electron-sovelluksen kopiointia useilla menetelmillä ja mittasimme, kuinka paljon fyysistä levytilaa kukin toimenpide lisäsi:
fs.cpSync +288 Mt
fs.cpSync + COPYFILE_FICLONE +288 Mt
fs.cpSync + COPYFILE_FICLONE_FORCE +288 Mt
/bin/cp -c -R ~0 Mt
Molemmat Node.js:n kloonaustilat tuottivat testissämme täyden fyysisen kopion. Edes FORCE-muunnelma ei ilmoittanut virheestä, vaikka odotettua kloonausta ei tapahtunut.
macOS:n oma cp -c toimi odotetusti, joten WebCatalogin työpöytäsovellus käyttää sitä suoraan.
Tämä muistutti myös siitä, että tiedostojärjestelmän optimoinnit on varmistettava mittaamalla itse tiedostojärjestelmää. Kopioi kirjoitettaessa -toimintaa pyytävän rajapinnan kutsuminen ei välttämättä tarkoita, että tuloksena olevat tiedostot todella jakaisivat fyysistä tallennustilaa.
Optimointi, jonka epäonnistuminen ei haittaa asennusta
Levytilan säästäminen on optimointi. Sovelluksen onnistunut asentaminen ei ole.
Suunnittelimme uuden prosessin niin, että kloonaus voi epäonnistua estämättä sovelluksen asentamista. Jos Photon-pohjasovelluksen valmistelu epäonnistuu, välimuistissa oleva pohja on vaurioitunut, kloonaus epäonnistuu tai allekirjoituksen tarkistus ei mene läpi, työpöytäsovellus palaa aiempaan rakennusprosessiin, jossa kaikki puretaan ja allekirjoitetaan kokonaan.
Pahimmassa tapauksessa levynkäyttö on siis sama kuin ennen, eikä asennus epäonnistu.
Meidän oli huomioitava myös samanaikaiset toiminnot. Photon-pohjasovellus valmistellaan ensin väliaikaisessa hakemistossa ja siirretään lopulliseen sijaintiinsa vasta valmistuttuaan. Näin kaksi samanaikaista sovelluksen rakennusta eivät voi vahingossa nähdä keskeneräistä pohjaa.
Myös vanhat pohjat voidaan poistaa turvallisesti. Asennettu APFS-klooni ei tarvitse alkuperäistä pohjaa pysyäkseen olemassa. Jos pohja poistetaan, klooni säilyttää edelleen käyttämänsä fyysiset lohkot.
Tämä toimii APFS:ssä, joka on kaikkien nykyaikaisten Macien oletustiedostojärjestelmä. Jos sovelluksesi sijaitsevat levyllä, joka ei tue kloonausta, kuten ulkoisella HFS+- tai exFAT-asemalla, WebCatalogin työpöytäsovellus käyttää tavallista kopiointia. Sovellukset toimivat silloin kuten ennenkin, mutta levytilaa ei säästy. Windowsissa ja Linuxissa mikään ei toistaiseksi muutu.
Looginen koko ja fyysinen koko ovat eri asioita
Yksi hieman hämmentävä sivuvaikutus on se, että Finder saattaa edelleen ilmoittaa kunkin sovelluksen kooksi noin 320 Mt.
Tämä luku kuvaa sovelluksen loogista kokoa. Sovellus todella sisältää noin 320 Mt tiedostoja, ja jos tiedostot kopioitaisiin paikkaan, jossa kloonausta ei käytetä, suunnilleen näin paljon dataa pitäisi kirjoittaa.
Muuttunut asia on fyysinen koko eli se, kuinka monta erillistä lohkoa tiedostot todella vievät levyltä.
Jos kahdessa sovelluksessa on sama 300 Mt:n kehys ja APFS sallii niiden jakaa samat taustalla olevat lohkot, kumpikin sovellus voi loogisesti sisältää 300 Mt, vaikka toinen niistä lisäisi fyysistä datamäärää tuskin lainkaan.
Finderin Näytä tietoja -ikkuna ja du:n kaltaiset työkalut eivät välttämättä tuo tätä jakamista näkyviin. Säästö näkyy selvimmin levyllä todella jäljellä olevan vapaan tilan määrässä.
Varmistimme tämän seitsemällä oikealla sovelluksella: Discordilla, Facebookilla, Instagramilla, Messengerillä, TikTokilla ja kahdella itse määritetyllä sovelluksella. Näin rakennettuina ne säästivät noin 1,9 Gt levytilaa vanhaan rakennusprosessiin verrattuna.
Tarkistimme myös taustalla olevien fyysisten lohkojen sijainnit levyllä ja vahvistimme, että sovellukset jakoivat yhteisen Electron- ja Photon-datansa lohkotasolla. Vanhalla rakennusprosessilla luotu sovellus ei jakanut näistä lohkoista yhtäkään, joten se tarjosi hyödyllisen vertailukohdan.
Lopputulos
Jos WebCatalogin työpöytäsovelluksella luo vain yhden sovelluksen, ero on pieni. Ensimmäinen sovellus vie itse asiassa hieman enemmän levytilaa kuin ennen, koska työpöytäsovellus säilyttää myös Photon-pohjasovelluksen, jota käytetään myöhempien kloonien luomiseen.
Sen jälkeen hyöty kasvaa nopeasti.
Ennen
1 sovellus ~320 Mt
10 sovellusta >3 Gt
APFS-kloonauksella:
Nyt
1 sovellus ~340 Mt
10 sovellusta ~360 Mt
Kun pohja on luotu, jokainen lisäsovellus kasvattaa fyysistä levynkäyttöä tyypillisesti vain 1–2 Mt.
Olennaista on, että saavutimme tämän luomatta riippuvuutta jaetusta ajoympäristöstä. Jokainen sovellus pysyy tavallisena, itsenäisenä macOS-sovelluksena, mutta APFS tallentaa identtisen Electron- ja Photon-datan vain kerran. Kun asennettuna on noin kymmenen sovellusta, todellinen levynkäyttö voi pudota alle kahdeksasosaan entisestä.
Ominaisuus on käytettävissä WebCatalogin macOS-työpöytäsovelluksen uusimmassa versiossa. Mitään ei tarvitse ottaa käyttöön: uudet sovellukset hyödyntävät sitä automaattisesti, ja jo asentamiesi sovellusten levynkäyttö pienenee niiden seuraavan päivityksen yhteydessä.