Android OpenGL ES 通过 NDK : placement of jpg decompression and binding to texture

Question

这个问题有点主观，但不完全是:我希望听到其他人对此的经验(或者也应该有充分理由的答案)。

我正在编写一个 Android OpenGL ES 1.1 应用程序。它使用 NDK:核心 OpenGL 渲染在 native 代码中，很像 san-angeles OpenGL sample NDK 自带的。我使用的是作为 JPG 读入应用程序的 OpenGL 纹理。我知道这是如何完成的，但我想知道最有效的地方是什么(高效，我的意思是快速执行)。

为了说明，这里有一些基于我项目中的输入 JPG 绑定(bind) OpenGL 纹理的场景:

1) Java 代码从 JPG 生成位图(即解压缩它)，并使用 Java OpenGL 绑定(bind)绑定(bind)和加载纹理。纹理 ID 通过 NDK 传递给 native 代码，以便 native 代码可以使用它们进行纹理映射。

2) Java 代码从 JPG 生成位图(即解压缩它)，并将原始图像数据通过 NDK 传递给 native 代码，然后从该原始图像数据绑定(bind)并加载纹理。

3) Java 代码通过 NDK 将 JPG 数据(压缩)传递给 native 代码， native 代码解压缩位图，然后绑定(bind)并加载纹理。

我使用 NDK 和 native 代码不是出于速度原因，而是出于可移植性原因——我希望我的核心 OpenGL 代码能够在 iPhone 和 Android 上运行，就像在 san-angeles OpenGL sample 中一样。 NDK 自带的。我知道 native 代码不一定总是比 Java 代码快。

Answer 1

** jpeg 的 native 解压缩将比 Java 实现更快，假设两者都使用相同的算法。但是，差异不会很大。 **

为了可移植性，我保留了尽可能多的原生代码。这样，当我在平台之间移动时，我几乎不需要做任何事情来创建端口。我使用 SOIL 在 native 代码中解压缩 JPG，我发现性能与运行相同代码的 iOS 版本相当。当然，android 似乎并不慢。

关于 Assets ，我发现ZIP解压缩确实很慢。将 Assets 中的扩展名更改为 MP3 大大加快了加载速度。幸运的是，MP3 没有被压缩。制作Android Package时，assets文件夹下的所有文件都会放到APK中。 APK 是一个包含应用程序、资源和 Assets 的 zip 文件。打包完成后，一些文件会在未压缩的情况下添加到 zip 文件中。其中之一是 MP3。通过将您的文件重命名为 MP3，它们将在未压缩的情况下添加，因此加载速度更快。

我对你的问题的主观回答是

4) 使用与 iOS 相同的代码，在 native 代码中执行所有纹理加载和 Assets 管理。要解压缩 jpeg，请使用 libjpeg-turbo 或 SOIL，SOIL 更容易，libjpeg-turbo 非常快。使用 libzip 和 libz 访问您的 Assets ，确保将 MP3 扩展名添加到每个文件以防止 zip 压缩。

土壤 http://www.lonesock.net/soil.html

LIBZIP http://www.nih.at/libzip/

NDK 中可用的 LIBZ

libjpeg-turbo http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.git;a=summary