Android Natiective

Pas si vous faites une application standard. Le Java SDK est plus complet que son homologue autochtone pour le moment où vous feriez encore des choses plus difficiles pour vous-même.

Si vous ne faites pas quelque chose qui nécessite le NDK (lu: la performance en temps réel sensible à la performance), puis collez avec Java.

Juste de la nourriture pour la pensée, mais si vous avez une application sur iOS et Android, certains code C / C ++ pourraient être partageables. De toute évidence, le code spécifique de l'OBJ-C et de la plate-forme ne fonctionnerait pas ailleurs. (Idem pour les trucs spécifiques Android). Mais vous pourrez peut-être avoir du code partagé qui est neutre de la plate-forme.

Si vous le pouvez, collez avec les applications de style Java jusqu'à ce que des versions d'Android Soutenir les activités autochtones constituent une fraction importante de la base installée.

Pour les choses difficiles à faire avant - en particulier les ports de code existant - ce sera probablement une grande aide.

Ce n'est pas tout à fait évident que ce qui a changé et écrit simplement votre propre wrapper Java. Par exemple, y a-t-il encore une copie du Dalvik VM suspendu?

Le NDK n'est pas indigène en soi. C'est dans une large mesure une enveloppe JNI autour du SDK Android. L'utilisation de NativeActivity vous donne un moyen pratique de traiter certains événements de cycle de vie d'applications et d'ajouter votre propre code natif sur le dessus. Alooper, AinPutqueue etc. sont tous des emballages JNI des contreparties Java SDK, certains avec un code supplémentaire privé et inaccessible pour de vraies applications.

En ce qui concerne le développement Android, il n'existe pas d'application entièrement dans Native C ++ - vous devrez (dans toutes les véritables cas d'application que je peux penser) toujours besoin d'utiliser l'API Android: S, qui sont à une énorme mesure pure java. Que vous utilisez ces emballages fournis par les NDK ou les emballages que vous créez vous-même ne changent pas vraiment ceci.

Alors, pour répondre à votre question: Non, cela ne serait pas utile, car vous allez finir par écrire des wrappers JNI pour les appels SDK au lieu d'écrire des wrappers JNI à vos propres méthodes Java qui font la même chose, avec moins de code, avec moins de code, avec moins de code, code plus simple et code plus rapide. Par exemple, montrant une boîte de dialogue à l'aide de "Pure C ++", implique de nombreux appels JNI. Il suffit 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, le code qui est plus facile à maintenir.

Pour bien comprendre ce que vous pouvez faire, vous devez vraiment examiner le code source Android. Commencez par native_app_glue.c, disponible dans la NDK, puis continuez avec la mise en œuvre du système d'exploitation d'Aactivity, Alooper, AinPutQueue etc. La recherche de code Google est une bonne aide. : -)

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