11

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

鉴于所有扩展的本机功能，是否值得完全绕过 Java 并使用本机代码编写 Android 应用程序？

4

4 回答 4

8

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 等的 OS 实现。Google 代码搜索在这方面有很大帮助。:-)

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

于 2011-02-15T00:07:50.720 回答
4

如果您只是制作标准应用程序，则不会。Java SDK 现在比它的 Native 版本更完整，所以你仍然会让自己变得更加困难。

如果您不做需要 NDK 的事情（阅读：实时性能敏感），那么坚持使用 Java。

于 2010-12-07T02:40:30.910 回答
3

只是一些思考的食物，但如果你在 iOS 和 Android 上有一个应用程序，一些 C/C++ 代码可能是可共享的。显然，iOS Obj-C 和特定于平台的代码在其他地方是行不通的。（对于 Android 特定的东西也是如此）。但是您也许可以拥有一些平台中立的共享代码。

于 2010-12-07T03:36:42.320 回答
3

如果可以的话，坚持使用 java 风格的应用程序，直到支持本机活动的 Android 版本构成已安装基础的很大一部分。

对于以前很难做的事情——尤其是现有代码的移植——这可能会有很大的帮助。

与仅编写自己的瘦 Java 包装器相比，发生了什么变化还不完全清楚。例如，还有 dalvik VM 的副本吗？

于 2010-12-07T04:42:33.787 回答