В предишната статия говорихме за това как да намалим размера на приложение за Android, като премахнем неизползваните ресурси. В блога на Кирил Мотие намерих много интересна статия с няколко съвета за намаляване на размера на APK и оптимизиране на кода в производството. След това продължаваме да превеждаме важните части.

12 м. (2413 думи.)

поставете

Александър кмет

Учен по данни и компютърен учен. Създател на този блог.

В предишната статия говорихме за това как да намалим размера на приложение за Android, като премахнем неизползваните ресурси. В блога на Кирил Мотие Намерих много интересна статия с няколко съвета за намаляване на размера на APK и оптимизиране на кода в производството. След това продължаваме да превеждаме важните части:

Не е тайна, че приложенията заемат все повече място. Първите приложения използваха няколко 2MB в началните версии на Android. Сега е доста често да се виждат приложения, които тежат между 10 и 20MB. Това увеличаване на размера е пряка последица както от очакванията на потребителите, така и от придобиването на опит от разработчиците. Основните причини за увеличаването на размера на APK файлове са:

  • Още dpi категории ([l | m | tv | h | x | xx | xxx] dpi).
  • Еволюцията на платформата Android, инструментите за разработка и екосистемата на библиотеката.
  • Непрестанните очаквания на потребителите за по-висококачествени графични интерфейси (UI).
  • и т.н...

Публикувайте леки приложения в Магазин за игри добра практика е, че всеки добър програмист трябва да обърне внимание при проектирането на приложение. Защо?.

  • Първо, защото е синоним на проста, поддържаема и надеждна кодова база.
  • Второ, защото програмистите обикновено предпочитат да останат под текущия лимит на Play Store, 50MB на APK ако не искате да използвате допълнителни файлове за изтегляне.
  • И накрая, защото живеем в свят на ограничения:
    • Ограничена честотна лента.
    • Ограничено дисково пространство.
    • и т.н.

Колкото по-малък е размерът на APK, толкова по-бърза е скоростта на изтегляне, толкова по-малко е разочарованието на потребителите и най-важното е по-добрите оценки.

В много (ако не всички) случаи нарастването на размера е задължително, за да отговори на изискванията и очакванията на потребителите. въпреки това, Кирил е убеден, че теглото на APK нараства като цяло по-бързо от очакванията на потребителите. Всъщност повечето приложения в Магазин за игри те заемат два пъти или повече, отколкото би трябвало. Някои техники/правила, които могат да се използват за намаляване на крайния размер на приложението, ще бъдат разгледани по-долу.

Преди да направите каквато и да е оптимизация, е важно да разберете APK формата. Най-общо казано, а APK това е архивиран файл, съставен от няколко файла в компресирана форма. Като програмист можете лесно да видите съдържанието му, като го разархивирате с командата unzip .

Това е APK след стартиране на разархивиране:

Повечето от горното съдържание трябва да са познати на всеки програмист. Той отразява структурата на проекта, която може да се наблюдава по време на разработката./активи,/lib,/res, AndroidManifest.xml. classes.dex съдържа компилираната версия (dex) на кода в Java и resources.arsc предварително компилираните ресурси, например двоичен XML (стойности, XML чертежи и т.н.).

Защото APK това е прост архивиран файл, това означава, че има два размера, компресиран и декомпресиран размер. И двете са важни, но в тази статия ще се спрем на компресирания размер. Колкото по-малък е APK, толкова по-малка е разархивираната версия.

Това може да се направи с най-различни техники. Тъй като всяко приложение е различно, няма абсолютно правило за "отслабване" до a APK. както и да е APK Състои се от 3 компонента, върху които можем да действаме:

  • Изходен код на Java.
  • Ресурси/активи
  • Роден код

Съветите по-долу са да се сведе до минимум количеството пространство, използвано от всеки от тези компоненти. По този начин минимизирате размера на APK файла.

Имайте код с добра хигиена

Вероятно е много очевидно, но навикът да имате чист код е първата стъпка за намаляване на размера на крайното приложение. „Познавайте кода си като гърба си.“ Отървете се от всички неизползвани библиотеки на зависимости. Правете кода по-добър ден след ден. Почиствайте го непрекъснато. Фокусирането върху поддържането на чиста и актуална кодова база обикновено е най-добрият начин за създаване APK файлове по-малък, съдържащ само това, което е строго необходимо за приложението.

Постигането на това обикновено е по-лесно, когато стартирате проект от нулата. По-трудно е срещу по-стария проект. Всъщност проектите с голям исторически опит са склонни да се справят с мъртви и/или практически безполезни парчета код. За щастие има някои инструменти, които да ни помогнат да изперем ...

Стартирайте Proguard

