Програма Yelp для Android пішла на дієту

Колтін Каверхілл, інженер-програміст
12 травня 2016 р

Будь то використання акумулятора, мережа чи час, ми дуже дбаємо про ресурси наших користувачів. Великий додаток створює бар'єр для входу для користувачів у мережах з обмеженою або низькою швидкістю. Минулого Дня Подяки, наші автоматичні сповіщення дають нам зрозуміти, що розмір нашої програми стає більшим, ніж ми хотіли, і ускладнюють завантаження нашої програми для користувачів з низькими ресурсами.

Тут ми побачили тенденцію до зростання розміру програми, оскільки ми додали більше функцій і створили більш привабливу програму. Для того, щоб вирішити розмір програми, ми спочатку мали зрозуміти, звідки цей розмір.

Розбивка збірки випуску приблизно у вересні 2015 року.

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

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

Почало здаватися, що ми можемо значно змінити ситуацію, зменшивши розмір файлу наших зображень. У пошуках потенційних удосконалень ми дізналися, що Android 4.2.1 представив новий формат зображення під назвою WebP, який вимагав кращого стиснення, ніж JPEG або PNG. На щастя, програма Yelp підтримує Android 4.4+, і її зображення в основному є PNG з декількома JPEG. Щоб перевірити претензії WebP, ми перетворили понад 2000 наших PNG за допомогою цієї команди:

Лише 8 із понад 2000 PNG-файлів, які ми стислили, не отримали вигоди від перетворення на WebP, і різниця для них була надзвичайно незначною (лише близько 400 байт). Загалом, розмір нашого стиснутого файлу .apk зменшився з 27,1 МБ до 23,1 МБ без втрати якості зображень. Наша розбивка все ще надавала перевагу зображенням трохи, але не настільки суттєво.

Це зменшення розміру було чудовим, але ми мали сумніви щодо продуктивності роботи. Чи буде WebP вимагати набагато більше часу на обробку для декодування/відтворення? Чи в результаті ми використаємо більше пам'яті? Використовуючи інструменти продуктивності Android, ми не виявили жодного збільшення обсягу пам’яті чи завантаження процесора при завантаженні зображень WebP порівняно з їх варіантами PNG на різних пристроях. Подібні результати повідомляє ця стаття на WebP, яка є агностичною для Android.

Не маючи жодних проблем, ми перенесли це на виробництво. Ми встановили гачок перед фіксацією, який автоматично перетворює PNG у формат WebP без втрат. Це дозволило нам насолоджуватися набагато меншим додатком без необхідності зайвої розробки - виграй!

Однак історія на цьому не закінчується ...

А як щодо вмісту з втратами, як JPEG для фотографій?

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

Чому це було так божевільно щодо цієї нової картини!?

Виявилося, що деякі з цих зображень були досить великими JPEG, найбільший - 1,4 Мб. Пам’ятайте, що вони не будуть стиснені в остаточному файлі .apk, тому кожен байт кожного зображення буде передаватися користувачам. Всі нові активи разом узяли нам збільшення розміру APK на 34% порівняно з попереднім випуском, з 21,88 МБ до 29,39 МБ!

Щоб стиснути ці зображення, ми спробували перетворити на WebP без втрат, як це було раніше. Однак ці нові зображення були насиченими фотографіями з великою кількістю кольорів, тому ми не бачили подібних переваг від стиснення без втрат. Внаслідок стиснення без втрат у глухий кут, ми спробували використовувати компресію з втратами:

cwebp -pass 10 -m 6 -mt -jpeg_like -q 60 [2]

92 КБ 60 з втратою якості

62 КБ 40 з втратою якості

Скорочення були величезні! Після перетворення всіх нових зображень наш остаточний розмір файлу .apk становив 22,76 МБ, що стало значним покращенням порівняно з 29,39 МБ.

Оскільки цей процес був надзвичайно суб’єктивним, ми не додали цього до наших перехватів перед комітуванням. Деякі зображення, такі як піктограми, завжди повинні бути дуже якісними і стискатись лише без втрат; тоді як інші, як великі фотографії, отримають вигоду від різного ступеня стиснення з втратами. Прийняття такого рішення важко автоматизувати.

Для тих, хто застряг у PNG (підтримує minSdkVersion менше 17) або тих, хто ще не готовий перейти на WebP, Кольт Мак-Анліс написав дуже докладну статтю про стиснення PNG. Він включає безліч методів видалення непотрібних байтів із зображень, які не виходять за рамки цієї публікації.

Перетворення WebP було швидким і простим способом для нас різко зменшити розмір файлу .apk. Якщо у вашому додатку багато зображень, ця стратегія повинна допомогти і вам! Хоча ефекти зменшення розміру файлу .apk недостатньо відомі, він все ще залишається незрозумілим: коли ми можемо легко зменшити свій вплив на зберігання та використання даних наших користувачів, ми будемо!

Виноски

Cwebp - це програма, що надається Google для перетворення зображень у WebP. Тут ми дозволяємо йому робити максимальну кількість аналізів (-пас 10). Ми встановили метод стиснення на найповільніший (-m 6), щоб отримати найкраще стиснення. Ми ввімкнули багатопотоковість (-mt) для деяких покращень швидкості. І нарешті, ми вказали, що хочемо, щоб зображення було без втрат (-без втрат), щоб у нас не було втраченої якості в створеному зображенні WebP. Для кмітливого читача доступно набагато більше варіантів. ↩

Тут ми вилучили опцію без втрат (без втрат), так що cwebp насправді знищить якість зображення. Ми сказали cwebp використовувати метод стиснення, схожий на JPEG (-jpeg_like), оскільки ми знаємо, що це всі фотографії. І нарешті, у нас є параметр якості (-q 60), який схожий, але відрізняється від параметрів якості JPEG. Значення 60 було вибрано після експериментів з різними значеннями для цих конкретних фотографій, і, здавалося, це дало нам найбільше зменшення розміру файлу, перш ніж помітна значна втрата якості. Ваші конкретні зображення та порогові показники якості будуть різними. ↩