Android NativeActivity

Question

Android NDK刚刚显着扩展，包括完全用本机C/C++代码编写android应用程序的支持。现在可以使用本地代码捕获键盘和触摸屏上的输入事件，并且还可以使用新的NativeActivity类在C/C++中实现应用程序生命周期。

考虑到所有扩展的本地功能，完全绕过Java并在本地代码中编写Android应用程序是否值得？

Answer 1

NDK本身不是本地的。它在很大程度上是围绕Android SDK的JNI包装。使用NativeActivity为您提供了处理某些应用程序生命周期事件的便捷方式，并且可以在顶部添加自己的本机代码。 ALooper，AInputQueue等都是Java SDK对应的JNI包装器，有些包含额外的代码，这些代码对于真正的应用程序是私有的和不可访问的。

当谈到Android开发时，就不会有这样的事情，就像完全用本地C++编写应用程序一样 - 您将（在我能想到的每个真实应用案例中）始终需要使用Android API：在很大程度上纯Java。无论你使用NDK提供的包装器还是你自己创建的包装器都不会改变这一点。

所以，回答你的问题：不，这不值得，因为你最终会为SDK调用编写JNI包装，而不是将JNI包装编写到自己的Java方法中，而这些方法执行相同的操作，代码少，更简单的代码和更快的代码。例如，显示使用“纯C++”的对话框，涉及相当多的JNI调用。只需通过JNI调用Java方法即可完成同样的任务，它将为您提供更快的代码（一个JNI调用），并且可以说更容易维护的代码。

要完全理解你能做什么，你必须检查Android源代码。从NDK中提供的native_app_glue.c开始，然后继续使用AActivity，ALooper，AInputQueue等的操作系统实现。谷歌代码搜索对此非常有帮助。 :-)

如果在Java中很容易做到并且包含很多调用，那么可以通过JNI调用一个完成所有工作的方法，而不是编写所有额外的代码来使用多个JNI调用来完成它。保留尽可能多的现有C++代码合理的。

Answer 2

不是如果你只是制作一个标准的应用程序。 Java SDK比现在的Native更完整，所以你仍然会让事情变得更加困难。

如果你没有做一些需要NDK的东西（阅读：实时性能敏感），然后坚持使用Java。

Answer 3

只是一些想法，但如果你在iOS和Android上有应用程序，一些C/C++代码可能是可共享的。很明显，iOS Obj-C和平台特定的代码在其他地方不起作用。 （同上Android的具体内容）。但是你可能有一些平台中立的共享代码。

Answer 4

如果可以，请坚持使用java风格的应用程序，直到支持本地活动的Android版本构成已安装基础的重要组成部分。

对于以前很难做的事情 - 特别是现有代码的端口 - 这可能是一个很大的帮助。

现在还不完全清楚，与刚编写自己的瘦Java包装器相比，有哪些变化。例如，是否还有dalvik VM的副本在附近？