完全通过NDK NativeActivity而不是通过Java SDK完成OpenGL + OpenCV是否值得表现？

Question

我即将开始一项涉及使用EPSON Moverio AR眼镜或类似产品的增强现实项目。假设我们使用这些眼镜，它们可以在Android 4.0.4 - API 15上运行。该应用程序将涉及近乎实时的视频分析（来自眼镜相机的帧），用于使用标记进行特征检测/跟踪，并在现实世界中覆盖3d对象'基于标记。

到目前为止，在技术方面，看起来我们将处理：

1. API 15
2. 的OpenCV
3. OpenGLES2

考虑到上述情况，我想知道是否值得通过NDK使用单NativeActivity和android_native_app_glue代码完成所有操作。当我说值得时，我的意思是表现明智。

当然，在C / C ++方面做这一切有一个优点，那就是代码可能会被移植，只需要很少的修改就可以在其他环境中运行。但OpenCV确实有Android的Java绑定，GL也可以在一定程度上用于Java。所以我只是想知道性能是否值得，或者它与使用GLSurfaceView的情况大致相同。

Answer 1

我在增强现实中工作。我见过的绝大多数应用都是原生的。 Google建议避免使用原生应用程序，除非绝对必要。我认为AR是必要的相对较少的案例之一。我所知道的好处是：

1. 原生相机访问将允许您获得更高的捕获帧速率。将数据传递到Java层会大大降低速度。即使OpenCV的非本机捕获在Java中也可能较慢，因为OpenCV primary在本机对象中维护数据。捕获帧率是限制更新对象姿势信息速度的限制因素。请注意，OpenCV的原生相机will not work on devices running Qualcomm's MSM optimized fork of android - 包括许多snapdragon设备。
2. Java中对OpenGL方法的每次调用不仅具有与本机相关的成本，而且还会执行相当多的额外检查。查看GLES20.cpp，其中包含GLES20类方法的本机实现。您将看到通过使用本机调用可以绕过相当多的逻辑。这在大多数移动应用程序中都很好，但3D渲染通常可以绕过这些检查和JNI开销获得显着的好处。这在AR中更为重要，因为您已经通过CV处理淹没了系统。
3. 您很可能希望您的检测相关代码采用原生代码。如果要查看本机和Java检测性能之间的差异，OpenCV会提供样本。前者将使用更少的资源并且更加一致。使用本机应用程序意味着您可以调用本机函数，而无需支付将大量数据从Java传递到本机的成本。
4. 由于缺乏垃圾收集和JNI，本机传感器访问更有效率，本机速率更加一致。如果您将以有趣的方式使用IMU数据，这是相关的。

您可能能够构建一个非原生应用程序，其中大部分代码都是原生代码，并且尽管基于Java，但运行良好，但它要困难得多。