Использование архитектуры Android?

У меня есть несколько родных библиотек, которые довольно большие и раздувают бинарный размер приложения. Я просмотрел разбиение APK, но сохранение и QAing нескольких APK не является чем-то, что я хочу сделать.

Поэтому я хотел бы исключить неиспользуемые архитектуры в моем выпуске сборки сборки, используя свойство ndk.abiFilters Gradle. (Отладочные сборки я хочу оставить в покое, так что я могу запустить эмулятор с ускорением HAXM на x86).

Я думал о том, что у меня были только armeabi-v7a и arm64-v8a, но я не уверен, стоит ли беспокоиться о рыночной доле других архитектур, которые я бросаю. После многого оглядываясь, я не могу найти ссылки на долю рынка ARMv6 (armeabi), MIPS, x86 или x86_64. Моя интуиция говорит мне, что последние три почти не существуют, но я не уверен в ARMv6.

Я нашел эту ссылку на форуме, в которой есть список телефонов, использующих различные архитектуры. Где-то есть что-то более надежное? Может быть, с% пользователей, похожих на панель управления версией Android?

Что-нибудь еще, что я могу пропустить, если я просто создаю свои родные библиотеки для armeabi-v7a и arm64-v8a (или armeabi, armeabi-v7a и arm64-v8a)?

Ответ 1

Прежде всего, если вы беспокоитесь о двоичном размере, вам действительно не нужен arm64-v8a, все эти устройства могут запускать двоичные файлы armeabi-v7a просто отлично. Только если вам действительно нужно вырвать последнюю дополнительную производительность, это может быть полезно.

Что касается armeabi и ARMv6; Сам Android официально не поддерживает его больше, поскольку Android 4.4 (октябрь 2013 г.) - и с Android 4.0 он должен быть гораздо менее распространенным (из этой версии источник AOSP требует модификаций для ARMv6). Поэтому на практике, если вы не поддерживаете версии ниже 4.4, вы можете отказаться от этого без каких-либо существенных потерь.

Кроме того, для x86; многие из этих устройств поставляются с удивительно приличной эмуляцией бинарников для рук, поэтому они могут справиться с версией armeabi-v7a как можно точнее.

Ответ 2

Включение дополнительных архитектур больше не будет влиять на размер двоичного файла при использовании пакетов приложений, поскольку в этом случае Google Play будет обслуживать каждое устройство только двоичные файлы, которые применяются к этому конкретному устройству. Не только это, но и обновления приложений будут намного меньше и быстрее.

Оставляя предыдущую информацию для проектов, все еще не использующих комплекты приложений:

К сожалению, панель инструментов Android, как бы она ни была полезна, не предоставляет информации об архитектуре и Google Analytics.
Статистика Unity используется для предоставления статистики по архитектуре и функциям процессора. Тем не менее, обратите внимание, что это не общая статистика, а охватывает только пользователей приложений/игр Unity. Кажется, что информация больше не доступна в публичной ссылке, поэтому я заменил прямые ссылки на последние снимки в archive.org.

Ответ 3

Я застрял в этой проблеме при использовании Mapbox и нашел эту статью очень полезной.

Исходя из нижнего рисунка, вам просто нужны armeabi-v7a и x86, а основанный на ответе Хосе Гомеса, я просто добавляю armeabi-v7a, и у меня вообще нет проблем.

Так что добавьте эту строку в вашем app.gradle

android {
 defaultConfig {
        //other configs
        ndk {
            abiFilters "armeabi-v7a"
        }
    }
}

Если вы все еще беспокоитесь об этих 2% - 3% тех, кто использует архитектуру x86, такую как телефоны ASUS ZenFone и lenovo, вы должны использовать эту строку в app.gradle

ndk {
    abiFilters "armeabi-v7a", "x86"
}

Ответ 4

Когда я прочитал ответ @mstorsjo, я был немного озадачен тем, как на самом деле использовать только одну (или две) нативные библиотеки, даже если это довольно просто и понятно. Поэтому я приведу здесь пример и еще несколько объяснений (на основе моих дальнейших исследований).

Для каждой поддерживаемой архитектуры мы должны создать определенную папку в папке jniLibs и поместить туда файл .so. Например, для поддержки armeabi-v7a (32 бита) и arm64-v8a (64 бита):

|--app
|--|--src
|--|--|--main 
|--|--|--|--jniLibs 
|--|--|--|--|--armeabi-v7a 
|--|--|--|--|--|--.so Files 
|--|--|--|--|--arm64-v8a 
|--|--|--|--|--|--.so Files

С armeabi-v7a вы поддерживаете более 90% доступных устройств, но, поскольку это 32-битная архитектура, его запуск на 64-битных устройствах приведет к потере производительности (20-30%) {1}. Для каждого конкретного случая может быть очень удобно проверить фактическое количество поддерживаемых устройств, что можно сделать в консоли Google Play в разделе Управление выпусками> Каталог устройств, указав ABI в качестве фильтра.

Внимание

Если вы не добавляете двоичные файлы для всех архитектур, вы должны знать следующее:

Если ваше приложение содержит любые другие нативные библиотеки, вам необходимо убедиться, что у вас есть только те же версии, что и у них. Это связано с тем, что Android требует, чтобы все загруженные собственные библиотеки создавались для одной и той же архитектуры. Например, если первой загруженной собственной библиотекой является armeabi-v7a, Android будет искать ТОЛЬКО библиотеки armeabi-v7a во всех вызовах System.loadLibrary() после этого. Если он не найдет эту точную архитектуру, он выдаст исключение java.lang.UnsatisfiedLinkError. {1}

Я столкнулся с этой проблемой, потому что некоторые из моих зависимостей использовали собственные библиотеки, из-за чего armeabi-v7a больше не мог быть загружен.

Ответ 5

У меня есть игра в прямом эфире в магазине. Посмотрите, какие у меня есть данные обо всех этих архитекторах (см. Скриншоты прилагается)