Днес никой няма търпението да чака приложението да се зареди. В мобилната екосистема, бързината на реакция е разликата между това потребителят да остане с приложението или да го изтрие за секунди. Зареждането на сложен интерфейс мигновено изисква да се отиде отвъд конвенционалната оптимизация на кода, като се фокусира върху това как устройството обработва инструкциите, преди те да достигнат до екрана.
За да се справи със забавянията при стартиране, Google въведе Baseline Profiles – инструмент, който позволява на разработчиците да маркират кои кодови пътища са жизненоважни. По този начин предотвратяваме необходимостта устройството да „открива“ как да стартира приложението от първия път, осигурявайки безпроблемна работа още от първото стартиране , независимо дали става въпрос за чиста инсталация или актуализация.
Какво точно представляват базовите профили и как работят?
За да ги разберете, първо трябва да знаете, че Android използва Android Runtime (ART). Традиционно кодът се изпълняваше чрез компилация Just-In-Time (JIT) , която преобразува кода, докато приложението се изпълнява, или компилация Ahead-Of-Time (AOT) , която прави всичко предварително. Проблемът с JIT е, че може да причини малки засичания или първоначално забавяне, защото кодът не е оптимизиран от самото начало.
Базовите профили действат като основно ръководство. Те представляват по същество списък с класове и методи, които системата трябва да прекомпилира, използвайки AOT, преди потребителят да отвори приложението. По този начин средата за изпълнение не е необходимо да интерпретира кода в движение, което може да доведе до подобрение на скоростта с до 30% при първоначално изпълнение.
За разлика от облачните профили, които разчитат на хиляди потребители, използващи приложението, и Google Play, които добавят тези данни (процес, който отнема дни), базовите профили се доставят директно в Android App Bundle (AAB) . Това означава, че оптимизацията е налична веднага, елиминирайки „бавния“ период, който често се наблюдава при новоактуализираните версии.
Кога е необходимо да се приложи тази техника?
Не всички приложения изискват едно и също ниво на оптимизация, но има сценарии, в които те са спасение. Използването на профили е от решаващо значение за намаляване на времето за студено стартиране , особено ако началният ви екран има тежки зависимости или сложно рендиране. Ако забележите, че първото стартиране е бавно, но второто е светкавично бързо, имате проблем с компилацията, който профилите могат да разрешат.
Освен това, те не са само за стартиране. Те са изключително полезни за подобряване на плавността на превъртане . Чрез предварително компилиране на логиката на списъците и анимациите, предотвратявате пропускането на кадри, което прави навигацията в съдържанието невероятно плавна. Те са идеални и за оптимизиране на повтарящи се функции , като например процеса на плащане или регистрация, като гарантират, че най-често използваните пътища са най-бързи.
Поетапна конфигурация на модула за генериране
Най-модерният начин за реализиране на това е чрез специален модул в Android Studio. За да започнете, трябва да отидете на Нов модул и изберете шаблона Генератор на базови профилиТук ще дефинирате целевото приложение, името на модула (например, baselineprofile) и предпочитания език, Kotlin или Java.
Този процес автоматизира създаването на тестова среда. Съветникът ще конфигурира плъгина. androidx.baselineprofile и ще добави библиотеката инсталатор на профили в модула на приложението. Последният е отговорен за правилното инсталиране на профила на устройствата на потребителите, дори на по-стари версии на Android, които не поддържат облачни профили.
Важен технически детайл е управлението на обфускацията. За да бъде профилът валиден, той трябва да бъде генериран върху вариант, където `isMinifyEnabled` е зададено на `false` . Не се притеснявайте обаче за крайната версия: R8 е в състояние да пренапише правилата на профила, за да съответстват на обфускирания код на производствения APK файл, като по този начин поддържа максимална сигурност и оптимизация на размера.
Създаване на критични потребителски пътешествия (CUJ)
Основен профил, който само стартира приложението, е полезен, но за да извлечем максимума от неговата производителност, трябва да дефинираме Критични потребителски пътуванияТова се прави в рамките на класа BaselineProfileGenerator използвайки правилото BaselineProfileRuleВътре в блока collectТрябва да симулираме реалните действия, които потребителят би предприел.
Например, ако приложението ви има асинхронно зареждане, не е достатъчно просто да извикате startActivityAndWait()Трябва да внедрите интелигентно чакане, така че системата да регистрира кода, който се изпълнява, когато съдържанието най-накрая се появи. Това се постига чрез взаимодействие с интерфейса чрез UiAutomator, търсейки специфични елементи и чакайки те да станат видими преди края на теста.
За усъвършенстван работен процес можете да програмирате генератора превъртане на списъци вертикално използвайки метод flingПридвижвайте се до подробни екрани или дори управлявайте диалогови прозорци за системни разрешения. Колкото по-точно е симулираното ръководство, толкова по-точен ще бъде генерираният профил и следователно, Колкото по-плавно ще бъде преживяването действителен краен потребител.
Генериране и валидиране на производителността
След като генераторът е написан, е време да го стартирате. В идеалния случай трябва да използвате Устройство, управлявано от Gradle (GMD) или емулатор с изображение aosp да има root права, въпреки че последните версии на библиотеката вече позволяват генериране на профили на физически устройства с Android 13 или по-нова версия без усложнения.
При изпълнение на задачата Gradle :app:generateBaselineProfileСистемата стартира приложението няколко пъти, събира извиканите класове и методи и създава файл baseline-prof.txtТози файл се поставя автоматично в папката с активи на приложението, готов за пакетиране в AAB.
За да разберем дали наистина работи, използвахме Jetpack MacrobenchmarkСъздадохме тест, който сравнява два сценария: единият с CompilationMode.None() (без оптимизация) и друг с CompilationMode.Partial() (използвайки профила). При анализа на метриката време за пълно показванеЧесто се наблюдават драстични намаления на милисекундите, което потвърждава, че критичният код вече не е необходимо да се компилира в реално време.
В реални сценарии, като например при мащабни приложения, е наблюдавано, че нишката Just-in-Time (JIT) намалява от 25% от времето до само 3%. Това освобождава ресурси на процесора и намалява термичното натоварване на устройството, което води до по-стабилно и ефективно приложение , особено на устройства от нисък клас.
Внедряването на базови профили е една от най-рентабилните инвестиции в потребителското изживяване, тъй като позволява на софтуера да изглежда лек и отзивчив още от първата секунда. Чрез комбиниране на използването на модули за бенчмарк за генериране и постоянно валидиране на времената за зареждане, всеки разработчик може да трансформира бавно приложение в незабавен , професионален инструмент , който задържа потребителите.