Milisekundy vydělávají miliony: Jak a proč zrychlit vaši aplikaci, z InDrive Playbook

Ahoj všichni, jmenuji se Vladimir Pchelyakov, jsem inženýr iOS na inDrive. V tomto článku budu hovořit o tom, jak čas spuštění aplikace ovlivňuje příjmy společnosti, jak jsme urychlili naši aplikaci a budu pokrývat nástroje, přístupy, stejně jako skutečné situace a samozřejmě výsledky. Tento článek může sloužit jako plán pro každý tým, který chce urychlit čas spuštění aplikace a kritickou cestu uživatele, protože problémy, které jsme vyřešili, pravděpodobně existují ve většině neoptimalizovaných projektů. Z hlediska kontextu můžete v aplikaci inDrive objednat taxi jako cestující, nebo můžete přijímat objednávky a jezdit jako řidič. V tomto článku se budu zabývat: Jak startovací doba ovlivňuje příjmy společnosti Druhy spuštění aplikace Čas spuštění aplikace, TTI a čas spuštění Průměrná hodnota a percentil Co ovlivňuje čas spuštění Cyklus zrychlení aplikací Nejúčinnější způsoby, jak zrychlit Nástroje, procesy, situace Výsledky Jak start-up čas ovlivňuje příjmy společnosti Většina lidí si myslí, že vývojáři jsou „příliš posedlí optimalizacemi“, které nepřinášejí žádnou skutečnou hodnotu.Data však ukazují, že urychlení věcí o stovky milisekund může ovlivnit podniky téměř stejně jako spuštění nové funkce nebo vstup na nový trh. InDrive výzkum Uvnitř společnosti jsme provedli rozsáhlou studii, která ukázala, že zrychlení kritické cesty cestujícího o 750 ms zvyšuje počet objednávek o 1,5%. Deloitte výzkum Deloitte zveřejnil některá velmi působivá čísla: zrychlení mobilní webové stránky o 100 ms dává +8,5% konverze v e-commerce, a +10% v cestování. Navíc některé společnosti záměrně zpomalily aplikaci pro určité skupiny uživatelů, aby dokázaly hypotézu: čím rychleji se aplikace spustí, tím více objednávek uživatel provádí.A hypotéza byla potvrzena.Pokud jste vždy chtěli pracovat na urychlení aplikace, ale neměli silné argumenty, nyní je máte. Typy spuštění aplikace Typ spuštění aplikace přímo ovlivňuje metriku, takže je důležité je rozdělit. Apple neposkytuje přímé rozhraní API pro určení typu spuštění, takže každý tým to dělá svým vlastním způsobem. Studený start Plné načítání aplikace od začátku, nejpomalejší typ spuštění. Proces aplikace nebyl přítomen, není tam žádná vyrovnávací paměť, vše je inicializováno od začátku. Například toto je první spuštění po stažení z obchodu nebo po několika hodinách nebo více poté, co byla aplikace stažena z paměti. Cold Launch je jediná čestná metrika, která může být srovnávána z jedné verze na druhou, aby bylo možné vyvodit závěry. Horký start Aplikace byla nedávno ukončena, takže žádný proces neexistuje. Nicméně, části aplikace zůstávají částečně v paměti - systémové vyrovnávací paměti a dynamický linker cache jsou stále teplé. K tomu dochází, když aplikaci stáhnete z paměti a téměř okamžitě ji znovu otevřete, otevírá se znatelně rychleji.Tato metrika závisí příliš na mnoha faktorech, takže pro nás nefunguje. Horký start Aplikace byla jednoduše minimalizována a znovu otevřena. zde není co měřit, aplikace se otevírá okamžitě a neprochází žádnou cestou, je již na správném místě. předehřátí Zní to užitečně, ale způsobuje spoustu problémů: měli jsme "startu" 15 minut a 10 hodin, protože předehřívání vytvořilo proces předem a vypočítali jsme čas z proměnné, která byla vytvořena v hlavním souboru, a uživatel aplikace nespustil okamžitě, ale po desítkách hodin. Zpočátku jsme nemohli pochopit, kde byla chyba a jak by čas spuštění mohl být rovný hodinám, a to také vážně zkazilo statistiky, protože ostatní údaje jsou měřeny v ms a metriky s hodinami opravdu zkazily obraz. Be careful, Prewarm can completely ruin the statistics. Čas spuštění aplikace, TTI a čas spuštění Když jsme začali pracovat na urychlení věcí, ukázalo se, že i základní pojmy byly chápány odlišně každým. Čas spuštění aplikace Důležité: Nejedná se o obrazovku spouštění systému, která se okamžitě zobrazí, ale o náš ovládací prvek kořenového zobrazení – okamžik, kdy je provedeno propojení knihovny, metody AppDelegate jsou dokončeny, je vytvořen ovládací prvek zobrazení a metoda zobrazeníDidAppear je spuštěna. TTI (Time to Interactive) – čas na interakci Můžete to také nazvat kritickou cestou, protože ovlivňuje začátek vytváření nebo zpracování objednávky a to je to, co ovlivňuje obchodní metriky. Tato cesta je pro každou aplikaci jiná, protože každý má jiný koncový bod a je vybrán na základě jeho dopadu na podnikání. Například v našem případě: Pro cestující - když se zobrazí mapa a uživatel může klepnout na "Kam jít".Čím rychleji se to stane, tím pravděpodobnější je, že cestující vytvoří objednávku. Pro řidiče – když se zobrazí obrazovka s příkazy cestujících.Čím rychleji k tomu dojde, tím je pravděpodobnější, že řidič uvidí a přijme objednávku včas. Hang Time To je doba, kdy rozhraní "zmrazí" - tlačítko je klepnut, ale akce se nestane okamžitě, například to trvá vteřinu. Obvykle je to výsledek těžkých výpočtů na hlavním drátu. A ano, Závěsný čas přímo ovlivňuje TTI, protože zmrazení se objeví nejen když uživatel klepne na tlačítko, ale také když něco na kritické cestě zaujme hlavní drát a rozhraní uživatele zmrazí během renderování. Průměrná hodnota a procento Po shromažďování dat od milionů uživatelů musíte nějakým způsobem interpretovat tyto metriky a existují nejméně 2 možnosti: průměrná hodnota a percentily. Proč průměr nepřináší celý obraz Průměr se zdá pohodlný a snadno vypočítatelný, ale někdy je těžké z něj vyvodit závěry. Zde je příklad: Máme 5 uživatelů a čas spuštění pro 5 uživatelů = 1, 2, 3, 9, 12 sekund. Průměrné hodnocení = 5,4 sec. But this does not reflect reality: 3 z 5 uživatelů spustí aplikaci za 3 sekundy nebo rychleji. 2 uživatelé jsou velmi pomalý a zkreslit celou statistiku. A pokud je jeden start zaznamenán jako "1 hodina" (nebo nekonečnost přichází kvůli metrické chybě), průměr se stává zcela bezvýznamným. Jak percentily fungují a proč jsou přesnější Percentil ukazuje, kolik času aplikace potřebuje, aby se X procent uživatelů vešlo do této doby. Na stejných 5 hodnotách: 1, 2, 3, 9, 12 50th percentile = 3 sekundy → polovina uživatelů spustí aplikaci za 3 sekundy nebo rychleji. 80th percentile = 9 sekund → 80% uživatelů vidí aplikaci za ≤ 9 sekund. 99. percentil = 12 sekund → „nejtěžší“ uživatelé: slabá zařízení, špatný internet. Kromě hlavního množství uživatelů se vždy snažíme urychlit 95. percentil, abychom zlepšili životy lidí, jejichž aplikace načte nejdelší dobu, s největší pravděpodobností kvůli zařízení nebo špatnému internetu v jejich zemi. Mimochodem, poznamenám, že působíme ve 47 zemích po celém světě a máme mnoho zemí, kde mnoho uživatelů má slabá zařízení a špatný nestabilní internet. Co ovlivňuje čas spuštění Podívejme se na hlavní oblasti, které mohou výrazně zpomalit aplikaci. Požadavky sítě Počet požadavků v řetězci, pořadí požadavků, schopnost cache, rychlost internetu. Inicializace aplikace Na startu probíhá obrovské množství operací: propojení knihovny, spuštění běhu Objective-C, Swift Reflection, inicializace SDK (analytika, reklamy, Firebase), načítání dylib, dyld, rebase, vázání symbolů, inicializace DI kontejnerů. Hlavní hrozba Jakékoliv těžké operace na hlavním drátu zvyšují TTI: JSON dekódování velkých a složitých modelů, synchronní hovory, zbytečné výpočty „na startu“, protože to bylo pohodlné, i když je lze přesunout někam jinam. Charakteristika zařízení Nemůžeme zrychlit stará zařízení, ale můžeme pro ně přizpůsobit logiku nebo snížit množství zatížení. Zajímavý fakt: pro země se slabými zařízeními a pomalým internetem, Meta vydala aplikaci Facebook Lite. Cyklus zrychlení aplikací Chcete-li urychlit aplikaci, musíte systematicky měřit a zlepšovat, ne "opravovat věci očima". Náš cyklus vypadá takto: Mark up the app for data collection App Launch Splash TTI of all verticals (critical paths) Steps of the critical path Collect and visualize data Raw telemetry data Long-term storage, Big Query Monitor Xcode Organizer Find places of slowdown Instruments: LaunchTime, Profile, Network, Hangs Timeline analysis Fix problems Restructure requests Cache Offload the main thread Remove everything unnecessary from startup Experimenty běží Compare results, verify hypotheses Control startup time before a new release UI-performance tests on CI, alerts on degradations This way, from version to version the app becomes faster, more stable and more predictable. Of course, markup and visualization are not done in every cycle. Nejúčinnější způsoby, jak zrychlit Největší účinek přichází z několika zřejmých, ale systematicky provedených kroků: Změna pořadí požadavků na síť Cachingové požadavky na síť Odstranění hlavního tématu Odstranění těžkých počítačů při startu To jsou přesně ty změny, které nám přinesly maximální zlepšení TTI s minimálním úsilím a rizikem, že něco zlomíme. Nástroje, procesy a situace V této kapitole vám řeknu o našich nástrojích a procházím několika skutečnými příklady, ve kterých vám ukážu, jak jeden nástroj doplňuje druhý a jak každý z nich vypadá. Optimalizace je nemožná bez měření. Nejprve musíte projekt označit. Uvnitř naší aplikace jsou označeny klíčové fáze zahájení: AppLaunchTracker – spuštění aplikace, dokud se neobjeví první ovladač. SplashTracker - doba různých fází splashové obrazovky (získání funkcí, profil, určení umístění). CriticalPathTracker – kritická cesta uživatele s rozdělením kroků a časem mezi nimi VerticalsTTITracker – TTI pro každý produkt vertikální. Veškerá data jsou vizualizována v grafech a dashboardech (Kibana, Redash). Kromě toho jsme vytvořili procesy: Porovnání verzí podle výkonu Testy výkonu UI na CI Varování před degradací Pravidelné týdenní schůzky a plán urychlení Používáme nativní nástroje: Xcode Instruments – LaunchTime, Profil, Síť, Hangs Xcode Organizer – Hangs, spuštění aplikace Doporučuji také vytvořit cestovní mapu, abychom pochopili pořadí provádění úkolů. Nyní se podívejme na všechno v akci. Práce s požadavky na síť Jedním z nejúčinnějších způsobů, jak urychlit TTI, je přepracování pořadí síťových požadavků a spuštění nezávislých požadavků souběžně. Pro analýzu jsme použili Xcode Instruments → Network, kde můžete jasně vidět, jaké jsou požadavky a jejich závislosti. Co jsme udělali: Způsobuje specifický tok zachytil stopu síťových požadavků překryl okamžiky, kdy se na něm objevily obrazovky Poté jsme šli do produktového týmu, ukázali výsledky, diskutovali o tom, jak optimalizovat pořadí síťových požadavků a poté vytvořili úkoly. Jednoduchý případ Žádost, na které první obrazovka závisela, byla odeslána příliš pozdě. Může být přesunuta na začátek životního cyklu obrazovky, protože ve skutečnosti neměla žádnou závislost. Na Androidu jsme našli klasický "schodiště": toggles → driver config → důvody → nabídky Všechny požadavky šly striktně sekvenčně. teprve poté začalo načítání objednávek. Řešení : Spojte několik požadavků do jednoho nebo spustit požadavky souběžně, pokud neexistují žádné závislosti. Nejjednodušším a nejúčinnějším způsobem je odstranit umělou sekvenci tam, kde není potřeba.Existuje šance, že vývojáři napsali tuto sekvenci dávno pro pohodlí nebo z jiných důvodů, a zůstal tak, protože to nikoho neobtěžovalo. Ještě složitější případ: Řidič krmiva Původně, před naložením objednávek, byl proveden řetězec několika požadavků: Obecné taxislužby Nastavení taxikářů Kurýrní nastavení Všechny šly postupně a každá žádost zpomalila TTI, zejména na pomalém internetu to bylo patrné, protože každá ze tří žádostí zvýšila celkový čas cesty. Spojili jsme se s týmem a výrazně zjednodušili schéma: Souběžně byly zahájeny nezávislé žádosti Spojení dvou požadavků do jedné žádosti A jen ve vzácných případech bychom museli čekat na paralelní žádost, ale i tehdy, to bylo spuštěno paralelně s prvním, ne od začátku po prvním. V důsledku toho: Místo tří po sobě jdoucích žádostí byla jedna v nejlepším případě v nejhorším případě – o jednu žádost méně než dříve Poté jsme provedli experiment a výsledek: TTI acceleration of 0.5–0.8 seconds on average na 95. percentilu – až 2 sekundy Timelines Grafy podle verzí ukazují, že aplikace se stala rychlejší nebo pomalejší, ale neodpovídá na otázku proč. Pro vyřešení tohoto problému používáme časové řádky - rozdělení TTI po fázích. to znamená, že shromažďujeme všechny hlavní fáze kritické cesty: Spuštění aplikace Delegované metody Hledání Toggles Získání umístění Získání profilu Navigace do modulu module initialization Rendering obrazovky To nám umožňuje přesně vidět: Která fáze se zrychluje Kde se objevila regrese Co přesně ovlivnilo finální TTI It is timelines that allow us to safely make large changes and understand their consequences. This also became the basis for decision-making and finding regressions or places for acceleration — the longest pieces interest us the most. To je velmi dobrá úroveň detailů, ale naplánujte je, aby byly okamžitě podrobné a vysoce kvalitní, protože jejich změna později bude nepohodlná a porovnání grafů s předchozím rozdělením bude nemožné. Oznámení o spuštění aplikace a odstranění tajfunu Zpráva o spuštění aplikace Xcode ukazuje, který kód zpomaluje spuštění. V našem případě: DI kontejner Typhoon vzal ~30% času startu některé z jeho inicializací se důsledně objevovaly na nejpomalejších místech After removing Typhoon: První fáze startu byla zkrácena téměř třikrát, z ~1,3 sekundy na ~445 ms ve verzi 5.122. Na časovém řádku můžete vidět, jak se první fáze zrychlila třikrát, ale celkový TTI se zvětšil. Kdybychom neměli rozpad, nepochopili bychom, co se děje a jak by odstranění DI mohlo vše zpomalit. Závěrečná sazba Nyní můžeme vidět, jak jeden nástroj doplňuje jiný – časové řádky poskytly obraz, že spuštění urychlilo, ale dále něco narušilo a ovlivnilo několik počátečních fází. Ukázalo se, že nová verze aplikace začala výrazně zpomalovat.Něco blokovalo hlavní vlákno.Nástroj ukazuje, že 92% času spánku pocházelo z SDK třetí strany. Kromě toho poukazuje na konkrétní linii. Důvod - síťová žádost od třetí strany knihovny na hlavním drátu s čekáním na odpověď serveru až 10 sekund. Problém se reprodukoval pouze na pomalém internetu, takže to šlo bez povšimnutí našimi testéry a vývojáři, protože každý má rychlý internet na notebooku a zařízeních. S knihovnou jsme podali problém a po opravě se Hang Rate vrátil do normálu. výzkumu Čas od času profilujeme hlavní uživatelskou cestu tím, že ji spustíme na různých zařízeních, a vypadá to zhruba takto. Zde jsme našli mikro-mrazy a okamžitě vidíme, které fáze kritické cesty ovlivňují. Ukázalo se, že určitý kód pro práci s umístěním uživatele silně zatěžoval hlavní drát. Opravili jsme problém, náhodné mikro-mrazy zmizely a rychlost Hang se stala ještě nižší. Stejně tak byla snížena fáze sběru profilu z 480 ms → 21 ms. Testy výkonu UI na CI Nalezení problémů a jejich řešení je dobré, ale ještě lepší je dozvědět se o zpomalení předtím, než aplikace přejde do App Store, a dokonce i předtím, než začne regrese verzí. Udělali jsme nativní test uživatelského rozhraní, který prochází reálným scénářem na výrobním serveru a odesílá stejné metriky jako pro výrobní verzi. prochází skutečnou uživatelskou cestou na klíčovou obrazovku runs at night Několikrát běží bez síťových šmejdů Odesílání metriky do telemetrie Pokud čas překročí prahovou hodnotu, přichází na Slack upozornění. To dává možnost zachytit problém před vydáním, který je v současné době nejdůležitějším prvkem celého systému.Vidíme také všechny stejné časové řádky a test je co nejblíže reálným podmínkám použití. Také, abychom se ujistili, že naše vyrovnávací paměť funguje dobře, přidali jsme internetové šroubování na CI - nejprve test běží normální rychlostí, vše je vyrovnávací paměť, pak totéž, ale na 3G pomalém internetu. Podle mého názoru je to jedna z nejdůležitějších součástí práce na rychlosti spuštění - nedovolte, aby taková verze šla k vydání. Dále chceme spustit toto na každém Pull Request asynchronně, aby nedošlo k zablokování fúze, protože testy výkonu běží na stejném Mac Mini, aby měření byla upřímná, a s velkým týmem by tam byla čára. Srovnání verzí Před přidáním nové závislosti do projektu máme proces srovnávání verzí – instrukce pro vývojáře, jak porovnat aktuální verzi aplikace a tu s novou přidanou závislostí. Jednou během takového běhu jsme viděli 250 ms nárůst při spuštění aplikace a rozhodli se tuto funkci zavést pouze dočasně a pouze na část uživatelů, aby nedošlo k zpomalení aplikace. Toggle Caching Podívejme se na poslední případ - podívejme se na časové řádky, jedna z nejdelších etap na naší cestě je dostat funkční přepážky (700 ms), černé pruhy na grafu. Zavedli jsme progresivní vyrovnávací paměť: pokud jsou přepínače čerstvější než po určitou dobu – používáme vyrovnávací paměť. Samozřejmě provádíme A/B experiment, který ukazuje zlepšení. Výsledek : fáze přepínání byla snížena ve verzích 126–127 TTI became noticeably faster users who open the app frequently and those with slow internet benefited the most. Graf ukazuje, jak se řidiči přepínají. Stala se tak malou, protože aplikace otevřou velmi často. Dopravní světla a rychlá státní kontrola Když je příliš mnoho metrů, potřebujete agregáty. Používáme „dopravní světla“. They use complex aggregation formulas per day, automatic evaluation of improvements and degradations. I will not describe all of this now since it would take a lot of time, but globally it is all for a quick answer to the question: "what happened with the version". Například na jedné z verzí došlo k viditelnému výjimečnému nárůstu TTI - výsledku odkládání hlavního drátu. Konečné výsledky Let us look at our results over half a year of work. Od začátku roku do září (verze 115 → 140): doba od spuštění aplikace k přechodu na produkt vertikálně (50. percentil) se zkrátila téměř třikrát: 2,8 sec → 1 sec Podíl uživatelů s startem rychlejším než 5 sekund: 58% → 84% U 75 procent uživatelů se aplikace spustí za 4 sekundy a dříve to bylo 6,2 sekundy. At the same time, improvements happened gradually from version to version, except for one bug spike, which we quickly caught thanks to the tools.The percentage of users who run the app on cold starts faster than 5 seconds. Conclusion Zrychlení aplikace není jednorázová optimalizace, ale nepřetržitý proces: Jasné metriky Srozumitelné časy Automatické ovládání před propuštěním Pravidelné analýzy a experimenty A nejdůležitější věc – zrychlení o stovky milisekund opravdu ovlivňuje podnikání.