Влияние использования Multidex на производительность приложения, стабильность, совместимость...?

Ответ 1

Я не специалист в Dalvik, но я работал над несколькими проектами, которые в какой-то момент требовали MultiDex, и это некоторые из уроков, которые я узнал:

Неудачные установки на некоторых устройствах?

Некоторые устройства, особенно старые телефоны Gingerbread (но также ICS), используют очень маленький буфер LinearAlloc, который может вызвать ошибки при установке или запуске приложения с слишком многими классами или чья иерархия классов слишком сложна. Включение MultiDex не вносит непосредственного вклада в эту проблему, но позволяет разработчикам продолжать "раздувание кода" до того момента, когда приложение становится слишком большим для запуска на этих устройствах... которое иногда замечает только когда начинаются сотни очень грустных пользователей позвонив в службу поддержки.

Медленный запуск приложения (при первом запуске или всегда)?

Первый запуск после установки или обновления определенно медленнее, главным образом из-за дорогостоящих операций ввода-вывода, необходимых для извлечения дополнительных файлов dex из APK в файловую систему. Последующие запуски также влияют пропорционально размеру и сложности классов, которые должны быть загружены, чтобы вывести свой первый Activity, так что хорошо сохранить основные компоненты приложения (особенно действия) в первичной документации, чтобы минимизировать время запуска, хотя это не всегда возможно.

Новые сбои или ANR на некоторых устройствах?

Мы видели ANR в телефонах Alcatel OneTouch (2.3.3) и Google Nexus One (2.3.6), которые были вызваны извлечением dex слишком долго. В более современных устройствах обновления и приложения для запуска с использованием холодного запуска могут занимать немного больше времени, но обычно недостаточно долго, чтобы вызывать ANR.

Общая деградация производительности?

Загрузка классов становится намного медленнее, что сказывается на приложении непредсказуемым образом. Если вы используете систему DI, Protobuf или какую-либо другую структуру, которая генерирует сотни классов, то вы можете обнаружить, что некоторые из ваших рабочих процессов становятся на 20-25% медленнее после включения multidex. Одним из способов смягчения этого является загрузка классов заблаговременно через, например, фоновый поток или BroadcastReceiver, но это, конечно же, увеличит объем памяти приложения и потенциально замедлит работу устройства.

Кроме того, некоторая оптимизация времени установки-времени также может быть пропущена, если dexopts обнаружит классы, отсутствующие в первичном dex, поэтому может быть значительный штраф в отношении использования ЦП и памяти, даже если только несколько классов попадают во вторичные dex.

Должен ли я приложить много усилий (т.е. путем тонкой настройки моей конфигурации Proguard, чтобы более агрессивно сжиматься, сбрасывать некоторые сторонние библиотеки и т.д.), чтобы соответствовать пределу 64K-методов, или мне нужно просто включить Multidex?

MultiDex решает предел метода 64K, но это не серебряная пуля, и IMHO не следует использовать в качестве предлога, чтобы избежать оптимизации размера APK, но если

• Вы ориентируетесь только на современные устройства (например, API 16 +)
• Время работы/холодного запуска не критично.
• У вас нет времени для оптимизации приложения далее

то MultiDex может быть подходящим, иначе удаление ненужного кода - это путь.

Ответ 2

В итоге я перешел к multidex, по сути, потому что дорожная карта моего приложения заставила бы меня сделать это в конечном итоге (так как я планирую интегрировать большие библиотеки в ближайшем будущем).

Это было более месяца и сотни тысяч инсталляций/обновлений многопользовательской APK, поэтому теперь я могу с уверенностью сказать, что переход к multidex не имел никакого существенного побочного эффекта в моем конкретном случае.

(обратите внимание: обновление только нацелено на API 11+, поэтому я не могу говорить о потенциальных проблемах с Android 2.x).