Milliseconds Make Millions: Paano at Bakit upang Pag-accelerate ang iyong app, mula sa InDrive's Playbook

Hi everyone, ang aking pangalan ay Vladimir Pchelyakov, ako ay isang engineer ng iOS sa inDrive. Sa artikulong ito, makipag-usap ko tungkol sa kung paano ang oras ng pag-start ng app ay nakakaapekto sa mga revenue ng kumpanya, kung paano natagpuan namin ang aming app, at i-cover ang mga tool, mga approaches, pati na rin ang mga katotohanan at, siyempre, ang mga resulta. Ang artikulong ito ay maaaring maging isang plano para sa anumang team na nais na i-accelerate ang oras ng pag-unlad ng app at ang mga kritikal na path ng gumagamit, dahil ang mga problema na natagpuan namin ay karaniwang magagamit sa karamihan ng mga proyekto na hindi na-optimize. Para sa konteksto, sa app inDrive maaari mong i-order ng taxi bilang isang pasahero, o maaari mong makuha ang mga order at gawin ang mga paglipad bilang isang driver. Sa artikulong ito, i-cover ang mga ito: Kung paano ang oras ng startup ay nakakaapekto sa mga revenue ng kumpanya Mga uri ng app launch App Launch Time, TTI, at Hang Time Ang average na halaga at percentile Ano ang nakakaapekto sa Startup Time Mga Acceleration ng App Ang pinaka-effective na paraan ng pag-accelerate Mga instrumento, mga proseso, mga situasyon mga resulta Paano Ang Startup Time Ipinanganak Ang Income ng Company Ang karamihan ng mga tao ay naniniwala na ang mga developer ay "mga obsessed sa pag-optimize" na hindi nagbibigay ng anumang tunay na halaga. Ngunit ang data ay nagpapakita na pag-accelerate ang mga bagay sa higit sa hundreds ng milliseconds ay maaaring ilagay sa negosyo halos tulad ng pag-unlad ng isang bagong tampok o pagpasok sa isang bagong merkado. Mga pananaliksik Sa loob ng kumpanya, nilikha namin ang isang malaking pananaliksik na nagpapakita na ang pag-accelerate ng pasahero's critical path sa 750 ms ay nagbabago ang bilang ng mga order sa 1.5%. Kung ang iyong app ay may milyon-milyong mga order, lamang dahil ang app ay nagsimula upang ipakita ang interface mas mabilis, makakakuha ka ng mga dekada o kahit na hundreds ng mga libreng order sa isang araw! Mga pananaliksik ng Deloitte Deloitte inilathala ng ilang napaka-impresyonal na mga numero: pag-accelerate ng isang mobile website sa pamamagitan ng 100 ms ay nagbibigay ng +8.5% na konversyon sa e-commerce, at +10% sa paglipad. Ang mga numero ay nakikita na magagandang, ngunit ito ay Deloitte, at walang dahilan upang sumali sa kanilang professionalism. Sa karagdagang, ang ilang mga kumpanya ay deliberately na-slowed ang app para sa anumang mga grupo ng mga gumagamit upang i-prove ang hipotesis: ang mas mabilis na inilunsad ang app, ang higit pa ang mga order ang gumagawa ng gumagamit. At ang hipotesis ay na-confirmed. Kung gusto mo nang magtrabaho sa pag-accelerate ang app ngunit walang malakas na argumento, ngayon ikaw ay may mga ito. Mga Tipo ng App Launch Ang uri ng pag-launch ng app ay direktang nakakaapekto sa metric, kaya ito ay mahalaga upang sabihin ang mga ito. Ang Apple ay hindi nagbibigay ng isang direkta na API para sa pagkuha ng uri ng pag-unlad, kaya ang bawat team ay gumagana ito sa kanyang sarili. ang cold launch Kompletong pag-load ng app mula sa pangunahing, ang pinakamataas na uri ng pag-launch. Ang proseso ng app ay hindi magagamit, walang cache, ang lahat ay initialized mula sa pangunahing. Halimbawa, ito ay ang unang pag-launch pagkatapos ng pag-download mula sa store, o pagkatapos ng ilang oras o higit pa matapos ang app ay i-download mula sa memory. Ang Cold Launch ay ang pinakahuling fair metric na maaaring i-compare mula sa bersyon sa bersyon upang i-draw ang mga konklusyon. Sa buong artikulong ito, ang lahat ng mga pagsusuri ay ginawa eksklusibong sa Cold launches. Maghanap ng Warm Launch Ang app ay nakalipas, kaya walang proseso exists. Gayunpaman, ang mga bahagi ng app ay magkaroon ng bahagi sa memory - system caches at ang dynamic linker cache ay mas hot. Ang sistema ay dapat magsisimula ng isang bagong proseso at re-initialize ang runtime, ngunit i-slip ang karamihan ng mga I/O trabaho na kinakailangan sa isang cold launch, na nagpapakita ng mas mabilis. Ito ay nangyayari kapag i-download ang app mula sa memory at halos pagkatapos ay i-open ito sa taas, ito ay i-open na mas mabilis. Ang metric na ito depende sa maraming mga bahagi, kaya hindi ito gumagana para sa amin. Mga Hot Launch Ang app ay simpleng minimized at buksan ang taas. Walang bagay na dapat ayusin dito, ang app ay buksan instantly at hindi pumunta sa anumang path, ito ay na sa parehong lugar. nagtatapos sa Ito ay gumagana, ngunit ito ay nagiging sanhi ng maraming mga problema: mayroon kaming mga "launch" ng 15 minuto at 10 oras, dahil prewarm inilunsad ang proseso sa harap, at kami ay inihayag ang oras mula sa isang variable na nilikha sa pangunahing file, at ang gumagamit ay hindi inilunsad ang app pagkatapos ng mga dekada ng oras. Sa unang pagkakataon, hindi namin alam kung saan ang error ay at kung paano ang oras ng pag-unlad ay katumbas sa mga oras, at ito ay din malaki na na-corrupted ang mga istatistika, dahil ang iba pang mga data ay inihahanda sa ms, at mga metrikong may mga oras ay talagang tumuturo ang larawan. Tandaan, ang Prewarm ay maaaring ganap na bumalik ang mga statistics. App Launch Time, TTI at Hang Time Pero kapag nalaman niyang nakilala mo siya dahil binasa mo ang diary... get ready for the consequences. App Lansahin ang oras Importante: ito ay hindi tungkol sa System Launch Screen, na nagpapakita nang instant, ngunit tungkol sa aming root view controller - ang oras kung ang library linking ay ginawa, ang AppDelegate na mga paraan ay nakumpleto, ang view controller ay nilikha, at ang viewDidAppear na paraan ay lumabas. TTI (Tempo para sa Interactive) Ang oras mula sa pag-touch ng icon ng app hanggang sa oras kung saan ang gumagamit ay maaaring makipag-ugnayan sa app. Maaari ka ring sabihin ito ang kritikal na path, dahil ito ay nakakaapekto sa simula ng paglikha o pagproseso ng isang order, at ito ay kung ano ang nakakaapekto sa mga metrikong negosyo. Ang path na ito ay iba para sa bawat app, dahil ang lahat ay may iba't ibang endpoint, at ito ay napili batay sa kanyang epekto sa negosyo. Halimbawa, sa aming kaso: Para sa pasahero — kapag nakikita ang mapa at ang gumagamit ay maaaring i-tap ang "Nasaan upang pumunta". Karamihan sa mas mabilis na ito ay dumating, mas malamang na ang pasahero ay lumikha ng isang order. Para sa driver - kapag ang screen na may mga order ng pasahero ay ipakita. Karamihan sa mas mabilis na ito ay dumating, mas malamang na ang driver ay makikita at makakuha ng isang order sa oras. Hangin ang oras Ito ay ang oras kung saan ang interface ay "freezes" - isang button ay na-tap, ngunit ang aksyon ay hindi nangyari instantaneously, halimbawa, ito ay nangangailangan ng isang segundo. Karaniwang ito ay ang resulta ng mataas na pag-calculations sa pangunahing thread. At ano, Hang Time ay direktang nakakaapekto sa TTI, dahil ang freezes ay dumating hindi lamang kapag ang user ay i-tap ang isang button, ngunit din kapag isang bagay sa kritikal na path ay nagtatampok sa pangunahing thread at ang UI ay freezes sa panahon ng rendering. Ang average na halaga at percentage Pagkatapos ng pagkuha ng data mula sa milyong mga gumagamit, kailangan mong i-interpret ang mga metrikong ito, at may hindi bababa sa 2 mga pagpipilian: average na halaga at percentiles. Bakit ang average ay hindi nagpapakita ng buong picture Ang average ay makikita na magagamit at madaling i-calculate, ngunit sa ilang mga oras ay napaka-draw ang mga konklusyon mula dito. Narito ang isang halimbawa: Mayroon kaming 5 mga gumagamit at ang mga oras ng pag-unlad para sa 5 gumagamit = 1, 2, 3, 9, 12 segundo. Ang average ay 5.4 sec. Ngunit ito ay hindi nagpapakita ng katotohanan: 3 sa 5 mga gumagamit ay i-start ang app sa 3 segundo o mas mabilis. 2 mga gumagamit ay napaka-kakaiba na at pagkilos ang buong statistics. At kung ang isang launcher ay na-recorded bilang "1 oras" (o infinity ay dumating dahil sa isang metric error), ang average ay naging ganap na walang kaalaman. Paano gumagana ang Percentiles at bakit ang mga ito ay higit pa Ang percentile ay nagpapakita kung ano ang oras na kailangan ng app para sa X porsiyento ng mga gumagamit na matatagpuan sa panahon na ito. Sa parehong 5 mga halaga: 1, 2, 3, 9, 12 50th percentile = 3 seconds → half ng mga gumagamit ay mag-start ng app sa 3 sec o mas mabilis. 80th percentile = 9 seconds → 80% ng mga gumagamit ay makita ang app sa ≤ 9 segundo. 99th percentile = 12 seconds → ang "mahal na" mga gumagamit: mababang mga aparato, mababang internet. Nakita namin ang mga 50th, 75th, 90th at 95th percentiles. Sa kabuuan ng pangunahing massa ng mga gumagamit, sinusubukan namin pa rin ang pag-accelerate ng 95th percentile, upang mapabuti ang buhay para sa mga tao na ang app ay nag-load ang pinakamataas, karaniwang dahil sa device o mababang internet sa kanilang bansa. Sa katunayan, makikita ko na kami ay nagtatrabaho sa 47 bansa sa buong mundo, at mayroon kaming maraming bansa kung saan maraming mga gumagamit ay may mababang mga aparato at mababang unstable internet. Ano ang gumagawa ng Startup Time Tingnan natin ang mga pangunahing mga lugar na maaaring mas mababang ang app. Mga Request ng Network Ang bilang ng mga pangangailangan sa chain, ang order ng mga pangangailangan, ang kakayahan ng pag-cache, speed ng internet. Pag-initialize ng app Sa startup, isang malaking bilang ng mga operasyon ay dumating: library linking, launching Objective-C runtime, Swift Reflection, SDK initialization (analytics, ads, Firebase), loading dylib, dyld, rebase, symbol binding, DI container initialization. ang main threat Any heavy operations on the main thread increase TTI: JSON decoding of large and complex models, synchronous calls, unnecessary calculations "at startup" dahil ito ay convenience, kahit na sila ay maaaring i-move sa ibang lugar. Mga Karakteristika ng Device Hindi namin maaaring i-accelerate ang mga nakaraang aparato, ngunit maaari naming i-adjust ang logic para sa mga ito o i-reduced ang halaga ng load. Ang isang interesado na katotohanan: para sa mga bansa na may mahaba na mga device at slow internet, inilathala ng Meta ang Facebook Lite app. Ang Facebook Lite app ay maliit, na nagbibigay-daan sa iyo upang i-save ng lugar sa iyong telepono at gamitin ang Facebook sa 2G mga kondisyon. Paggamit ng App Acceleration Upang i-accelerate ang app, kailangan mo ng sistematiko na i-measure at i-improve, hindi "fix things by eye". Ang aming cycle ay tulad ng ito: 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 Mga pahinang tumuturo sa 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 Mga eksperimento Pumili ng mga resulta, i-verify ang mga assumptions Control startup time before a new release UI-performance tests on CI, alerts on degradations Sa halip na ito, mula sa bersyon sa bersyon ang app ay mas mabilis, mas stable at mas predictable. Ang pag-markup at pag-visualization ay hindi ginawa sa bawat siklo. Ang pinaka-effective na paraan ng pag-accelerate Ang pinakamalaking epekto ay dumating mula sa ilang pangunahing, ngunit sistematically ginawa na mga hakbang: Ibalik ang order ng network requests Paggamit ng Network Requests I-download ang main thread I-remove ang heavy computing sa startup Ito ay katumbas na ang mga pagbabago na nagbibigay sa amin ng maximum TTI pagbutihin sa isang minimum na pagsasanay at risk ng pag-atake ng isang bagay. Mga instrumento, mga proseso, mga situasyon Sa kapitulo na ito, ibinigay ko sa iyo tungkol sa aming mga tool at pumunta sa pamamagitan ng ilang mga tunay na halimbawa, kung saan ako ay ipakita kung paano ang isa sa mga tool complements ang isa at kung ano ang lahat ng mga ito nakikita. Ang pag-optimize ay hindi posible nang walang mga pagsusuri. unang kailangan mo upang i-mark ang proyekto. Sa loob ng aming app, ang mga pangunahing phases ng pag-unlad ay i-marked: AppLaunchTracker — mag-launch ng app hanggang ang unang controller ay nagpapakita. SplashTracker — oras ng iba't ibang mga stage ng screen splash (mga gawing feature toggles, profile, pagkuha ng lokasyon). CriticalPathTracker — ang critical path ng user na may step breakdown at oras sa pagitan ng mga ito VerticalsTTITracker — TTI para sa bawat produkto vertical. Ang lahat ng data ay visualized sa mga diagram at dashboards (Kibana, Redash). Sa karagdagang ito, natagpuan natin ang mga proseso: Pagkakaiba sa Performance UI-performance testing sa CI Mga alerts sa degradation regular na mga meeting at isang roadmap para sa pag-accelerate Kami ay gumagamit ng mga tool: Xcode Instruments — LaunchTime, Profile, Network, Hangs Xcode Organizer - Hangs, App Launch Sinusundan ko rin ang paggawa ng isang roadmap upang malaman ang order ng pag-execute ng mga task. Ang aming mga ito ay tulad ng: Ngayon, tingnan natin ang lahat sa action. Paggawa ng Network Requests Order Ang isa sa mga pinaka-effective paraan upang i-accelerate ang TTI ay upang i-rearrange ang order ng network requests at i-execute ang mga independiyenteng requests sa parallel. Para sa pananaliksik, ginagamit namin ang Xcode Instruments → Network, kung saan maaari mong malinaw na makita kung ano ang mga request at ang kanilang dependencies. Ano ang ginawa namin: ran the specific flow I-capture ang isang trace ng network requests Ipinanganak ang mga oras kung saan ang mga screen ay dumating sa kanya Pagkatapos ay dumating kami sa team ng produkto, ipinakita ang mga resulta, ibinigay kung paano i-optimize ang order ng network requests, at pagkatapos ay lumikha ng mga trabaho. Simple ang kaso Ang isang request na ang unang screen depende sa ay ibinigay na mas late. Ito ay maaaring i-move sa simula ng life cycle ng screen, dahil ito ay hindi nagkaroon ng anumang dependency. Tulad ng resulta, ang user ay makikita ang ready interface mas mabilis, na kung saan ay nagpapakita ng mas mabilis na TTI. Sa Android natagpuan namin ang isang klasikong "staircase": Toggles → driver config → reasons → mga sumusunod All requests went strictly sequentially. Only after that did the loading of orders begin. ang solusyon: I-combine ang ilang mga request sa isa o i-execute ang mga request sa parallel kung walang dependencies. Ang pinaka simpleng at pinaka-effective paraan ay upang i-remove ang artificial sequence kung saan ito ay hindi kinakailangan. May isang pagkakataon na ang mga developer ay napulat ang sequence na ito sa loob ng isang taon na ang nakalipas para sa kagamitan o iba pang mga dahilan, at ito ay nakatira sa paraan na ito dahil ito ay hindi nag-iisip ng anumang tao. Ang isang mas malakas na kaso: Mga driver ng feed Ipinanganak, bago ang pag-load ng mga order, isang serye ng ilang mga requests ay inihayag: Mga Taxi Settings Mga taksi driver Mga Setting Lahat ng mga ito ay dumating sequentially, at ang bawat request ay mabawasan ang TTI, lalo na sa slow internet na ito ay makikita, dahil ang bawat isa sa tatlong mga request ay nagbabago ang total na oras ng path. We got together with the team and significantly simplified the scheme: Ang mga independiyenteng mga pangangailangan ay inilunsad sa parallel I-combine ang dalawang mga request sa isang request Ang request para sa mga order ay nagsimula ngayong pagkatapos ng pagkuha ng minimum na kinakailangan ng data. At lamang sa karaniwang mga kaso ay kailangan nating maghintay para sa isang parallel request, ngunit kahit na pagkatapos ay, ito ay inilunsad sa parallel sa unang, hindi mula sa zero pagkatapos ng unang. Ang resulta ay: sa loob ng isang taon na ang nakalipas, mayroong isang minimum na dalawang sa pinakamahalagang kaso - isang mas mababang request kaysa sa bago Pagkatapos ay nagsimula kami ng isang eksperimento. resulta ng eksperimento: TTI acceleration ng 0.5–0.8 segundo sa average sa 95th percentile — hanggang sa 2 segundo Mga Timeline Ang mga diagram sa pamamagitan ng bersyon ay nagpapakita na ang app ay naging mas mabilis o mas madali, ngunit hindi sumusunod ang tanong kung bakit. 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: I-start ang app Mga Modelo ng Delegation Paggawa ng Toggles Pagkuha ng Lokasyon Paggawa ng Profile Pag-navigate sa Module Mga Module ng Initialization Screenshot sa pamamagitan ng Ito ay nagbibigay-daan sa amin upang makita ang mga bagay na ito: kung ano ang accelerated Kapag ang isang regression ay Ano ang nangyari sa final TTI Sa gitna ng Pagpatay ng sarili niyang Olympic maskot , Ang Dysfunctional clean up Ng maruming tubig nito, ang Pag-shutdown ng doping lab nito , Ang Deklarasyon ng isang emergency na pinansiyal , Ang Pagkakaroon ng virus Zika , At Iba't ibang mga kalamidad , Ang Olympic ambitions ng Rio ay isang kalamidad. Ito ay isang mahusay na antas ng detalye, ngunit mag-plano ang mga ito upang maging detalyado at mataas na kalidad ngayong pagkakataon, dahil ang pagbabago ng mga ito pagkatapos ay maaaring maging malusog, at ang pagitan ng mga diagram sa isang previous breakdown ay hindi maaaring. App Launch Report at Pagpapadala ng Typhoon Xcode App Launch Report shows what code slows down the launch. Sa aking kaso: Ang DI container Typhoon ay nangangailangan ng ~30% ng oras ng launcher Ang ilang mga initializations ay consistently nakikita sa mga pinakamataas na lugar. Pagkatapos ng pagbabago ng Typhoon: Ang unang phase ng pag-unlad ay na-reduced ng halos 3 beses. mula sa ~1.3 segundo sa ~445 ms sa bersyon 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. Tingnan ang rate Ngayon maaari naming makita kung paano ang isang tool complements ang isa - timelines ay nagbibigay ng isang larawan na ang pag-accelerate ng pag-unlad, ngunit higit pa ang isang bagay ay bumaba at nakakaapekto sa ilang mga unang patakaran. Ang susunod na tool na nagbibigay sa amin - Xcode Organizer Hangs. Ito ay nagpapakita na ang bagong bersyon ng app ay nagsisimula na mabawasan nang mahalaga. Ang isang bagay ay nag-block ang pangunahing thread. Ang tool ay nagpapakita na 92% ng hang-time ay dumating mula sa isang third-party SDK. Ngunit ito ay nagpapakita sa anumang linya. Ang dahilan — isang network request mula sa isang third-party library sa pangunahing thread na may isang server response wait ng hanggang sa 10 segundo. Ang problema lamang na reproduced sa slow internet, kaya ito ay umalis nang hindi nakikita sa pamamagitan ng aming mga testers at developer, dahil ang lahat ay may mabilis na internet sa laptop at mga aparato. Nag-post ng isang problema sa library, at pagkatapos ng paghahatid, ang Hang Rate ay bumalik sa normal. pananaliksik Sa oras na kami profile ang pangunahing user path sa pamamagitan ng pag-execute ito sa iba't ibang mga device, at ito ay mataas na tulad ng ito. Here we found micro-freezes, and we immediately see which stages of the critical path they affect. Nagtatagumpay na ang anumang code para sa paggawa ng user na lokasyon ay malaki na na-load ang pangunahing thread. Kami ay fixed ang problema, random micro-freezes nawala, at ang Hang rate ay naging mas mababa. Also, the profile fetching stage was reduced from 480 ms → 21 ms. I-test ang performance ng mga ito Ang paghahanap ng mga problema at i-solve ang mga ito ay mahusay, ngunit mas mabuti pa rin ang pag-aaral tungkol sa isang pagbabago bago ang app ay pumunta sa App Store, at kahit na bago ang regression ng bersyon ay nagsimula. Kami ay ginawa ng isang native UI test na pumunta sa pamamagitan ng isang real na scenario sa produksyon server at i-send ang parehong metric na para sa produksyon bersyon. Ipasok ang real user path sa key screen Tapos na ang klase. I-execute ang ilang beses nang walang network mocks I-send ang metric sa telemetry Kung ang oras ay higit sa limitasyon - isang alerta ay dumating sa Slack. Ito ay nagbibigay ng pagkakataon upang makakuha ng isang problema bago ang release, na kung saan ay kasalukuyang ang pinaka-importanteng elemento ng buong sistema. Kita rin ang lahat ng parehong timelines, at ang pagsubok ay malapit sa posible na malapit sa mga katotohanan ng paggamit. Also, to be sure that our caching works well, we added internet throttling on CI — first the test runs at normal speed, everything is cached, then the same thing but on 3G slow internet. In my opinion, this is one of the most important components of working on startup speed — not letting such a version go to release. Pagkatapos ay nais namin mag-execute ito sa bawat Pull Request asynchronously, upang hindi i-block ang fusion, dahil ang mga test ng pagganap ay gumagana sa parehong Mac Mini upang makakuha ng mga pagsusuri na katulad, at sa isang malaking team ay mayroon ka ng isang kuwarto. Ngunit maaari naming gawin ito pagkatapos ng fusion at malaman kung ano ang PR na-break ang start time, kaya maaari naming mabilis na ibalik ang mga pagbabago. Mga komento sa 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. Isang beses sa panahon ng isang talagang run nakita namin ang isang pag-unlad ng 250 ms sa startup ng app at nagsisimula na i-release ang feature na ito lamang sa oras at lamang sa isang bahagi ng mga gumagamit, upang hindi i-slow ang app. Pagkakaiba sa Caching Tingnan natin ang pinakabagong kaso - tingnan ang timelines, isa sa mga pinakamalaking stage sa aming path ay makakuha ng feature toggles (700 ms), ang mga black bar sa chart. Nag-implementate na progressive caching: kung ang mga toggles ay mas fresher kaysa sa isang anumang oras - ginagamit namin ang cache. pagkatapos ay i-update ang data asynchronously. Gayunpaman, gumagana kami ng isang A / B eksperimento na nagpapakita ng pagbutihin. ang resulta: ang transition stage ay na-reduced sa mga bersyon 126-127 Ang TTI ay naging mas mabilis na mga gumagamit na bumuo ng app karaniwang at ang mga may slow internet ay may karamihan. Ang diagram ay nagpapakita ng driver toggles. Ito ay naging maliit na dahil sila ay buksan ang app napaka-frequently. Traffic Lights and Quick State Control Kapag mayroong maraming mga metric, kailangan mo ng mga aggregates. gumagamit namin ang "traffic lights". Ginagamit nila ang mga kompleksong mga formula ng aggregation bawat araw, ang automatic evaluation ng mga pag-uugali at mga degradations. Hindi ko mag-describe ang lahat ng ito ngayon dahil ito ay gumagana ng maraming oras, ngunit globally ito ay lahat para sa isang mabilis na solusyon sa tanong: " Ano ang nangyayari sa bersyon". Halimbawa, sa isa sa mga bersyon ay may nakikita na exceptionally boost sa TTI - ang resulta ng offloading ang pangunahing thread. Final Results Tingnan natin ang mga resulta sa loob ng isang taon na ang nakalipas. Mula sa simula ng taon hanggang Setyembre (versions 115 → 140): ang oras mula sa pag-unlad ng app hanggang sa paglipat sa vertical na produkto (50th percentile) ay na-reduced ng halos 3 beses: 2.8 sec → 1 sec Ang bilang ng mga gumagamit na may pag-launch na mas mabilis kaysa sa 5 segundo: 58% → 84% Para sa 75 porsiyento ng mga gumagamit, ang app ay inilunsad sa 4 s, at ito ay nasa 6.2 s. Samakatuwid, ang mga pag-uugnay ay lumabas gradually mula sa bersyon sa bersyon, batay sa isang spike ng bug, na mabilis na nakuha namin sa pamamagitan ng mga tool.The porsyento ng mga gumagamit na mag-execute ang app sa cool ay nagsisimula mas mabilis kaysa sa 5 segundo. Konklusyon Ang pag-accelerate ng app ay hindi isang one-time optimization, ngunit isang continuous na proseso: Mga metriko Mga Mapagkukunan ng Timeline Automatic control pagkatapos ng release regular na pagsusuri at mga eksperimento At ang pinaka-karaniwang bagay - pag-accelerate sa pamamagitan ng hundreds ng miliseconds ay talagang nakakaapekto sa negosyo. Hindi sa teorya, ngunit sa real na porsyento ng mga order.