Android NativeActivity
Android NDK 刚刚进行了显着扩展，支持完全使用 Android 编写 Android 应用程序本机 C/C++ 代码。现在可以使用本机代码捕获键盘和触摸屏上的输入事件，还可以使用新的 NativeActivity 类在 C/C++ 中实现应用程序生命周期。
考虑到所有扩展的本机功能，完全绕过 Java 并用本机代码编写 Android 应用程序是否值得？
The Android NDK has just been significantly expanded to include support for writing android applications entirely in native C/C++ code. One can now capture input events on the keyboard and touch screen using native code, and also implement the application lifecycle in C/C++ using the new NativeActivity class.
Given all the expanded native capabilities, would it be worthwhile to completely bypass Java and write Android application in native code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
NDK 本身并不是原生的。它在很大程度上是 Android SDK 的 JNI 包装器。使用 NativeActivity 为您提供了一种处理某些应用程序生命周期事件的便捷方法，并在顶部添加您自己的本机代码。 ALooper、AInputQueue 等都是 Java SDK 对应项的 JNI 包装器，其中一些带有附加代码，这些代码是私有的且对于实际应用程序来说是无法访问的。
当谈到 Android 开发时，不存在完全用本机 C++ 编写应用程序这样的事情 - 你（在我能想到的每个真实的应用程序案例中）总是需要使用 Android API：s，这在很大程度上纯Java。无论您是通过 NDK 提供的包装器还是您自己创建的包装器来使用它们，都不会真正改变这一点。
所以，回答你的问题：不，这是不值得的，因为你最终会为 SDK 调用编写 JNI 包装器，而不是为你自己的 Java 方法编写 JNI 包装器来完成同样的事情，用更少的代码、更简单的代码和更快的代码。例如，使用“纯c++”显示对话框，涉及相当多的JNI调用。只需通过 JNI 调用执行相同操作的 Java 方法即可为您提供更快的代码（一次 JNI 调用），并且可以说，代码更易于维护。
要完全了解您可以做什么，您确实必须检查 Android 源代码。从 NDK 中提供的 native_app_glue.c 开始，然后继续 AActivity、ALooper、AInputQueue 等操作系统实现。Google 代码搜索在这方面提供了很大的帮助。 :-)
如果在 Java 中很容易做到，并且包含许多调用，请通过 JNI 调用一个方法来完成这一切，而不是编写所有额外的代码来通过多个 JNI 调用来完成这一切。尽可能多地保留现有的 C++ 代码。合理。
The NDK is not native per-se. It is to a large extent a JNI wrapper around the Android SDK. Using NativeActivity gives you a convenient way of dealing with certain app-life cycle events, and add your own native code on top. ALooper, AInputQueue etc. are all JNI wrappers of the Java SDK counterparts, some with additional code that is private and unaccessible for real apps.
When it comes to Android development, there's no such thing as writing an application entirely in native C++ - you will (in every real App case that I can think of) always need to use the Android API:s, which are to a huge extent pure Java. Wether you use these through wrappers provided by the NDK or wrappers that you create yourself doesn't really change this.
So, to answer your question: No, it wouldn't be worthwhile, because you would end up writing JNI wrappers for SDK calls instead of writing JNI wrappers to your own Java methods that do the same thing, with less code, simpler code and faster code. For example, showing a dialog using "pure c++", involves quite many JNI calls. Just calling a Java method through JNI that does the same thing will give you faster code (one JNI call), and, arguably, code that is easier to maintain.
To fully understand what you can do, you really must examine the Android source code. Start with native_app_glue.c, which is available in the NDK, then continue with the OS implementation of AActivity, ALooper, AInputQueue etc. Google Code Search is a great help in this. :-)
If it is easy to do in Java, and includes many calls, call a method through JNI that does it all, rather than writing all the extra code to do it with multiple JNI calls. Preserve as much of your existing C++ code as is reasonable.
如果您只是制作标准应用程序，则不然。 Java SDK 目前比其 Native 版本更完整，因此您仍然会让自己的事情变得更加困难。
如果您所做的事情不需要 NDK（即：实时性能敏感），那么请坚持使用 Java。
Not if you are just making a standard application. The Java SDK is more complete than its Native counterpart right now so you would still be making things more difficult for yourself.
If you are not doing something that requires the NDK (read: real time performance sensitive) then stick with Java.
只是一些值得深思的东西，但如果您有 iOS 和 Android 上的应用程序，一些 C/C++ 代码可能是可共享的。显然，iOS Obj-C 和平台特定的代码在其他地方不起作用。 （对于 Android 特定的东西也是如此）。但您也许可以拥有一些平台中立的共享代码。
Just some food for thought but if you have an app on iOS and Android, some C/C++ code might be shareable. Obviously the iOS Obj-C and platform specific code wouldn't work elsewhere. (Ditto for the Android specific stuff). But you might be able have some shared code that's platform neutral.
如果可以的话，坚持使用 Java 风格的应用程序，直到支持本机活动的 Android 版本占已安装基础的很大一部分。
对于以前很难做到的事情 - 特别是现有代码的移植 - 这可能会有很大的帮助。
目前尚不完全清楚与仅编写自己的瘦 java 包装器相比发生了什么变化。例如，是否还存在 dalvik VM 的副本？
If you can, stick with the java style apps until versions of Android supporting native activities constitute a significant fraction of the installed base.
For things that were hard to do before - particularly ports of existing code - this will probably be a big help.
It's not entirely clear yet what has changed vs. just writing your own thin java wrapper. For example, is there still a copy of the dalvik VM hanging around?