这个问题接近主观，但并不完全：我希望听到别人对此的经验（或者也应该有充分理由的答案）。
我正在编写Android OpenGL ES 1.1应用程序。它使用NDK：核心OpenGL渲染采用本机代码，非常类似于NDK附带的san-angeles OpenGL sample。我正在使用OpenGL纹理作为JPG读入应用程序。我知道这是怎么做的，但我想知道这是最有效的地方（通过高效，我的意思是快速执行）。
为了说明，这里有几个基于我项目中的输入JPG绑定OpenGL纹理的场景：
1）Java代码从JPG创建一个位图（即解压缩它），并使用Java OpenGL绑定绑定和加载纹理。纹理ID通过NDK传递给本机代码，以便本机代码可以将它们用于纹理映射。
2）Java代码从JPG创建一个位图（即解压缩它），并将原始图像数据通过NDK传递给本机代码，然后从原始图像数据中绑定并加载纹理。
3）Java代码通过NDK将JPG数据（压缩）传递给本机代码，该代码解压缩位图，然后绑定并加载纹理。
我使用NDK和本机代码不是出于速度原因，但出于便携性原因 - 我希望我的核心OpenGL代码可以在iPhone和Android上运行，就像NDK附带的san-angeles OpenGL sample一样。我知道本机并不总是比Java代码更快。
答案 0 :(得分：3)
**假设两者都使用相同的算法，jpeg的原生解压缩将比Java实现更快。然而，差异并不大。 **
为了便于携带，我尽可能多地保留原生代码。这样，当我在平台之间移动时，我几乎没有什么可以创建端口。我使用SOIL在本机代码中解压缩JPG，我发现性能与运行相同代码的iOS版本相当。当然android似乎没有任何慢。
关于资产，我发现ZIP解压缩确实很慢。将资产扩展名更改为MP3大幅加载。感谢MP3不要压缩。 制作Android软件包后，资产文件夹中的所有文件都会放入APK中。 APK是包含应用程序，资源和资产的zip文件。在创建包时，一些文件被添加到zip文件而不进行压缩。其中之一是MP3。通过将文件重命名为MP3，它们可以不加压缩地添加，因此加载速度更快。
我对你问题的主观回答是
4）使用您用于iOS的相同代码，在Native Code中完成所有纹理加载和资产管理。要解压缩jpegs使用libjpeg-turbo或SOIL，SOIL更容易，libjpeg-turbo非常快。使用libzip和libz访问您的资产，确保在每个文件上添加MP3扩展名以防止压缩。
SOIL 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