Proguard е изключително полезен инструмент, който замъглява, оптимизира и свива кода по време на компилация. Една от основните му характеристики за намаляване на размера е Разтърсването на дървета. Proguard като цяло той преминава през всички директории с код, за да открие парчета, които не се използват. Всичко, което намерите (т.е. неизползваните), се премахва от APK финал. Proguard също така преименувайте полета, класове и интерфейси, за да направите кода възможно най-лек.

Както се досещате Proguard той е изключително полезен и ефективен. Но с голяма сила идва и голямата отговорност. Много разработчици помислят Proguard много досаден инструмент, защото по подразбиране той разбива приложения, които разчитат силно на отражението. Разработчиците трябва да конфигурират Proguard за да посочите в кои класове, полета и т.н. можете да извършвате оптимизации.

Използвайте Lint широко

Proguard работи от страна на Java. За съжаление, той не работи от страна на ресурсите. В резултат на това, ако изображение my_image в res/drawable не се използва, Proguard просто премахнете вашата референция в клас R, но не и изображение.

Власинки е анализатор на статичен код, който помага за откриване на неизползвани ресурси с просто извикване на ./gradlew lint. Генерирайте отчет в HTML, в раздела "UnusedResources" ще бъдат изброени всички ресурси. Безопасно е да изтриете такива ресурси, стига да не бъдат достъпни чрез отражение в кода.

Власинки анализира ресурси (файлове в директорията/res), но игнорира активи (Файлове в/assets). Тъй като активите се достъпват по име, вместо на препратка към Java или XML (Вижте Компилирани и некомпилирани ресурси). И заради това Власинки не може да определи дали даден актив се използва в проекта. Това е задачата на програмиста.

Бележка на преводача: Има и други инструменти за автоматично изтриване на неизползвани ресурси, като изгледа в статията „ИЗТРИВАНЕ НА НЕИЗПОЛЗВАНИ РЕСУРСИ В ANDROID“, спомената в началото на тази статия.

Да бъдеш инат с ресурси

Android поддържа голям брой устройства. Всъщност той е проектиран да поддържа устройства, независимо от тяхната конфигурация: плътност на екрана, форма на екрана, размер и т.н. В Android 4.4 рамката изначално поддържа различни плътности: ldpi, mdpi, tvdpi, hdpi, xhdpi, xxhdpi Y. xxxhdpi. Въпреки че Android ги поддържа, това не означава, че трябва да експортирате всички активи към всеки от тях.

Не се страхувайте да не поддържате някои плътности, ако знаете, че тя ще се използва от много малък процент от хората. Кирил само поддържа hdpi, xhdpi Y. xxhdpi във вашите приложения. Това не е проблем за устройства с друга плътност, тъй като Android автоматично изчислява ресурсите, мащабирайки съществуващите за други плътности.

Основната точка зад правилото hdpi/xhdpi/xxhdpi просто е. Първо, (Кирил) обхваща 80% от своите потребители. Второ, xxxhdpi засега тя съществува само като нещо за бъдещето. При по-ниска плътност, като ldpi или mdpi, без значение колко усилия са изразходвани за създаването на ресурсите, резултатът ще бъде толкова лош, колкото да оставите Android да бъде този, от който да намалява hdpi.

По същия начин наличието на един вариант на изображение в drawable-nodpi може да намали пространството. Възможно е да си позволите това в редки случаи, ако изображението се показва много рядко, например.

Минимизиране на конфигурациите на ресурсите

Разработката на Android често разчита на използването на външни библиотеки като библиотеката за поддръжка на Android, Google Play Services, Facebook SDK и т.н. Всички тези библиотеки предоставят ресурси, които не са непременно полезни за нашето приложение. Например услугите на Google Play се доставят с преводи за езици, които приложението ви не поддържа. Използвайте и ресурси mdpi, например, което може да не е полезно в нашето приложение.

От версия 0.7 на приставката Градле, възможно е да предадете информация за това какви конфигурации са необходими за нашето приложение на системата за изграждане. Това е възможно благодарение на настройките в resConfig и resConfigs. Файлът build.gradle по-долу не позволява на aapt да групира ресурси, които не съответстват на това, което приложението използва:

Компресиране на изображения

Aapt Предлага се с компресор за изображения без загуби. Например PNG изображение, което не изисква повече от 256 цвята, може да бъде преобразувано в такова с 8-битова цветова палитра (8-битова = 1B = 256 стойности). Все пак aapt направете това за нас, би било добра идея да оптимизираме и изображението сами, за това има няколко инструмента, като pngquant, imageAlpha, imageOptim или optipng.

Android има специален тип изображения: 9-кръпки. За да оптимизирате тези изображения, просто кажете на дизайнера да минимизира „разтегливите“ области и съдържание.

Ограничете броя на архитектурите

Android обикновено се занимава с Java, но понякога е необходимо да се използва собствен код. В сегашната екосистема на Android ще бъде достатъчно да се разработи за архитектурите armabi и x86. В тази статия можете да намерите повече информация по темата.

