Profilowanie i zmniejszanie frameworka iOS

Państwa kod Kotlin trafia do iOS jako binarny framework. Zbyt duży framework spowalnia uruchamianie aplikacji i zwiększa rozmiar pobierania, więc jego odchudzenie się opłaca.

Nie można zmniejszyć czegoś, czego się nie zmierzyło. Proszę sprawdzić rozmiar zbudowanego pliku .framework, aby każda późniejsza zmiana miała wartość do porównania.

Zawsze profilujcie framework release. Buildy debug pomijają optymalizację i zawierają dodatkowe symbole, przez co dają mylące, znacznie większe rozmiary.

Tabele symboli pomagają w debugowaniu, ale zwiększają rozmiar binariów. Ich stripowanie na potrzeby produkcji zmniejsza framework bez wpływu na jego działanie.

Każda biblioteka dodana do commonMain trafia również do iOS. Każda zależność dodaje bajty, dlatego proszę usuwać te, których naprawdę Państwo nie potrzebują.

Kompilator Kotlin/Native usuwa nieosiągalny kod. Ograniczenie publicznego API pomaga mu usunąć większą część tego, czego iOS nigdy nie wywołuje.

Proszę oznaczać pomocnicze elementy jako internal, a nie publiczne. Eksportowanych deklaracji nie można usunąć, więc wąski interfejs oznacza lżejsze binaria.

Rozmiar to jedno, a szybkość to drugie. Proszę użyć Xcode Instruments, aby sprawdzić, ile naprawdę trwa ładowanie i inicjalizowanie frameworka.

Kod uruchamiany podczas ładowania frameworka opóźnia start aplikacji. Proszę zachować leniwą inicjalizację, aby praca odbywała się dopiero przy pierwszym użyciu funkcji.

Firma Apple zrezygnowała z bitcode, więc nie trzeba go już dołączać. Proszę upewnić się, że stare ustawienia builda nie zwiększają nadal rozmiaru frameworka bez powodu.

Rozmiar po cichu rośnie. Proszę zapisywać rozmiar frameworka w CI, aby nagły wzrost wskazał commit, który dodał zbędny ciężar.

Proszę przypomnieć sobie, która konfiguracja builda zapewnia wiarygodny odczyt rozmiaru.

Zmierzono framework release, usunięto symbole, ograniczono zależności i publiczne API, sprofilowano uruchamianie w Instruments oraz śledzono rozmiar w CI. 📉