Pourquoi utiliser le code armeabi-v7a sur le code armeabi?
Dans mon projet actuel, j'utilise plusieurs fichiers .so. Ceux-ci sont situés dans les dossiers armeabi et armeabi-v7a. Malheureusement, l’un des fichiers .so est un fichier de 6 Mo et j’ai besoin de réduire la taille du fichier. Au lieu d'avoir un fichier APK gros, je voudrais utiliser uniquement les fichiers armeabi et supprimer le dossier armeabi-v7a.
Selon la documentation de NDK, le code armeabi-v7a est un code armeabi étendu pouvant contenir des instructions supplémentaires du processeur. Tout cela dépasse mon expertise, mais je me demande pourquoi on aimerait avoir à la fois armeabi-v7a et armeabi. Il doit y avoir une bonne raison d'avoir les deux, non?
Sur mes appareils de test, tout semble bien fonctionner. Ceux-ci ont ARM v7. Est-il prudent de supposer que tout fonctionne maintenant?
Cela dépend de ce que fait votre code natif, mais la v7a prend en charge les opérations matérielles en virgule flottante, ce qui fait une énorme différence. armeabi fonctionnera bien sur tous les périphériques, mais sera beaucoup plus lent et ne tirera pas parti des capacités de processeur des nouveaux périphériques. Prenez quelques points de repère pour votre application particulière, mais la suppression des fichiers binaires armeabi-v7a n’est généralement pas une bonne idée. Si vous devez réduire la taille, vous pouvez avoir deux apks distincts pour les appareils plus anciens (armeabi) et les plus récents (armeabi-v7a).
EABI = Interface binaire d'application intégrée. Ce sont ces spécifications auxquelles un exécutable doit se conformer pour pouvoir s'exécuter dans un environnement d'exécution spécifique. Il spécifie également divers aspects de la compilation et du couplage requis pour l'interopérabilité entre les chaînes d'outils utilisées pour l'architecture ARM. Dans ce contexte, lorsque nous parlons de armeabi, nous parlons de l'architecture ARM et du système d'exploitation GNU/Linux. Android suit le little-endian ARM ABI GNU/Linux.
l'application armeabi s'exécutera sur ARMv5 (par exemple ARM9) et ARMv6 (par exemple ARM11). Vous pouvez utiliser du matériel en virgule flottante si vous construisez votre application en utilisant les options GCC appropriées, telles que - (mfpu = vfpv3 -mfloat-abi = softfp qui indique au compilateur de générer des instructions en virgule flottante pour le matériel VFP et active le logiciel conventions d'appel. armeabi ne prend pas en charge les conventions d'appel rigides (cela signifie que les registres FP ne sont pas utilisés pour contenir des arguments pour une fonction), mais les opérations FP de HW sont toujours prises en charge.
l'application armeabi-v7a s'exécutera sur les périphériques Cortex A #, tels que les Cortex A8, A9 et A15. Il supporte les processeurs multi-core et - mfloat-abi = hard. Donc, si vous construisez votre application en utilisant - - mfloat-abi = hard, la plupart de vos appels de fonction seront plus rapides.
Au lieu d'avoir un fichier APK gros, je voudrais utiliser uniquement les fichiers armeabi et supprimer le dossier armeabi-v7a.
Le contraire est une stratégie bien meilleure. Si vous avez minSdkVersion à 14 et que vous téléchargez votre apk sur le Play Store, vous remarquerez que vous supporterez le même nombre de périphériques, que vous supportiez armeabi ou pas. Par conséquent, il n'y a aucun appareil avec Android 4 ou supérieur qui pourrait bénéficier de armeabi.
C'est probablement pourquoi Android NDK ne prend même plus en charge armeabi conformément à la révision r17b. [ source ]