Използвайте отново, когато е възможно

Това е може би една от най-важните основни оптимизации, които научавате, когато започвате да разработвате мобилни устройства. В ListView или RecyclerView повторното използване помага да се запази гладкото превъртане (Повече за изгледите за рециклиране в статията Създаване на персонализиран адаптер). Повторното използване може също да помогне за намаляване на крайния размер на APK. Например, Android предоставя няколко помощни програми за оцветяване на актив, като използва android: tint и android: tintmode в Android L или ColorFilter във всички версии.

Също така е възможно да се избегне спестяването на ресурси, които са само ротации на друг. Да приемем, че имаме две изображения с име ic_arrow_expand и ic_arrow_collapse:

Лесно можем да се отървем от ic_arrow_collapse, като създадем RotateDrawable, базиран на ic_arrow_expand. Тази техника също така намалява времето, необходимо на дизайнера, тъй като той ще трябва да създаде само едно изображение, а ние ще създадем завъртаните версии с:

Оказвайте в код, когато е необходимо

Понякога рендирането на графики директно от кода може да бъде от голяма полза. Един от най-добрите примери за колосално увеличаване на теглото е анимация кадър по кадър. Кирил Наскоро работите с Android Wear и разгледахте библиотеката за поддръжка на Android Wearable. Подобно на другите библиотеки, той съдържа няколко полезни класа при работа с носими устройства.

За съжаление, след създаването на основен Hello World, забелязахте, че APK в резултат тежат повече от 1.5MB. След проучване на wearable-support.aar, той открива, че две анимации кадър по кадър са пакетирани в 3 различни плътности: анимация за уведомяване за „Успех“ (31 кадъра) и друга „Отваряне по телефона“ (54 кадъра).

Анимацията за "успех" е изградена с AnimationDrawable, дефинирана в XML:

Недостатъкът е, че всеки кадър се показва за 33ms, което прави анимацията да работи с 30fps. Показването на кадър на всеки 16 ms би довело до двойно по-голяма библиотека. Рамката generic_confirmation_00175 (ред 15) се показва за 333ms, последвана от generic_confirmation_00185. Това е страхотна оптимизация, която предотвратява пакетирането на 9 кадъра (176-184) в приложението. За съжаление, wearable-support.aar съдържа тези 9 кадъра, които не се използват за 3 плътности.

Анимацията с използване на код изисква повече време за разработка. обаче може значително да намали размера на активите в APK и също така поддържа плавна анимация при 60 кадъра в секунда. По време на превода на тази статия Android не предоставя инструмент, който позволява лесното изобразяване на тези анимации. Дано работят по това.

Отидете още по-далеч

Всички описани по-горе техники са фокусирани главно върху приложението/библиотеката. Можем ли да стигнем по-далеч, ако имахме пълен контрол над дистрибуторската верига? Със сигурност би могло, но това ще включва известна работа от страна на сървъра или по-конкретно от страна на Play Store. Например Play Store може да има пакетна система, която пакетира само родните библиотеки, необходими за всяко устройство.

Друга възможност би била да се пакетира само необходимата конфигурация за устройството. За съжаление това би нарушило напълно една от най-важните функционалности на Android: Горещи промени в конфигурацията. Всъщност Android е проектиран да се справи с промените в конфигурацията по време на изпълнение (език, ориентация и т.н.). Например премахването на ресурси, несъвместими с плътността на екрана на устройството, би било голяма полза. Приложенията на Android обаче могат да се справят с промени в плътността на екрана в движение. Дори да отхвърлим тази възможност, пак ще трябва да се справим с чертежи, дефинирани за различна плътност, отколкото устройството, което инсталира приложението. В допълнение към тези, които имат повече от един класификатор на плътността (ориентация, по-малка ширина и т.н.).

Опаковката на APK от страна на сървъра изглежда изключително мощно. Но е много рисковано, тъй като APK Окончателната доставка на потребителя ще бъде напълно различна от тази, изпратена от разработчика до Play Store. Доставете a APK с премахнати някои ресурси/активи просто ще разбие приложенията.

Завършеност

Дизайнът се опитва да извлече най-доброто от набор от ограничения. Теглото/размерът на a APK това очевидно е едно от тези ограничения. Не се страхувайте да направите един аспект от приложението по-лош, за да подобрите другите. Например, не се колебайте да намалите качеството на визуализацията на потребителския интерфейс, ако размерът на APK в резултат се намали и приложението стане по-плавно. 99% от потребителите няма да забележат, че качеството е спаднало, но ще забележат, че приложението е по-плавно. В крайна сметка, дадено заявление се оценява по неговата съвкупност, а не по сумата на някои аспекти поотделно.

Благодаря на Кирил, че ми позволи да преведа оригиналната му статия „Поставяне на вашите APK на диета“