Κάθε εφαρμογή που δημιουργούσατε με την εφαρμογή WebCatalog για υπολογιστές καταλάμβανε μέχρι πρόσφατα περίπου 320 MB χώρου στον δίσκο στο macOS. Αυτό δεν είναι ασυνήθιστο για μια εφαρμογή που βασίζεται στο Electron, αλλά το WebCatalog έχει σχεδιαστεί για ανθρώπους που χρησιμοποιούν πολλές εφαρμογές ιστού ως εφαρμογές υπολογιστή. Αν εγκαθιστούσατε δέκα, μπορούσαν να καταλάβουν πάνω από 3 GB, παρότι τα περισσότερα δεδομένα μέσα σε αυτές ήταν ακριβώς τα ίδια.
Πρόσφατα αλλάξαμε τον τρόπο με τον οποίο η εφαρμογή WebCatalog για υπολογιστές δημιουργεί εφαρμογές στο macOS. Η πρώτη εφαρμογή χρησιμοποιεί πλέον περίπου 340 MB φυσικού χώρου στον δίσκο, ποσό που περιλαμβάνει ένα τοπικά αποθηκευμένο, προετοιμασμένο αντίγραφο της μηχανής εφαρμογών. Έπειτα, κάθε επιπλέον εφαρμογή προσθέτει συνήθως μόνο 1–2 MB πραγματικής χρήσης δίσκου. Στις δοκιμές μας, ο χώρος που καταλάμβαναν δέκα εφαρμογές μειώθηκε από πάνω από 3 GB σε περίπου 360 MB.
Το πετύχαμε χρησιμοποιώντας μια δυνατότητα που υπάρχει ήδη στο macOS: τους κλώνους APFS. Το ενδιαφέρον δεν ήταν απλώς να κλωνοποιήσουμε αρχεία. Ήταν να κάνουμε την κλωνοποίηση να λειτουργεί διατηρώντας παράλληλα κάθε εφαρμογή ανεξάρτητη, σωστά υπογεγραμμένη με υπογραφή κώδικα και λειτουργικά ισοδύναμη με μια εφαρμογή που δημιουργήθηκε με την παλιά διαδικασία.
Γιατί κάθε εφαρμογή καταλάμβανε άλλα 320 MB
Η εφαρμογή WebCatalog για υπολογιστές μετατρέπει ιστότοπους σε αυτόνομες εφαρμογές υπολογιστή. Κάθε εφαρμογή που δημιουργείτε εκτελείται στο Photon, τη δική μας μηχανή εφαρμογών που βασίζεται στο Electron. Στο macOS, καθεμία είναι ένα κανονικό πακέτο .app που περιέχει το Electron (Chromium και Node.js), το Photon και τα αρχεία της συγκεκριμένης εφαρμογής.
Ας πάρουμε ως παράδειγμα δύο εφαρμογές, το Slack και το Discord. Τα ονόματα, τα εικονίδια, τα αναγνωριστικά πακέτου και οι ρυθμίσεις τους διαφέρουν, αλλά το μεγάλο πλαίσιο του Electron και το μεγαλύτερο μέρος του Photon είναι πανομοιότυπα.
Μέχρι τώρα, κάθε εφαρμογή δημιουργούνταν ως εντελώς ξεχωριστό αντίγραφο.
Slack.app
Electron
Photon
Αρχεία ειδικά για το Slack
Discord.app
Electron
Photon
Αρχεία ειδικά για το Discord
Το πλαίσιο του Electron και το Photon μπορεί να ήταν πανομοιότυπα μέχρι και το τελευταίο byte και στις δύο εφαρμογές, αλλά το macOS εξακολουθούσε να αποθηκεύει ένα ακόμη φυσικό αντίγραφο για κάθε εφαρμογή. Επομένως, δέκα εφαρμογές σήμαιναν περίπου δέκα αντίγραφα σχεδόν του ίδιου πακέτου εφαρμογής των 320 MB.
Αυτή η αρχιτεκτονική είχε, ωστόσο, ένα χαρακτηριστικό που θέλαμε να διατηρήσουμε: κάθε εφαρμογή ήταν πλήρως ανεξάρτητη. Η διαγραφή της μίας δεν μπορούσε να επηρεάσει κάποια άλλη και οι εγκατεστημένες εφαρμογές δεν εξαρτιόνταν από το αν η εφαρμογή WebCatalog για υπολογιστές παρέμενε στο σύστημα.
Αυτό που θέλαμε να εξαλείψουμε ήταν η περιττή επανάληψη δεδομένων στην οποία βασίζονταν.
Το APFS διέθετε ήδη τον μηχανισμό που χρειαζόμασταν
Οι σύγχρονοι Mac χρησιμοποιούν το σύστημα αρχείων APFS της Apple. Το APFS υποστηρίζει την κλωνοποίηση, έναν μηχανισμό αντιγραφής κατά την εγγραφή (copy-on-write) που επιτρέπει σε δύο ανεξάρτητα αρχεία να μοιράζονται τα ίδια φυσικά δεδομένα μέχρι να αλλάξει ένα από αυτά.
Φανταστείτε ότι αντιγράφετε ένα αρχείο 300 MB. Με μια κανονική αντιγραφή, το macOS γράφει άλλα 300 MB στον δίσκο, οπότε τα δύο αρχεία καταλαμβάνουν συνολικά περίπου 600 MB.
Με έναν κλώνο APFS, το νέο αρχείο εξακολουθεί να φαίνεται και να λειτουργεί σαν πλήρες αρχείο 300 MB, αλλά αρχικά παραπέμπει στα ίδια φυσικά μπλοκ με το πρωτότυπο.
Αρχείο A ─────┐
├── κοινά φυσικά μπλοκ
Αρχείο B ─────┘
Αν αργότερα αλλάξει μέρος του αρχείου B, το APFS γράφει νέα μπλοκ μόνο για τα δεδομένα που άλλαξαν. Όσα παραμένουν ίδια μπορούν να συνεχίσουν να μοιράζονται τα αρχικά μπλοκ.
Αρχείο A ───────── κοινά μπλοκ
Αρχείο B ───────── κοινά μπλοκ
└──────── τροποποιημένα μπλοκ
Από την οπτική της εφαρμογής, τα αρχεία A και B είναι ξεχωριστά. Από την οπτική του SSD, τα πανομοιότυπα δεδομένα χρειάζεται να αποθηκευτούν μόνο μία φορά.
Αυτή ήταν σχεδόν ακριβώς η συμπεριφορά που χρειαζόμασταν.
Δημιουργία εφαρμογών από κοινή βάση
Η εφαρμογή WebCatalog για υπολογιστές προετοιμάζει πλέον μια βάση για κάθε συνδυασμό εκδόσεων του Electron και του Photon. Η βασική εφαρμογή Photon περιέχει τα μέρη που είναι ίδια σε όλες τις εφαρμογές, όπως το Electron, το Photon, τη δομή του πλαισίου και τις κοινές υπογραφές.
Όταν η εφαρμογή για υπολογιστές δημιουργεί άλλη μία εφαρμογή με τις ίδιες εκδόσεις, δεν αποσυμπιέζει και δεν δημιουργεί πλέον ένα ακόμη πλήρες αντίγραφο από την αρχή. Αντί γι’ αυτό, δημιουργεί έναν κλώνο APFS της βασικής εφαρμογής Photon και προσαρμόζει μόνο τα μέρη που πρέπει να διαφέρουν.
Σε αυτά περιλαμβάνονται το όνομα και το εικονίδιο της εφαρμογής, το αναγνωριστικό πακέτου, οι ρυθμίσεις, τα ονόματα των εκτελέσιμων αρχείων, το αναγνωριστικό έκδοσης και άλλα μεταδεδομένα ειδικά για την εφαρμογή.
Επειδή το μεγαλύτερο μέρος του πακέτου παραμένει αμετάβλητο, το APFS συνεχίζει να μοιράζεται τα φυσικά μπλοκ που περιέχουν το Electron και το Photon. Μόνο η σχετικά μικρή ποσότητα δεδομένων που αφορά τη συγκεκριμένη εφαρμογή καταλαμβάνει νέο χώρο.
Γιατί να μη μοιράζονται απλώς το Electron;
Μια πιο προφανής προσέγγιση θα ήταν να εγκαταστήσουμε το Electron μία φορά και να κάνουμε κάθε εφαρμογή να παραπέμπει σε αυτό.
Το εξετάσαμε, αλλά θα άλλαζε ριζικά το μοντέλο αξιοπιστίας. Αν εξαφανιζόταν η κοινή εγκατάσταση του Electron, κάθε εφαρμογή που εξαρτάται από αυτή θα μπορούσε να σταματήσει να λειτουργεί. Θα μπορούσε να την αφαιρέσει ένα εργαλείο εκκαθάρισης της προσωρινής μνήμης ή η απεγκατάσταση της εφαρμογής WebCatalog για υπολογιστές, ενώ η μεταφορά ή η επαναφορά μιας μεμονωμένης εφαρμογής θα γινόταν πιο περίπλοκη.
Θα έπρεπε επίσης να παρακολουθούμε ποιες εγκατεστημένες εφαρμογές εξαρτώνται από ποιες εκδόσεις του περιβάλλοντος εκτέλεσης, ώστε να μπορούμε να αφαιρούμε με ασφάλεια τις παλιές εκδόσεις.
Η υπογραφή κώδικα στο macOS δημιουργεί άλλο ένα πρόβλημα. Η αυστηρή επαλήθευση υπογραφής απορρίπτει συμβολικούς συνδέσμους που παραπέμπουν έξω από το πακέτο της εφαρμογής.
Οι κλώνοι APFS μάς δίνουν τα οφέλη της κοινής χρήσης χωρίς να εισάγουν αυτή την εξάρτηση. Οι εγκατεστημένες εφαρμογές μπορούν να μοιράζονται φυσικά μπλοκ στον δίσκο, παραμένοντας παράλληλα πλήρη, ανεξάρτητα πακέτα εφαρμογών.
Η διαγραφή της βασικής εφαρμογής Photon δεν προκαλεί πρόβλημα στις εφαρμογές που δημιουργήθηκαν από αυτήν. Η διαγραφή μιας εγκατεστημένης εφαρμογής δεν επηρεάζει κάποια άλλη. Το σύστημα αρχείων διαχειρίζεται την κοινή χρήση, ενώ η αρχιτεκτονική των εφαρμογών παραμένει ανεξάρτητη.
Η υπογραφή κώδικα παραλίγο να εξανεμίσει την εξοικονόμηση
Η κλωνοποίηση της εφαρμογής ήταν μόνο ένα μέρος του προβλήματος. Οι εφαρμογές macOS πρέπει επίσης να έχουν υπογραφή κώδικα.
Η παλιά μας διαδικασία δημιουργίας υπέγραφε εκ νέου, σε όλα τα επίπεδα, κάθε πακέτο εφαρμογής μετά την προσαρμογή του. Για ένα κανονικό αντίγραφο, αυτό δεν δημιουργεί πρόβλημα. Ωστόσο, όταν η αποθήκευση βασίζεται στην αντιγραφή κατά την εγγραφή, η τροποποίηση ενός μεγάλου δυαδικού αρχείου μπορεί να αναγκάσει το APFS να δεσμεύσει νέα φυσικά μπλοκ γι’ αυτό.
Κατά την ανάπτυξη, μετρήσαμε ότι η εκ νέου υπογραφή του πλαισίου Electron πρόσθετε περίπου 194 MB φυσικού χώρου αποθήκευσης ανά εφαρμογή. Είχαμε αποφύγει με επιτυχία την αντιγραφή του Electron κατά τη δημιουργία της εφαρμογής, μόνο και μόνο για να αντιγράψουμε ξανά μεγάλο μέρος του κατά την υπογραφή.
Επομένως, έπρεπε να αλλάξει και η διαδικασία υπογραφής.
Το μεγάλο, κοινό πλαίσιο υπογράφεται πλέον ως μέρος της βασικής εφαρμογής Photon. Όταν η εφαρμογή για υπολογιστές κλωνοποιεί αυτή τη βάση, αποφεύγουμε να τροποποιήσουμε τα μεγάλα, κοινόχρηστα δυαδικά αρχεία και υπογράφουμε εκ νέου μόνο τα μικρότερα μέρη που πράγματι χρειάζεται να διαφέρουν μεταξύ εφαρμογών.
Μόλις ολοκληρωθεί η εφαρμογή, εκτελούμε αυστηρή επαλήθευση υπογραφής στο τελικό πακέτο, για να βεβαιωθούμε ότι όλα παραμένουν έγκυρα.
Έτσι διατηρούμε τόσο τις εγγυήσεις της υπογραφής κώδικα του macOS όσο και την εξοικονόμηση χώρου που προσφέρει το APFS.
Όταν ζητήσαμε από το Node.js να κλωνοποιήσει, αλλά δεν κλωνοποίησε
Υπήρχε και άλλο ένα απρόσμενο πρόβλημα: η ίδια η κλωνοποίηση.
Το Node.js παρέχει σημαίες αντιγραφής που έχουν σχεδιαστεί για να ζητούν συμπεριφορά αντιγραφής κατά την εγγραφή, όπως οι COPYFILE_FICLONE και COPYFILE_FICLONE_FORCE. Θεωρητικά, έμοιαζαν ακριβώς με τα API που χρειαζόμασταν.
Στις δοκιμές μας με το Node.js 24, αντιγράψαμε την ίδια εφαρμογή Electron των 288 MB με διάφορες μεθόδους και μετρήσαμε πόσο επιπλέον φυσικό χώρο στον δίσκο κατανάλωσε κάθε ενέργεια:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Και οι δύο λειτουργίες κλωνοποίησης του Node.js εξακολουθούσαν να παράγουν ένα πλήρες φυσικό αντίγραφο στη δοκιμή μας, ενώ ακόμη και η παραλλαγή FORCE δεν ανέφερε σφάλμα όταν δεν πραγματοποιήθηκε η αναμενόμενη κλωνοποίηση.
Η εγγενής εντολή cp -c του macOS λειτούργησε όπως αναμενόταν, οπότε η εφαρμογή WebCatalog για υπολογιστές χρησιμοποιεί απευθείας αυτόν τον μηχανισμό.
Ήταν επίσης μια χρήσιμη υπενθύμιση ότι οι βελτιστοποιήσεις του συστήματος αρχείων πρέπει να επαληθεύονται με μετρήσεις στο ίδιο το σύστημα αρχείων. Το ότι καλούμε ένα API που ζητά αντιγραφή κατά την εγγραφή δεν σημαίνει απαραίτητα ότι τα αρχεία που προκύπτουν μοιράζονται πράγματι φυσικό χώρο αποθήκευσης.
Ασφαλής εναλλακτική όταν η βελτιστοποίηση αποτυγχάνει
Η εξοικονόμηση χώρου στον δίσκο είναι βελτιστοποίηση. Η επιτυχής εγκατάσταση μιας εφαρμογής δεν είναι.
Σχεδιάσαμε τη νέα διαδικασία έτσι ώστε η κλωνοποίηση να μπορεί να αποτύχει χωρίς να εμποδίζει την εγκατάσταση της εφαρμογής. Αν αποτύχει η προετοιμασία της βασικής εφαρμογής Photon, αν η αποθηκευμένη στην προσωρινή μνήμη βάση έχει υποστεί ζημιά, αν αποτύχει η κλωνοποίηση ή αν η επαλήθευση υπογραφής δεν περάσει, η εφαρμογή για υπολογιστές επιστρέφει στην προηγούμενη διαδικασία δημιουργίας, με πλήρη αποσυμπίεση και πλήρη υπογραφή.
Έτσι, στη χειρότερη περίπτωση, η χρήση δίσκου είναι ίδια με πριν· δεν αποτυγχάνει η εγκατάσταση.
Έπρεπε επίσης να λάβουμε υπόψη την ταυτόχρονη εκτέλεση. Μια βασική εφαρμογή Photon προετοιμάζεται πρώτα σε έναν προσωρινό κατάλογο και μεταφέρεται στην τελική της θέση μόνο όταν ολοκληρωθεί. Έτσι, δύο εφαρμογές που δημιουργούνται ταυτόχρονα δεν μπορούν κατά λάθος να βρουν μια μισοέτοιμη βάση.
Και οι παλιότερες βάσεις μπορούν να αφαιρεθούν με ασφάλεια. Ένας εγκατεστημένος κλώνος APFS δεν εξαρτάται από το αν η αρχική βάση εξακολουθεί να υπάρχει. Αν διαγραφεί η βάση, ο κλώνος διατηρεί τα φυσικά μπλοκ που εξακολουθεί να χρησιμοποιεί.
Αυτό λειτουργεί στο APFS, το προεπιλεγμένο σύστημα αρχείων σε κάθε σύγχρονο Mac. Αν οι εφαρμογές σας βρίσκονται σε δίσκο που δεν υποστηρίζει κλωνοποίηση, όπως μια εξωτερική μονάδα HFS+ ή exFAT, η εφαρμογή WebCatalog για υπολογιστές χρησιμοποιεί μια κανονική αντιγραφή. Έτσι, οι εφαρμογές λειτουργούν όπως πριν, αλλά δεν εξοικονομούν χώρο. Προς το παρόν, δεν αλλάζει τίποτα σε Windows και Linux.
Το λογικό και το φυσικό μέγεθος δεν είναι το ίδιο
Μια κάπως παραπλανητική παρενέργεια είναι ότι το Finder μπορεί ακόμη να αναφέρει πως κάθε εφαρμογή καταλαμβάνει περίπου 320 MB.
Αυτός ο αριθμός αντιπροσωπεύει το λογικό μέγεθος της εφαρμογής. Η εφαρμογή πράγματι περιέχει αρχεία συνολικού μεγέθους περίπου 320 MB και, αν αυτά τα αρχεία αντιγράφονταν κάπου χωρίς κλωνοποίηση, περίπου τόσα δεδομένα θα έπρεπε να εγγραφούν.
Αυτό που άλλαξε είναι το φυσικό μέγεθος: πόσα μοναδικά μπλοκ καταλαμβάνουν πραγματικά αυτά τα αρχεία στον δίσκο.
Αν δύο εφαρμογές περιέχουν το ίδιο πλαίσιο των 300 MB και το APFS τους επιτρέπει να μοιράζονται τα ίδια υποκείμενα μπλοκ, καθεμία μπορεί λογικά να περιέχει 300 MB, ενώ η δεύτερη δεν προσθέτει σχεδόν καθόλου νέα φυσικά δεδομένα.
Η προβολή «Λήψη πληροφοριών» του Finder και εργαλεία όπως το du δεν εμφανίζουν απαραίτητα αυτή την κοινή χρήση. Η εξοικονόμηση φαίνεται πιο καθαρά στον ελεύθερο χώρο που πράγματι απομένει στον δίσκο.
Το επαληθεύσαμε με επτά πραγματικές εφαρμογές: Discord, Facebook, Instagram, Messenger, TikTok και δύο προσαρμοσμένες εφαρμογές. Με αυτόν τον τρόπο δημιουργίας, εξοικονόμησαν περίπου 1,9 GB χώρου στον δίσκο σε σύγκριση με την παλιά διαδικασία.
Ελέγξαμε επίσης τις θέσεις των δεδομένων στον φυσικό δίσκο και επιβεβαιώσαμε ότι οι εφαρμογές μοιράζονταν τα κοινά τους δεδομένα Electron και Photon σε επίπεδο μπλοκ. Μια εφαρμογή που δημιουργήθηκε με την παλιά διαδικασία δεν μοιραζόταν κανένα από αυτά τα μπλοκ, προσφέροντάς μας ένα χρήσιμο μέτρο σύγκρισης.
Το αποτέλεσμα
Για κάποιον που δημιουργεί μόνο μία εφαρμογή με το WebCatalog για υπολογιστές, η διαφορά είναι μικρή. Η πρώτη εφαρμογή καταλαμβάνει μάλιστα λίγο περισσότερο χώρο στον δίσκο από πριν, επειδή η εφαρμογή για υπολογιστές διατηρεί επίσης τη βασική εφαρμογή Photon που χρησιμοποιείται για τη δημιουργία των επόμενων κλώνων.
Στη συνέχεια, το όφελος αυξάνεται γρήγορα.
Πριν
1 εφαρμογή ~320 MB
10 εφαρμογές >3 GB
Με κλωνοποίηση APFS:
Μετά
1 εφαρμογή ~340 MB
10 εφαρμογές ~360 MB
Μετά τη δημιουργία της αρχικής βάσης, κάθε επιπλέον εφαρμογή προσθέτει συνήθως μόνο 1–2 MB φυσικής χρήσης δίσκου.
Το σημαντικό είναι ότι το πετύχαμε χωρίς να εισαγάγουμε εξάρτηση από ένα κοινό περιβάλλον εκτέλεσης. Κάθε εφαρμογή παραμένει μια κανονική, αυτοτελής εφαρμογή macOS, ενώ το APFS αποθηκεύει τα πανομοιότυπα δεδομένα του Electron και του Photon μόνο μία φορά. Με περίπου δέκα εγκατεστημένες εφαρμογές, αυτό μπορεί να μειώσει την πραγματική χρήση δίσκου σε λιγότερο από το ένα όγδοο.
Η δυνατότητα είναι διαθέσιμη στην τελευταία έκδοση της εφαρμογής WebCatalog για υπολογιστές στο macOS. Δεν χρειάζεται να ενεργοποιήσετε τίποτα: οι νέες εφαρμογές τη χρησιμοποιούν αυτόματα, ενώ οι εφαρμογές που έχετε ήδη θα καταλαμβάνουν λιγότερο χώρο την επόμενη φορά που θα ενημερωθούν.