Android NativeActivity

Question

Le Android NDK vient d'être considérablement élargi pour inclure le support pour l'écriture d'applications Android entièrement en code natif C/C++. On peut maintenant capturer des événements d'entrée sur le clavier et l'écran tactile en utilisant du code natif, et également implémenter le cycle de vie de l'application en C/C++ en utilisant la nouvelle classe NativeActivity.

Compte tenu de toutes les fonctionnalités natives étendues, serait-il utile de Java et écrire des applications Android complètement by-pass dans le code natif?

Answer 1

Le NDK n'est pas natif en soi. Il s'agit dans une large mesure d'un wrapper JNI autour du SDK Android. L'utilisation de NativeActivity vous offre un moyen pratique de gérer certains événements de cycle de vie d'application et d'ajouter votre propre code natif. ALooper, AInputQueue, etc. sont tous des wrappers JNI des homologues Java SDK, certains avec du code supplémentaire privé et inaccessible pour de vraies applications. En ce qui concerne le développement Android, écrire une application entièrement en C++ natif ne suffit pas: vous devrez toujours utiliser l'API Android (dans tous les cas d'applications réels): s, qui sont dans une large mesure pure Java. Que vous les utilisiez à travers des wrappers fournis par le NDK ou des wrappers que vous créez vous-même ne changez pas vraiment cela. Donc, pour répondre à votre question: Non, ça ne vaudrait pas le coup, car vous finissez par écrire des wrappers JNI pour les appels SDK au lieu d'écrire des wrappers JNI sur vos propres méthodes Java qui font la même chose, avec moins de code , code plus simple et code plus rapide. Par exemple, afficher une boîte de dialogue en utilisant "pure C++" implique beaucoup d'appels JNI. Le simple fait d'appeler une méthode Java via JNI qui fait la même chose vous donnera un code plus rapide (un appel JNI), et, sans doute, un code plus facile à maintenir.

Pour bien comprendre ce que vous pouvez faire, vous devez vraiment examiner le code source Android. Commencez avec native_app_glue.c, qui est disponible dans le NDK, puis continuez avec l'implémentation du système d'exploitation de AActivity, ALooper, AInputQueue, etc. Google Code Search est d'une grande aide dans ce domaine. :-)

S'il est facile à faire en Java, et inclut de nombreux appels, appelez une méthode via JNI qui fait tout, plutôt que d'écrire tout le code supplémentaire pour le faire avec plusieurs appels JNI. Conserver autant de votre code C++ existant que raisonnable.

Answer 2

Pas si vous faites simplement une application standard. Le SDK Java est plus complet que son homologue natif en ce moment, ce qui rendrait les choses encore plus difficiles pour vous.

Si vous ne faites pas quelque chose qui nécessite le NDK (lire: sensible aux performances en temps réel), alors gardez Java.

Answer 3

Juste un peu de nourriture pour la pensée, mais si vous avez une application sur iOS et Android, certains C/C++ code peut être partageable. De toute évidence, le code iOS Obj-C et le code spécifique à la plate-forme ne fonctionneraient pas ailleurs. (Idem pour les trucs spécifiques Android). Mais vous pourriez avoir un code partagé neutre pour la plate-forme.

Answer 4

Si vous le pouvez, coller avec les applications de style java jusqu'à ce que les versions de soutenir les activités natives Android constituent une fraction importante de la base installée.

Pour les choses qui étaient difficiles à faire auparavant - en particulier les ports de code existant - cela sera probablement d'une grande aide.

On ne sait pas encore exactement ce qui a changé par rapport à l'écriture de votre propre wrapper Java fin. Par exemple, existe-t-il encore une copie de la machine virtuelle dalvik?