Інженерні розмови: Покладіть SignEasy для Android на дієту

За останні кілька місяців ми зробили ряд удосконалень для програми Android SignEasy. Ми досягли великих успіхів, намагаючись створити кращий досвід для наших користувачів, і майже за рік зусиль ми перейшли від того, щоб виглядати так (ліворуч, червень 2015 р.), До цього (праворуч, червень 2016 р.)!

Перероблений додаток побудований на принципах Material Design (що є цікавою історією само по собі). Це не тільки відчуває себе швидше, але й забезпечує покращений досвід підписання. Однак, як і всі хороші речі, це оновлення коштувало дорого, а об’єм програми становив майже 35 МБ. Неприпустимо! Ми відчували біль наших користувачів і вирішили, що настав час поставити програму на вкрай необхідну дієту. Ось деякі з технік, які ми використовували.

Бібліотеки вдосталь

Додатки, як правило, використовують купу бібліотек, щоб продовжувати працювати, і я маю на увазі не лише ту сторонній бібліотеку, яку ви додали для анімації. Вам також потрібно включити SDK для зворотної сумісності з будь-яким API Google або навіть для створення матеріалу вашого додатка. Кожна додана вами залежність може суттєво сприяти розміру файлу .apk, особливо якщо ваш додаток уже тривалий час працює. Гарною відправною точкою є обрізання непотрібних бібліотек із вашого додатка.

Непотрібний багаж

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

ProTip: Якщо у вашому додатку використовуються сервіси Google Play, переконайтеся, що ви не включаєте цілу інформацію пакет у вашій збірці. З версії 6.5 ви можете вибірково включати потрібні вам бібліотеки - ні більше, ні менше. Це акуратний маленький фокус, який допоміг нам вирізати кілька серйозних МБ.

Завжди ProGuard

Переконайтеся, що ви застосовуєте ProGuard до свого файлу .apk. Це дуже ефективний інструмент, який видаляє всі невикористані класи, методи та поля із пакетованої програми, включаючи будь-які з бібліотек.

Якщо ви використовуєте AppCompat-v7 або підтримуєте бібліотеку-v4 у своєму додатку (що ви, мабуть, робите), переконайтеся, що у вашому файлі ProGuard немає жодного з цих рядків.

Бібліотеки підтримки самі по собі великі, і корисно, якщо ви дозволите ProGuard видаляти всі невикористані класи.

ProTip: Якщо ви використовуєте AppView SearchView у своєму додатку, додавання вищезазначених двох рядків може призвести до поломки. Це пов’язано з тим, що будь-який елемент AppCompat, який використовується в XML як рядок, не буде розпізнаний AAPT, а ProGuard позбавить клас. Щоб цього уникнути, додайте цей рядок назад до конфігурації ProGuard.

(Це працює з будь-яким класом, який використовується в XML як рядок.)

Зменшення та зменшення

Простий прийом - це сказати Gradle зменшити ресурси та видалити невикористані ресурси для вас, коли ви пакуєте програму. У файлі build.gradle додайте наступне до типу збірки, на який ви хочете вплинути:

Управління тягачами

З огляду на широкий спектр пристроїв Android на ринку, розробники, як правило, додають активи для 5 різних щільностей (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi), а також різні активи, якщо у вас є спеціальний інтерфейс для планшетів, як у нас. Усі ці зображення, упаковані в єдиний файл .apk, суттєво сприяють більшій кількості.

Будьте нещадними

Одного разу я отримав чудову пораду від Google Developer Advocate: визначте пристрої, якими користується більшість ваших клієнтів, і якщо вони не потрапляють у відрі mdpi-hdpi, видаліть ресурси для цих двох щільностей. Спочатку звучить трохи ризиковано, але це один із найефективніших способів позбутися хорошої частини цих МБ. Звичайно, потрібно трохи більше часу, щоб об’єкт xhdpi відображався на цих пристроях, але це навряд чи помітно.

