WWDC22 state of the union prometteva molte migliorie per migliorare i tempi di avvio dell’applicazione.
with apps like Lyft or Airbnb launching almost twice as fast thanks to improvement in the dynamic linker.
Questo miglioramento deriva dalla velocizzazione dei controlli di protocollo. iOS 16 migliora il tempo di caricamento di un binario riducendo la quantità di dati caricati dal disco.
Questi miglioramenti sono dovuti a cambiamenti in dyld, il programma responsabile dell’avvio dell’applicazione e dell’avvio dell’esecuzione del codice. Inoltre, adottano due approcci opposti (ma comuni) per migliorare le prestazioni: l’eager loading e la lazy evaluation.
Verifiche di protocollo
I controlli di conformità al protocollo avvengono nel runtime di Swift per determinare il risultato di un codice come myVar as? MyProtocol. Ogni volta che un tipo è conforme a un protocollo, il binario include un “record di conformità”. Quando si verifica una conformità, il runtime esegue un loop su ogni record di conformità per vedere se qualcuno corrisponde all’operazione corrente. Questo ciclo è O(n), dove n è il numero di record di conformità dell’applicazione. Nelle applicazioni di grandi dimensioni possono essere più di centomila, rendendo ogni controllo di conformità molto lento.
I controlli di conformità del protocollo sono molto diffusi nelle applicazioni Swift, anche se non li scrivete voi, perché vengono invocati anche da operazioni comuni come String(describing:) o AnyHashable. Per alcune applicazioni Swift di grandi dimensioni, come Lyft e Airbnb, quasi la metà del tempo di lancio viene impiegato per i controlli di conformità del protocollo.
Il grande cambiamento riguarda la “chiusura dyld”, una cache per app utilizzata per accelerare varie operazioni dyld durante il lancio dell’app. La closure contiene ora le conformità precalcolate, consentendo di velocizzare ogni ricerca.
Page faults
Il secondo grande miglioramento deriva dalla riduzione della quantità di dati che devono essere caricati dal disco all’avvio. La prima volta che un pezzo di codice viene eseguito, il kernel carica il pezzo di memoria circostante, noto come pagina, in un processo chiamato page fault. All’avvio dell’app, alcune parti del binario devono essere sistemate prima che il codice possa essere eseguito. Su iOS 15 tutte le correzioni venivano effettuate all’avvio dell’app, il che significava che qualsiasi punto del binario che richiedeva una correzione doveva essere inserito nella pagina. Ora, una nuova funzione chiamata page-in linking risolve le correzioni in modo pigro, solo la prima volta che si accede a una pagina.
Riassumendo
Sono migliorati i tempi di avvio di una media del 18% rispetto a quando abbiamo provato a distribuire un binario su AppStore di iOS 15. Ora che iOS 16 non carica automaticamente ogni pagina, può rendere il tempo di avvio dell’app ancora più veloce!