web-dev-qa-db-fra.com

Android?

J'ai quelques bibliothèques natives qui sont assez grandes et gonflent la taille binaire de l'application. J'ai examiné fractionnement de l'APK mais la maintenance et l'assurance qualité de plusieurs APK ne sont pas quelque chose que je veux faire.

Je voudrais donc exclure les architectures inutilisées dans ma version de version en utilisant la propriété Gradle ndk.abiFilters. (Les versions de débogage que je veux laisser seules afin de pouvoir exécuter l'émulateur accéléré HAXM sur x86).

Je pensais simplement avoir armeabi-v7a et arm64-v8a dans ma version finale, mais je ne sais pas si cela vaut la peine de s'inquiéter de la part de marché des autres architectures que je laisse tomber. Après beaucoup de recherches, je ne trouve aucune référence à la part de marché d'ARMv6 (armeabi), MIPS, x86 ou x86_64. Mon intuition me dit que les trois derniers sont presque inexistants, mais je ne suis pas sûr de ARMv6.

J'ai trouvé ce lien sur un forum qui a une liste de téléphones qui utilisent diverses architectures. Y a-t-il quelque chose de plus fiable quelque part? Peut-être avec% d'utilisateurs similaires au tableau de bord de la version Android version?

Autre chose que je pourrais manquer si je construis juste mes bibliothèques natives pour armeabi-v7a et arm64-v8a (ou armeabi, armeabi-v7a et arm64-v8a)?

androidandroid-ndkarm
39
kos

Tout d'abord, si vous vous inquiétez de la taille binaire, vous n'avez pas vraiment besoin d'arm64-v8a, tous ces périphériques peuvent très bien exécuter les binaires armeabi-v7a. Seulement si vous avez vraiment besoin d'en extraire la dernière performance supplémentaire, cela pourrait valoir la peine.

Quant à armeabi et ARMv6; Android lui-même ne le prend plus officiellement en charge depuis Android 4.4 (octobre 2013) - et depuis Android 4.0 il devrait être beaucoup moins courant (à partir de cette version, la source AOSP nécessite des modifications pour continuer à construire pour ARMv6). Donc, dans la pratique, si vous ne supportez pas les versions inférieures à 4.4, vous pouvez supprimer celle-ci sans perte significative.

Aussi, pour x86; beaucoup de ces appareils sont livrés avec une émulation étonnamment décente de binaires de bras, de sorte que ceux-ci peuvent très bien gérer avec la version armeabi-v7a.

38
mstorsjo

L'inclusion d'architectures supplémentaires n'aura plus d'impact sur la taille binaire lors de l'utilisation de bundles d'applications , car dans ce cas, Google Play ne servira à chaque appareil que les fichiers binaires qui s'appliquent à cet appareil particulier. Non seulement cela, mais aussi les mises à jour des applications seront beaucoup plus petites et plus rapides.

Laisser les informations précédentes pour les projets n'utilisant toujours pas les bundles d'application:

  • Malheureusement, le Android Dashboard , aussi utile soit-il, ne fournit pas d'informations sur l'architecture, pas plus que Google Analytics.

  • Statistiques Unity utilisé pour fournir statistiques par architecture et fonctionnalités CP . Notez cependant que ce ne sont pas des statistiques générales, mais ne couvrent que les utilisateurs des applications/jeux Unity. Les informations ne semblent plus être disponibles dans un lien public, j'ai donc remplacé les liens directs par les derniers instantanés dans archive.org.

30
Jose Gómez

Je suis bloqué ce problème lors de l'utilisation de Mapbox et j'ai trouvé cela article tellement utile.

Base sur l'image du bas dont vous avez juste besoin armeabi-v7a et x86 et base sur Jose Gómez réponse j'ajoute juste armeabi-v7a et je n'ai aucun problème.

Alors ajoutez cette ligne dans votre app.gradle

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

Si vous êtes toujours inquiet à propos de 2% - 3%, ceux qui utilisent une architecture x86 comme ASUS ZenFone et lenovo téléphones, vous devez utiliser cette ligne dans app.gradle

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

enter image description here

12
Radesh

Quand j'ai lu la réponse @mstorsjo, j'étais un peu confus sur la façon de n'utiliser vraiment qu'une (ou deux) bibliothèques natives, même si c'est assez simple et direct. Par conséquent, je vais donner ici un exemple et quelques explications supplémentaires (basées sur mes recherches ultérieures).

Pour chaque architecture prise en charge, nous devons créer un dossier spécifique dans le dossier jniLibs et y déposer le fichier .so. Par exemple, pour prendre en charge armeabi-v7a (32 bits) et arm64-v8a (64 bits):

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

Avec armeabi-v7a vous prenez en charge plus de 90% des appareils disponibles, mais comme il s'agit d'une architecture 32 bits, son exécution sur des appareils 64 bits entraînera une perte de performances (20-30%) - {1} . Pour chaque cas spécifique, il peut être très pratique de vérifier le nombre réel d'appareils pris en charge, ce qui peut être fait dans la console Google Play dans la section Gestion des versions> Catalogue d'appareils, en spécifiant ABI comme filtre.

Attention

Lorsque vous n'ajoutez pas de binaires pour toutes les architectures, vous devez être conscient des éléments suivants:

Si votre application contient d'autres bibliothèques natives, vous devrez vous assurer que vous n'en avez également que les mêmes versions. Cela est dû à Android exigeant que toutes les bibliothèques natives chargées soient construites pour la même architecture. Par exemple, si la première bibliothèque native chargée est armeabi-v7a, Android apparaîtra [~ # ~] seulement [~ # ~] pour armeabi-v7a bibliothèques sur tous les appels System.loadLibrary () après cela. S'il ne trouve pas cette architecture exacte, il lèvera l'exception Java.lang.UnsatisfiedLinkError. {1}

J'ai rencontré ce problème car certaines de mes dépendances utilisaient des bibliothèques natives, où armeabi-v7a ne pouvait plus être chargé.

3
goemic