Крім того, як уже згадувалося раніше, програма SignEasy має деякі активи, характерні для форм-фактора планшета. Через свої більші розміри порівняно з телефонними активами, ці зображення, як правило, також більші за розміром. Ми спробували з’ясувати, в який сегмент щільності потрапила більшість наших користувачів планшетів (це дуже допомогло), і були здивовані, побачивши, що більшість планшетних пристроїв мають щільність mdpi або xhdpi. Видалення всіх інших ресурсів для планшетів різко вплинуло на розмір файлу .apk.

Прийміть векторні малюнки ... серйозно

Як розробник Android, однією з найкращих практик, яку ви можете застосувати, є примушення розробників та дизайнерів почати використовувати SVG для активів зображень, які будуть включені у ваш проект як v ector тягачі . Це дозволяє замінити кілька PNG-файлів на одну векторну графіку, яка зберігає свою чіткість, незалежно від щільності пристрою, на якому вона відображається, - вона ж чиста магія. Хоча вона спочатку була доступна лише для Lollipop і вище, бібліотека підтримки 23.2 включає підтримку векторних малюнків аж до API 7. Плюс, Android Studio 1.4 представив чудовий маленький інструмент, який допомагає імпортувати векторну графіку у ваш проект. Це точно допоможе зменшити розмір файлу .apk.

Все невикористане

Ось кілька методів, які допоможуть вам відмовитись від тих менших невикористаних ресурсів. Незважаючи на те, що вони не мають великого впливу на розмір файлу .apk, в кінцевому рахунку кожен КБ має значення. Крім того, це допомагає підтримувати базу коду чистою.

Android Lint

Це дуже зручний інструмент, вбудований прямо в Android Studio (але як це не дивно знайти). Йти до Аналіз> Запустити перевірку за назвою . У діалоговому вікні перевірки введіть невикористані ресурси, виберіть обсяг (рекомендується весь проект) та запустіть. Lint аналізує всі ресурси (рядки, малюнки, розміри тощо), які ніде не використовуються у коді. Ви можете перейти до кожної пропозиції та видалити ресурс, або просто попросити Lint видалити все для вас. Простіше зробити останнє, а потім повторно додати те, що ви випадково видалили, особливо якщо ви ніколи раніше цього не робили, оскільки Lint, ймовірно, в підсумку запропонує дуже велику кількість невикористаних ресурсів.

Виберіть свої мови

Цікавим прийомом, який обговорювався в Google I/O 2016, було зазначення, які мови ви локалізуєте у своєму сценарії Gradle. Це позбавляє всіх інших рядкових файлів, які могли бути додані іншими бібліотеками мовами, які ви навіть не підтримуєте. Для цього вкажіть мови, які ви підтримуєте, у файлі build.gradle на рівні програми:

Розділення файлу .apk

Система Gradle дозволяє створювати кілька файлів .apk для збірки залежно від критерію розбиття. Хоча це не заохочується документацією Android, іноді найефективнішим способом обрізання файлу .apk є, наприклад, подрібнення. Ви можете зробити це різними способами:

ABI розколовся

Це особливо корисно, якщо ваш проект включає бібліотеки, написані у власному коді (файли .so), які підтримують різні архітектури процесора. Ви можете розділити свій файл .apk за архітектурою, щоб користувач, що працює під керуванням ABI, не отримував код для x86 тощо. Для цього до файлу build.gradle додайте наступне:

Розподіл рівня щільності

Цей підхід дозволяє створювати декілька файлів .apk, розділених за щільністю пристрою, щоб користувач із пристроєм xhdpi не мав активів, призначених для xxxhdpi. Для цього додайте у файл build.gradle на рівні програми наступне:

Щоб отримати повний перелік інших варіантів розділення, прочитайте це .

Я також рекомендую переглянути цю розмову Google I/O 2016 та прочитати відповідний блог, щоб дізнатися більше про способи зменшення розміру програми.

Після копіткого застосування більшості вищезазначених методів, команда SignEasy Android успішно зменшила розмір нашої програми майже на 30%. Тим не менш, ми ще не повністю задоволені, і ми плануємо випробувати ще більше способів полегшити зберігання даних на пристроях наших користувачів. Пам’ятайте, кожен КБ має значення.

Якщо у вас є запитання, думки та коментарі, знайдіть мене у Twitter @ApoorvaTyagi.