Android NativeActivity

Question

Le Android NDK vient d'être considérablement élargi pour inclure le support pour écrire Android applications entièrement en code natif C / C ++. On peut maintenant les événements d'entrée de capture sur l'écran du clavier et tactile à l'aide du code natif, ainsi que la mise en œuvre du cycle de vie des applications en C / C ++ en utilisant la nouvelle classe NativeActivity.

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

Answer 1

Le NDK n'est pas natif par-soi. Il est dans une large mesure une enveloppe JNI autour du SDK Android. L'utilisation NativeActivity vous donne un moyen pratique de faire face à certains événements du cycle de vie app-et ajoutez votre propre code natif sur le dessus. ALooper, AInputQueue etc. sont tous les emballages de JNI des SDK Java homologues, certains avec un code supplémentaire qui est privé et pour les applications réelles unaccessible.

En matière de développement Android, il n'y a pas une telle chose que d'écrire une application entièrement en C ++ natif - vous (dans tous les cas réel App que je peux penser) toujours besoin d'utiliser l'API Android: s, qui sont à une grande mesure Java pur. Que vous utilisez ces emballages à travers fournis par le NDK ou les emballages que vous créez ne change pas vraiment.

Alors, pour répondre à votre question: Non, ce ne serait pas la peine, parce que vous finirez par écrire wrappers JNI pour SDK appelle au lieu d'écrire des emballages JNI à vos propres méthodes Java qui font la même chose, avec moins de code, le code plus simple et un code plus rapide. Par exemple, montrant une boîte de dialogue en utilisant « pure c ++ », implique tout à fait 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, qui est disponible dans le NDK, puis continuer avec la mise en œuvre du système d'exploitation de AActivity, ALooper, AInputQueue etc. Google Code Search est une grande aide dans ce domaine. : -)

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

Answer 2

Non si vous faites juste une application standard. Le SDK Java est plus complet que son homologue autochtone en ce moment si vous continuerez à faire les choses plus difficiles pour vous-même.

Si vous ne faites pas quelque chose qui nécessite le NDK (lire: la performance en temps réel sensibles). Puis coller avec Java

Answer 3

Si vous le pouvez, bâton 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 avant - en particulier les ports de code existant -. Ce sera probablement une grande aide

Il est pas tout à fait clair encore ce qui a changé par rapport à simplement écrire votre propre wrapper mince java. Par exemple, est-il encore une copie de la machine virtuelle Dalvik traîner?

Answer 4

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. Il est évident que le code spécifique Obj-C iOS et plateforme ne travailleraient pas ailleurs. (Même chose pour la substance spécifique Android). Mais vous pourriez être en mesure ont un code partagé de la plate-forme neutre.