У попередній статті ми говорили про те, як зменшити розмір програми для Android, усунувши невикористані ресурси. У блозі Сіріла Мотьє я знайшов дуже цікаву статтю з кількома порадами щодо зменшення розміру файлу .apk та оптимізації коду у виробництві. Далі ми переходимо до перекладу важливих частин.

12 м. (2413 слів.)

свої

Олександрський міський голова

Науковець даних та комп’ютерник. Творець цього блогу.

У попередній статті ми говорили про те, як зменшити розмір програми для Android, усунувши невикористані ресурси. У блозі Кирило Мотьє Я знайшов дуже цікаву статтю з кількома порадами щодо зменшення розміру файлу .apk та оптимізації коду у виробництві. Далі ми переходимо до перекладу важливих частин:

Не секрет, що додатки займають дедалі більше місця. Перші програми раніше займали декілька 2 Мб у початкових версіях Android. Зараз досить часто можна спостерігати програми вагою від 10 до 20 Мб. Це збільшення розміру є прямим наслідком як очікувань користувачів, так і набуття досвіду розробниками. Основні причини збільшення розміру Файли .apk є:

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

Публікуйте легкі програми на Play Store це хороша практика, на яку повинен звертати увагу кожен хороший програміст при розробці програми. Чому?.

  • По-перше, тому що це синонім простої, підтримуваної та надійної кодової бази.
  • По-друге, оскільки програмісти, як правило, воліють залишатися нижче поточного ліміту Play Store, 50 Мб на APK якщо ви не хочете використовувати додаткові завантаження.
  • Нарешті, оскільки ми живемо у світі обмежень:
    • Обмежена пропускна здатність.
    • Обмежений простір на диску.
    • тощо.

Чим менший розмір файлу .apk, тим вища швидкість завантаження, менше розчарувань користувачів і, головне, кращі оцінки.

У багатьох (якщо не у всіх) випадках збільшення розміру є обов’язковим для задоволення вимог та очікувань користувачів. Тим не менше, Кирило переконаний, що вага APK зростає, як правило, швидше, ніж очікували користувачі. Насправді більшість додатків у Play Store вони займають вдвічі і більше, ніж мали б. Деякі методи/правила, які можна використовувати для зменшення остаточного розміру програми, будуть розглянуті нижче.

Перш ніж виконувати будь-яку оптимізацію, важливо зрозуміти формат APK. Загалом кажучи, a APK це заархівований файл, що складається з декількох файлів у стислій формі. Як програміст, ви можете легко переглянути його вміст, розпакувавши його за допомогою команди unzip .

Це те, що APK після запуску розпакування:

Більшість вищевказаного вмісту має бути знайомим кожному програмісту. Він відображає структуру проекту, яку можна спостерігати під час розробки./assets,/lib,/res, AndroidManifest.xml. classes.dex містить скомпільовану версію (dex) коду Java та resources.arsc попередньо скомпільовані ресурси, наприклад двійковий XML (значення, XML-малюнки тощо).

Тому що APK це простий заархівований файл, це означає, що він має два розміри - стислий та розпакований. І те, і інше важливо, але в цій статті ми зупинимося на стиснутому розмірі. Чим менший APK, тим менша розпакована версія.

Це можна зробити за допомогою різних методів. Оскільки кожна програма різна, немає абсолютного правила, щоб зробити "стрункішою" 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,5 Мб. Дослідивши носиму підтримку.aar, він виявив, що дві покрокові анімації упаковані в 3 різні щільності: анімація для повідомлення "Успіх" (31 кадр) і інша "Відкрити на телефоні" (54 кадри).

Анімація для "успіху" побудована за допомогою AnimationDrawable, визначеного в XML:

Недоліком є ​​те, що кожен кадр відображається протягом 33 мс, завдяки чому анімація працює зі швидкістю 30 кадрів в секунду. Показ кадру кожні 16 мс призвів би до створення бібліотеки вдвічі важчої. Кадр generic_confirmation_00175 (рядок 15) відображається протягом 333 мс, а потім 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 при вилученні деяких ресурсів/активів це просто зламало б програми.

Завершення

Дизайн намагається отримати найкраще із набору обмежень. Вага/розмір APK це явно одне з цих обмежень. Не бійтеся зробити один аспект програми гіршим, щоб покращити інші. Наприклад, не соромтеся знизити якість відображення інтерфейсу користувача, якщо, як наслідок, розмір файлу .apk зменшиться і додаток стане більш плавним. 99% користувачів не помітять, що якість знизилася, але вони помітять, що додаток більш гнучкий. Зрештою, заявка оцінюється за її сукупністю, а не за сумою окремих аспектів окремо.

Дякуємо Кирилу за те, що він дозволив мені перекласти його оригінальну статтю «Покласти свої APK на дієту»