Hallo almal, my naam is Vladimir Pchelyakov, ek is 'n iOS-ingenieur by inDrive. In hierdie artikel sal ek praat oor hoe app-start tyd die inkomste van die maatskappy beïnvloed, hoe ons ons app versnel, en ek sal die gereedskap, benaderings, sowel as werklike situasies en natuurlik die resultate dek. Hierdie artikel kan dien as 'n plan vir enige span wat die app-lancering tyd en die gebruiker se kritieke pad wil versnel, want die probleme wat ons opgelos het, bestaan waarskynlik in die meeste nie-geoptimaliseerde projekte. Vir konteks, in die inDrive-app kan jy 'n taxi as 'n passasier bestel, of jy kan bestellings neem en ry as 'n bestuurder. In hierdie artikel sal ek dek: 
 
 
 
 
 
 
 
 
 
 Hoe die start tyd die inkomste van die maatskappy beïnvloed Soorte app lanseer App Launch Time, TTI en Hang Time Gemiddelde waarde en persentil Wat beïnvloed die start tyd App versnelling siklus Die mees effektiewe maniere om te versnel Tools, prosesse en situasies Resultate Hoe start-up tyd beïnvloed maatskappy inkomste Most people think that developers are "too obsessed with optimizations" that bring no real value. But data shows that speeding things up by hundreds of milliseconds can affect business almost as much as launching a new feature or entering a new market. Simply put, if your app takes too long to open, some users will go to a competitor or just give up on their need. Inleiding navorsing Binne die maatskappy het ons 'n groot studie uitgevoer wat getoon het dat die versneling van die passasiers se kritieke pad met 750 ms die aantal bestellings met 1,5% verhoog. Deloitte navorsing Deloitte het 'n paar baie indrukwekkende getalle gepubliseer: die versneling van 'n mobiele webwerf met 100 ms gee +8.5% omskakeling in e-handel, en +10% in reis. Daarbenewens het sommige maatskappye die app doelbewus vertraag vir sekere groepe gebruikers om die hipotese te bewys: hoe vinniger die app begin, hoe meer bestellings die gebruiker maak. Soorte App Lancering Die tipe app-lancering beïnvloed direk die metrieke, dus is dit belangrik om hulle afsonderlik te vertel. Apple bied nie 'n direkte API vir die bepaling van die tipe lanseer nie, so elke span doen dit op sy eie manier. Koue lancering Volledige lading van die app van die kern af, die langsame tipe lancering. Die app proses was nie teenwoordig nie, daar is geen cache nie, alles word van die begin af geïmplementeer. Byvoorbeeld, dit is die eerste lancering na aflaai van die winkel, of na 'n paar uur of meer nadat die app uit geheue afgelaai is. Cold Launch is die enigste eerlike metric wat van weergawe tot weergawe vergelyk kan word om gevolgtrekkings te trek. Warm begin Die app is onlangs beëindig, so geen proses bestaan nie. Maar dele van die app bly gedeeltelik in geheue - stelselcaches en die dinamiese koppelaarcache is nog warm. Dit gebeur wanneer jy die app uit die geheue laai en dit byna onmiddellik weer oopmaak, dit oopmaak merkbaar vinniger. Warm begin Daar is niks om hier te meet nie, die app oopmaak dadelik en gaan nie deur enige pad nie, dit is reeds op die regte plek. Voorverwarming Dit klink nuttig, maar dit veroorsaak baie probleme: ons het "lancerings" van 15 minute en 10 uur gehad, want prewarm het die proses vooraf geskep, en ons het die tyd bereken van 'n veranderlike wat in die hoofbestand geskep is, en die gebruiker het nie dadelik die app begin nie, maar na tien uur. Aanvanklik kon ons nie verstaan waar die fout was en hoe die lanseer tyd kan gelyk wees aan ure, en dit het ook die statistieke ernstig bederf, want ander data word in ms gemeten, en metrikes met ure het die prentjie regtig verstoord. Wees versigtig, Prewarm kan die statistieke heeltemal ruïneer. App Launch Time, TTI en Hang Time Toe ons begin werk om dinge te versnel, het dit blyk dat selfs basiese terme deur almal anders verstaan word. App begin tyd Belangrik: dit gaan nie oor die stelsel Launch Screen, wat dadelik verskyn nie, maar oor ons root view controller - die oomblik wanneer die biblioteekverbinding gedoen word, die AppDelegate-metodes voltooi is, die weergave-bestuurder geskep word, en die viewDidAppear-metode is aangestel. TTI (tyd om interaktief te wees) Jy kan dit ook die kritieke pad noem, want dit beïnvloed die begin van die skep of verwerking van 'n bestelling, en dit is wat die besigheidsmetrik beïnvloed. Hierdie pad is anders vir elke app, aangesien almal 'n ander eindpunt het, en dit word gekies op grond van sy impak op die besigheid. Byvoorbeeld in ons geval: Vir die passasier - wanneer die kaart verskyn en die gebruiker kan druk "Waar om te gaan". Hoe vinniger dit gebeur, hoe meer waarskynlik sal die passasier 'n bestelling skep. Vir die bestuurder – wanneer die skerm met passasiersbevelen weergegee word. Hoe vinniger dit gebeur, hoe meer waarskynlik sal die bestuurder 'n bestelling op tyd sien en neem. Hang die tyd Dit is die tyd wanneer die koppelvlak "bevrore" - 'n knoppie is gedruk, maar die aksie gebeur nie dadelik nie, byvoorbeeld neem dit 'n sekonde. Gewoonlik is dit die gevolg van swaar berekenings op die hoofdraad. En ja, Hang Time beïnvloed direk TTI, want bevrore verskyn nie net wanneer die gebruiker 'n knoppie druk nie, maar ook wanneer iets op die kritieke pad die hoofdraad beset en die UI bevrore tydens rendering. Gemiddelde waarde en persentasie Na die versameling van data van miljoene gebruikers, moet jy hierdie metrikes op een of ander manier interpreteer, en daar is ten minste 2 opsies: gemiddelde waarde en persentile. Waarom die gemiddelde nie die volledige prentjie gee nie The average seems convenient and easy to calculate, but sometimes it is hard to draw conclusions from it. Hier is 'n voorbeeld: Ons het 5 gebruikers en die opstart tyd vir 5 gebruikers = 1, 2, 3, 9, 12 sekondes. Die gemiddelde is 5,4 sek. Maar dit weerspieël nie die werklikheid nie: 3 van 5 gebruikers begin die app in 3 sekondes of vinniger. 2 gebruikers is baie stadig en skeef die hele statistieke. En as een lancering geregistreer word as "1 uur" (of oneindigheid kom as gevolg van 'n metriese fout), word die gemiddelde heeltemal betekenisloos. Hoe persentile werk en hoekom hulle meer akkuraat is 'N Percentile wys hoeveel tyd die app nodig het sodat X persent van gebruikers binne daardie tyd pas. Op dieselfde 5 waardes: 1, 2, 3, 9, 12 Die 50ste percentiel = 3 sekondes → die helfte van die gebruikers begin die app in 3 sekondes of vinniger. 80ste percentiel = 9 sekondes → 80% van die gebruikers sien die app in ≤ 9 sekondes. 99ste percentiel = 12 sekondes → die "swaarste" gebruikers: swak toestelle, slegte internet. Ons kyk na die 50ste, 75ste, 90ste en 95ste percentiel. Behalwe die hoofmassa van gebruikers, probeer ons altyd om die 95ste percentiel te versnel, om die lewe te verbeter vir mense wie se app die langste laai, waarskynlik as gevolg van die toestel of swak internet in hul land. By the way, ek sal opmerk dat ons in 47 lande regoor die wêreld werk, en ons het baie lande waar baie gebruikers swak toestelle en slegte onstabiele internet het. Wat beïnvloed die start tyd Kom ons kyk na die belangrikste gebiede wat die app aansienlik kan vertraag. Netwerk vrae Die aantal versoekings in die ketting, die volgorde van versoekings, die vermoë om te cache, internet spoed. App inisialisering By die opstart gebeur 'n groot aantal bedrywighede: biblioteekverbinding, die lancering van Objective-C runtime, Swift Reflection, SDK-initialisering (analitiek, advertensies, Firebase), laai dylib, dyld, rebase, simboolbinding, DI-container-initialisering. Die hoofdreiging Enige swaar bedrywighede op die hoofdraad verhoog TTI: JSON-dekodeer van groot en komplekse modelle, sinchrone oproepe, onnodige berekenings "by die opstart" omdat dit gerieflik was, selfs al kan hulle elders verplaas word. Kenmerke van die toestel Ons kan nie ou toestelle versnel nie, maar ons kan die logika aanpas of die hoeveelheid lading verminder. 'N Interessante feit: vir lande met swak toestelle en stadig internet, het Meta die Facebook Lite-toepassing vrygestel. App versnelling siklus Om die app te versnel, moet jy stelselmatig meet en verbeter, nie "dinge deur die oog regmaak nie". Our cycle looks like this: 
 
 
 
 
 
 
 
 
 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 Xcode Organizer vir die monitor 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 Voer eksperimente Vergelyk resultate, verifieer veronderstellings Control startup time before a new release
 
 
 
 UI-performance tests on CI, alerts on degradations Op hierdie manier word die app van weergawe tot weergawe vinniger, meer stabiel en meer voorspelbaar. Die mees effektiewe maniere om te versnel Die grootste effek kom uit 'n paar duidelike, maar stelselmatige stappe: 
 
 
 
 
 Verander die volgorde van netwerkverzoeke Caching netwerk versoek Aflaai die hoof thread Verwydering van swaar rekenaars by die start Dit is presies die veranderinge wat ons die maksimum TTI verbetering met 'n minimale poging en risiko van iets breek het. Tools, prosesse en situasies In hierdie hoofstuk sal ek jou vertel oor ons gereedskap en deur 'n paar werklike voorbeelde gaan, waarin ek sal wys hoe een gereedskap die ander aanvul en hoe elkeen daarvan lyk. Optimalisering is onmoontlik sonder metings. Eerstens moet jy die projek opmerk. Binne ons app word die sleutellanceringsfases aangeteken: 
 
 
 
 
 AppLaunchTracker – die app begin totdat die eerste bestuurder verskyn. SplashTracker - tyd van verskillende splash skerm fases (verwyder funksies, profiel, lokasie bepaal). CriticalPathTracker – die gebruiker se kritieke pad met stapverdeling en tyd tussen hulle VerticalsTTITracker — TTI vir elke produk vertikaal. Alle data word visualiseer in grafieke en dashboards (Kibana, Redash). Daarbenewens het ons prosesse ingestel: 
 
 
 
 
 version comparison by performance UI-prestasie toets op CI Waarschuwing vir degradasie regular weekly meetings and a roadmap for speeding up Ons gebruik native gereedskap: 
 
 
 Xcode Instrumente — LaunchTime, profiel, netwerk, hangers Xcode Organizer - Hangs, App Lancering Ek beveel ook aan om 'n padkaart te skep om die volgorde van taakuitvoer te verstaan. Ons lyk soos hierdie: Kom ons kyk nou na alles in aksie. Werk met die netwerk versoek bestellings One of the most effective ways to speed up TTI is to rearrange the order of network requests and run independent requests in parallel. Vir analise het ons Xcode Instrumente gebruik → Netwerk, waar jy duidelik kan sien wat versoekings gaan en hul afhanklikhede. What we did: 
 
 
 
 Die spesifieke vloei vang 'n spoor van netwerk versoekings oorskry die oomblikke wanneer skermte daarop verskyn het This way it became clear which requests actually block the UI from showing. After that we went to the product team, showed the findings, discussed how to optimize the order of network requests, and then created tasks. Eenvoudige geval A request that the first screen depended on was sent too late. It could be moved to the beginning of the screen lifecycle, because it actually had no dependency. As a result, the user would see the ready interface sooner, which means faster TTI. Op Android het ons 'n klassieke "trap" gevind: toggles → driver config → reasons → offers Alle versoekings het streng opeenvolgend gegaan. Slegs daarna het die laai van bestellings begin. Die oplossing: Kombineer verskeie versoekings in een of loop versoekings parallel as daar geen afhanklikhede is nie. Die eenvoudigste en mees effektiewe manier is om die kunsmatige volgorde te verwyder waar dit nie nodig is nie. 'N meer komplekse geval: bestuurder voedsel Oorspronklik, voor die laai bestellings, is 'n ketting van verskeie versoekings uitgevoer: 
 
 
 
 Algemene taxi instellings taxi driver settings Koerier instellings Al hulle het opeenvolgend gegaan, en elke versoek het die TTI vertraag, veral op die stadig internet dit was merkbaar, aangesien elkeen van die drie versoekte die totale pad tyd verhoog het. Ons het saam met die span gekom en die skema aansienlik vereenvoudig: 
 
 
 
 Onafhanklike versoekings is parallel gestuur kombineer twee instellings versoek in een versoek die versoek vir bestellings begin onmiddellik na die ontvangs van die minimum nodige data.En slegs in selde gevalle sal ons nodig het om te wag vir 'n parallelle versoek, maar selfs dan, dit is gelanceer in parallel met die eerste, nie van nul na die eerste. As a result: 
 
 
 In plaas van drie opeenvolgende versoekings, was daar een in die beste geval in the worst case — one fewer request than before Daarna het ons 'n eksperiment uitgevoer. 
 
 
 TTI acceleration of 0.5–0.8 seconds on average op die 95ste percentiel - tot 2 sekondes Timelyn Grafieke per weergawe toon dat die app vinniger of trager geword het, maar beantwoord nie die vraag waarom. To solve this problem we use timelines — a breakdown of TTI by stages. That is, we collect all the main stages of the critical path: 
 
 
 
 
 
 
 
 
 App begin delegate methods Die toggles Gee plek getting profile Navigeer na die module Modulêre inisiasie Skerm weergawe Dit laat ons toe om presies te sien: 
 
 
 
 Watter stadium het versnel Waar 'n regressie verskyn what exactly affected the final TTI Dit is tydlyne wat ons toelaat om groot veranderinge veilig te maak en hul gevolge te verstaan.Dit het ook die basis geword vir besluitneming en die vind van regressies of plekke vir versneling - die langste stukke wat ons die meeste belangstel. Dit is 'n baie goeie vlak van detail, maar beplan hulle om dadelik gedetailleerd en hoë gehalte te wees, want om hulle later te verander, sal ongemaklik wees, en die vergelyking van grafieke met 'n vorige afbraak sal onmoontlik wees. App Launch Report en Typhoon Verwyder Xcode App Launch Report toon watter kode die lancering vertraag. In ons geval: 
 
 
 The DI container Typhoon took ~30% of launch time verskeie van sy inisialisasies het konsekwent verskyn in die hoogste langsomste plekke Na die verwydering van die Typhoon: Die eerste fase van die lancering is byna 3 keer verminder. van ~1.3 sekondes tot ~445 ms in weergawe 5.122. On the timeline you can see how the first stage sped up 3 times, but the overall TTI became larger. If we did not have the breakdown, we would not have understood what was happening and how removing DI could slow everything down like that. But it turned out that along with the speedup, a bug made it into this version. I will talk about it in the next section. Hang Rate Nou kan ons sien hoe een instrument 'n ander aanvulling gee - tydlyne het 'n prentjie gegee dat die lancering versnel het, maar verder iets gebreek en verskeie aanvanklike stadiums beïnvloed het. Dit het getoon dat die nuwe weergawe van die app aansienlik begin vertraag. Iets blokkeer die hoofdraad. Die instrument toon dat 92% van die hang tyd kom van 'n derde-party SDK. Moreover, it points to the specific line. Die rede — 'n netwerk versoek van 'n derde party biblioteek op die hoof thread met 'n server reaksie wag van tot 10 sekondes. Ons het 'n probleem met die biblioteek aangemeld, en na die regstelling het Hang Rate weer normaal geword. Navorsing Van tyd tot tyd profiel ons die hoofgebruikerspad deur dit op verskillende toestelle uit te voer, en dit lyk ongeveer so. Hier het ons mikro-vrye gevind, en ons sien dadelik watter stadiums van die kritieke pad hulle beïnvloed. Dit blyk dat sekere kode vir die werk met gebruikersposisie die hoofdraad swaar laai.Ons het die probleem opgelos, willekeurige mikro-vrye verdwyn, en die Hang-koers het selfs laer geword. Also, the profile fetching stage was reduced from 480 ms → 21 ms. UI prestasie toetse op CI Om probleme te vind en hulle op te los, is goed, maar selfs beter is om te leer oor 'n vertraging voordat die app na die App Store gaan, en selfs voordat die weergawe regressie begin. Ons het 'n native UI-toets gedoen wat deur 'n werklike scenario op die produksie-bediener gaan en dieselfde metrikes stuur as vir die produksie-versie. 
 
 
 
 
 gaan deur die werklike gebruikerspad na die sleutelskerm hardloop in die nag loop 'n paar keer sonder netwerk muck sends metrics to telemetry As die tyd die drempel oorskry - 'n waarskuwing kom na Slack. Dit gee die vermoë om 'n probleem te vang voor die vrylating, wat tans die belangrikste element van die hele stelsel is. Ook, om seker te maak dat ons caching goed werk, het ons internet-grot op CI bygevoeg - eerste die toets hardloop met normale spoed, alles word cached, dan dieselfde ding, maar op 3G traag internet. In my mening is dit een van die belangrikste komponente van die werk op die spoed van die opstart - om nie so 'n weergawe te laat gaan om vry te maak nie. Next we want to run this on every Pull Request asynchronously, so as not to block the merge, since performance tests run on the same Mac Mini to keep measurements honest, and with a large team there would be a queue. But we can do this after the merge and understand which PR broke the startup time, so we can quickly revert changes. Version Comparison Before adding a new dependency to the project, we have a version comparison process — an instruction for the developer on how to compare the current version of the app and the one with the new dependency added. Een keer gedurende so 'n loop het ons 'n 250 ms toename by app-start gesien en besluit om hierdie funksie slegs tydelik en slegs aan 'n gedeelte van gebruikers uit te voer, sodat die app nie vertraag nie. Volg die Caching Kom ons kyk na die laaste geval - kyk na die tydlyne, een van die langste fases op ons pad is om funksies te kry (700 ms), die swart bars op die grafiek. Ons het progressiewe caching geïmplementeer: as die skakels vars is as 'n sekere tyd - ons gebruik die cache. Natuurlik loop ons 'n A / B-eksperiment wat verbetering toon. Die resultate: 
 
 
 die verskuiwingsfase is verminder in weergawes 126–127 TTI het merkbaar vinniger gebruikers geword wat die app gereeld oopmaak en diegene met 'n stadig internet het die meeste baat gehad. Die grafiek toon bestuurders toggle. Dit het so klein geword omdat hulle die app baie gereeld oopmaak. Traffic Lights and Quick State Control Wanneer daar te veel metrieke is, benodig jy aggregate. Ons gebruik "verkeersligte". Hulle gebruik komplekse aggregeringsformules per dag, outomatiese evaluering van verbeterings en afbraak. ek sal dit nie nou beskryf nie, want dit sal baie tyd neem, maar globaal is dit alles vir 'n vinnige antwoord op die vraag: "wat gebeur met die weergawe". Byvoorbeeld, op een van die weergawes was daar 'n sigbare buitengewone boost in TTI - die gevolg van die ontlading van die hoofdraad. Final Results Kom ons kyk na ons resultate oor 'n half jaar van werk. Van die begin van die jaar tot September (versies 115 → 140): die tyd van die app-lancering tot die oorgang na die produk vertikale (50th percentile) is byna 3 keer verminder: 2.8 sec → 1 sec Die aandeel van gebruikers met lancering vinniger as 5 sekondes: 58% → 84% For 75 percent of users the app launches in 4 sec, and it used to be 6.2 sec. 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. Konklusie Die versneling van die app is nie 'n eenmalige optimalisering nie, maar 'n voortdurende proses: 
 
 
 
 
 clear metrics Begrypbare timelines Automatiese beheer voor vrylating Periodieke analise en eksperimente En die belangrikste ding - versnel deur honderde millisekondes werklik beïnvloed die besigheid.

This story contains new, firsthand information uncovered by the writer.

inDrive.Tech

Hierdie oudio word in die oorspronklike taal van die storie vervaardig!

Millisekondes maak miljoene: Hoe en hoekom om jou app te versnel, uit InDrive se speelboek

About Author

KOMMENTAAR

HANG TAGS

HIERDIE ARTIKEL IS AANGEBIED IN

Related Stories

"What If ... I didn't Do It?"

Thrilled to be Recognized as Startup of the Year in New York City

"Walk Down the Road of Life Without Fearing Anything" Max Azarov, CEO and Co-Founder, Novakid

Thinking for the 21st century

"What If ... I didn't Do It?"

Thrilled to be Recognized as Startup of the Year in New York City

"Walk Down the Road of Life Without Fearing Anything" Max Azarov, CEO and Co-Founder, Novakid

Thinking for the 21st century

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps