À la découverte du SDK de compression de bibliothèque native pour les applications Android

Les applications Android sont généralement écrites en Java en raison de sa conception orientée objet élégante, et du fait que le kit de développement logiciel Android (Android SDK) fournit des fonctionnalités multiplateforme en Java. Cependant, les développeurs doivent parfois utiliser l'interface native d'Android, surtout si la gestion de la mémoire et les performances sont critiques. L'interface native d'Android est fournie par le kit de développement natif (NDK), permettant le développement natif en C/C++.

Il existe de nombreuses applications NDK sur le magasin de logiciels de Google. Pour réduire la taille du paquet, certains développeurs de logiciels fournissent un seul APK, mais pas un APK FAT (un seul APK contient soit un ARM, soit une bibliothèque x86 tandis qu'un APK FAT intègre les deux à la fois). En effet, les APK FAT ont des avantages par rapport aux APK simples. Ils sont plus accessibles pour les utilisateurs finaux et les bibliothèques ne se chevauchent pas lors de la mise à jour de l'application. Les développeurs sont donc encouragés à choisir des APK FAT pour l'écosystème de logiciels x86 Android. Mais comment les développeurs peuvent réduire la grande taille des fichiers APK FAT ?

Pour résoudre le problème de la taille de l'APK FAT, l'auteur a développé un SDK de compression de bibliothèque native. L'idée est d'utiliser l'algorithme de chaîne Lempel-Ziv-Markov (LZMA) (http://www.7-zip.org/sdk.html) pour compresser les bibliothèques natives. Google utilise Zip pour compresser tout le contenu, et malgré que Zip soit rapide, son taux de compression est inférieur à LZMA. D'ailleurs, LZMA est particulièrement efficace pour la compression des volumineux fichiers de dictionnaires qui se trouvent dans les bibliothèques natives. Le graphique suivant montre la différence dans la taille des fichiers après avoir effectué des compressions avec Zip et LZMA.

À partir des quatre graphiques ci-dessus, nous pouvons conclure que LZMA peut réduire la redondance entre les fichiers. Dans les cas extrêmes (trois fichiers identiques), LZMA peut obtenir un taux de compression plus élevé que Zip. Cette fonctionnalité est particulièrement adaptée pour la compression de bibliothèques natives. Généralement, une bibliothèque native utilise le même code pour obtenir « armeabi », « armeabi-V7A », « x86 » ou même les bibliothèques « mips ». Pour « armeabi-V7A », il y a un code ARM NEON et un code non NEON. Ces bibliothèques ont des redondances dues au même code source. Même avec une architecture différente, par exemple libffmpeg_armv7_vfpv3.so et libffmpeg_x86.so, quand l'un est ARMEABI et l'autre x86, le taux de compression est de 40 % tandis que pour un seul fichier, le taux n'est que de 20 %.

Le SDK de compression de bibliothèque native développé par l'auteur peut aider les développeurs d'applications dans l'intégration de la compression LZMA de bibliothèque native, et ce pour obtenir des fichiers plus petits. L'idée de base de ce SDK est de compresser l'ensemble de la bibliothèque native dans le dossier « asserts ».

L'API dans ce SDK est très simple. À la première exécution de cette application, le code extrait la totalité de la bibliothèque native du dossier « asserts ».

static boolean NewInstance(Context cont,Handler hdl,boolean showProgress)
static DecRawso GetInstance()
String GetPath(String libname)

Il est recommandé que les développeurs d'applications modifient le code source et ajoutent seulement NewInstance au démarrage de l'application, puis changent system.loadLibrary(***) en System.load (DecRawso. GetInstance(). GetPath(***)). Après ces changements mineurs, l'APK sera plus petit et s'exécutera comme précédemment.

Si les développeurs peuvent retarder suffisamment l'appel de NewInstance jusqu'au premier chargement de bibliothèque native, ils doivent appeler (NewInstance(cont, null, false)) sans le Handler. Sinon, un Handler doit être ajouté pour recevoir le message asynchrone “decode end”.

L'auteur a intégré ce SDK dans MoboPlayer sur une tablette de processeur Intel ® Atom ™ Z2760 (nom de code Clover Trail). Le code appelle NewInstance dans la méthode de synchronisation lorsque les utilisateurs démarrent l'application et l'écran de démarrage est affiché. L'appel de NewInsance est transparent pour l'utilisateur final, car le décodage est effectué en arrière-plan. Le tableau suivant montre le résultat de la compression :

Outre la compression LZMA, ce SDK fournit des fonctions supplémentaires pour encourager les développeurs à inclure une bibliothèque native x86 comme suit :

1. Le stockage sur Cloud : les éditeurs de logiciels peuvent stocker les bibliothèques x86 sur un serveur et ces dernières peuvent être téléchargées à partir du serveur après l'installation. Cette action se fait automatiquement sur des appareils x86 et n'est activée que lorsque le Wi-Fi est connecté ;
2. Détection des bibliothèques manquantes : si les bibliothèques x86 sont manquantes, le SDK va automatiquement réextraire les bibliothèques ARM. Un développeur peut copier la bibliothèque ARM dans le dossier x86 pour éviter ce problème, mais il faut s'assurer qu'il n'y ait pas de référence croisée entre les bibliothèques ARM et x86 ;
3. L'outil de construction de paquets Java : un outil de construction de paquet Java est fourni pour convertir les APK normaux en APK de LZMA compressés. Cet outil prend en charge les systèmes Windows, Linux, Mac. Vous pouvez l'utiliser comme suit : ComPressApk.jar-C :/ mon test.APK-kc :/ clé / *** # # # alias, si "-k" est absent (c'est-à-dire, vous pouvez simplement appeler ComPressApk . pot-C :/ mon / test.APK), la touche de test par défaut « Eclipse » sera utilisée pour signer cet APK. Cet outil peut être intégré dans un script de construction « ants » pour gérer automatiquement la compilation et la publication ;
4. Le filtre : la fonction ConfigureFilter vous permet seulement d'extraire les bibliothèques nécessaires. Par exemple, enteringConfigureFilter("libffmpeg", "libffmpeg_armv7_neon.so") signifie qu'il faut extraire uniquement libffmpeg_armv7_neon.so parmi toutes les bibliothèques qui commencent par « libffmpeg ». Ceci est utile pour réduire la taille de la post-installation.

L'utilisation du SDK de compression de bibliothèque native pour vos applications Android peut réduire considérablement la taille du paquet de la bibliothèque native et permettre aux applications d'utiliser de grandes bibliothèques natives (en général, ces applications sont des lecteurs vidéo, navigateurs et des jeux en 3D). Pour le code source et le support technique, merci de contacter l'auteur.

Toutes les infos et outils sur Intel Developer Zone Android

A travers le programme IDZ encore appelé « la Zone des développeurs Intel», Intel a pour ambition d'encourager et de soutenir les développeurs indépendants en mettant à leur disposition, tous les outils dont ils ont besoin pour concevoir des applications natives, multiplateformes et innovantes pour les PC, smartphones et tablettes fonctionnant sous les processeurs Intel.

Découvrez la zone des développeurs Android d'Intel

• Native Library Compression SDK for Android Apps, par YUMING L

Yuming Li (Yuming.li @ intel.com) est un ingénieur applications logicielles dans le groupe Intel Software and Services. Il se concentre actuellement sur les applications liées au multimédia et permettant l'optimisation des performances, en particulier sur les plates-formes mobiles Android.

Les résultats ont été estimés sur la base de l'analyse interne par Intel ® et sont fournis à titre informatif seulement. Toute différence dans la configuration matérielle ou la conception de logiciels ou de configuration peut affecter la performance réelle.