1. 从零理解纯Native层PNG贴图的核心逻辑
做过Android图形开发的同行大多有个共识：一旦涉及OpenGL ES，大部分人第一反应是跑在Java/Kotlin层，用GLSurfaceView配合GLES20那一套API。但真正往底层走，尤其是做视频编辑、相机预览、游戏引擎或者车载UI这类对性能和延迟极度敏感的场景时，纯Native层实现才是绕不开的路。这个项目标题说的就是这件事——不借助任何Java层的OpenGL封装，直接在C/C++里完成PNG图片的解码、纹理上传和渲染贴图。
先把这个事情拆开看。所谓“纯Native实现PNG图片贴图”，核心链路其实就四步：读取PNG文件、解码成RGBA像素数据、创建并绑定GL纹理、通过着色器把纹理画到屏幕上。听起来简单，但每一步在Native层都有坑。比如PNG解码，Native层没有BitmapFactory可用，你得自己引入libpng或者stb_image；再比如EGL环境的搭建，Native层不像Java层有GLSurfaceView帮你管好上下文，你得手动创建EGLDisplay、EGLSurface、EGLContext，还要处理ANativeWindow的绑定。
这个内容适合谁看？如果你已经写过Java层的OpenGL ES，想往Native层深入，或者你在做NDK相关的图形项目，需要把图片渲染逻辑下沉到C++，那这篇就是给你准备的。哪怕你之前没碰过EGL，只要懂基本的C++和OpenGL概念，跟着走一遍也能跑通。
我个人的经验是，Native层做贴图最大的价值在于可控性和性能。Java层的Bitmap解码会经过Java堆，大图容易触发GC抖动；而Native层直接操作像素内存，配合glTexImage2D上传，整个链路没有额外的内存拷贝。另外，Native层可以更精细地控制纹理格式、过滤参数、mipmap策略，这些在复杂渲染管线里非常关键。
注意：纯Native实现并不意味着完全脱离Android框架，你仍然需要
ANativeWindow来获取原生窗口句柄，只是OpenGL的调用全部在C/C++侧完成。
2. 环境搭建与核心依赖选型
2.1 Native层PNG解码方案对比
在Native层解码PNG，常见的选择有三个：libpng、stb_image、以及Android NDK自带的imagedecoder（Android 11+）。我实际用下来，各有取舍。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| libpng | 功能完整，支持所有PNG特性 | 依赖zlib，编译配置繁琐 | 需要处理复杂PNG（交错、16位） |
| stb_image | 单头文件，零依赖，集成极简 | 不支持某些冷门PNG特性 | 快速原型、中小项目 |
| NDK imagedecoder | 系统原生，无需额外编译 | 仅Android 11+，API受限 | 新项目、不想引入第三方库 |
我这次选的是stb_image，原因很简单：一个头文件搞定，不需要折腾CMake里的zlib链接。对于贴图这个场景，绝大多数PNG都是标准的8位RGBA/RGB，stb_image完全够用。如果你要做商业级产品，对PNG兼容性要求极高，那还是老老实实上libpng。
2.2 CMake配置与依赖引入
在CMakeLists.txt里，核心是链接OpenGL ES、EGL、Android和log库。下面是我实际用的配置：
cmake_minimum_required(VERSION 3.18.1) project(native_png_texture) add_library(native_png_texture SHARED native_render.cpp egl_core.cpp ) target_include_directories(native_png_texture PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/third_party ) find_library(EGL_LIB egl) find_library(GLES_LIB GLESv3) find_library(ANDROID_LIB android) find_library(LOG_LIB log) target_link_libraries(native_png_texture ${EGL_LIB} ${GLES_LIB} ${ANDROID_LIB} ${LOG_LIB} )这里有个细节：GLESv3对应OpenGL ES 3.0，如果你只用2.0特性，换成GLESv2也行。但既然是新项目，我建议直接上3.0，纹理相关的API更丰富，比如glTexStorage2D这种不可变纹理存储，性能更好。
stb_image的引入就是把stb_image.h丢到third_party目录，然后在某个.cpp里定义STB_IMAGE_IMPLEMENTATION宏再include。注意，这个宏只能在一个编译单元里定义，否则会重复符号。
#define STB_IMAGE_IMPLEMENTATION #include "stb_image.h"2.3 EGL上下文初始化要点
Native层没有GLSurfaceView，EGL环境得自己搭。核心流程是：获取EGLDisplay、选择EGLConfig、创建EGLContext、创建EGLSurface并绑定ANativeWindow。
EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY); eglInitialize(display, &major, &minor); const EGLint configAttribs[] = { EGL_SURFACE_TYPE, EGL_WINDOW_BIT, EGL_RENDERABLE_TYPE, EGL_OPENGL_ES3_BIT, EGL_RED_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_BLUE_SIZE, 8, EGL_ALPHA_SIZE, 8, EGL_NONE }; eglChooseConfig(display, configAttribs, &config, 1, &numConfigs); const EGLint contextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 3, EGL_NONE }; EGLContext context = eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs); EGLSurface surface = eglCreateWindowSurface(display, config, nativeWindow, nullptr); eglMakeCurrent(display, surface, surface, context);提示：
eglCreateWindowSurface的第三个参数是ANativeWindow*，这个指针通常从Java层的Surface通过ANativeWindow_fromSurface获取，或者从SurfaceTexture回调里拿到。
踩过的坑：EGLConfig的选择一定要匹配你的渲染需求。如果你需要透明背景，EGL_ALPHA_SIZE必须至少为8；如果你要做多重采样，还得加上EGL_SAMPLE_BUFFERS和EGL_SAMPLES。选错了config，后面渲染出来的画面要么颜色不对，要么直接黑屏。
3. PNG解码与纹理上传的完整实操
3.1 PNG像素数据的读取与格式转换
stb_image的调用非常直接：
int width, height, channels; unsigned char* data = stbi_load(pngPath, &width, &height, &channels, 4); if (!data) { LOGE("Failed to load PNG: %s", stbi_failure_reason()); return; }第四个参数传4，强制输出RGBA四通道。为什么强制RGBA？因为OpenGL ES的纹理上传对像素格式有要求，GL_RGBA是最通用的，避免了RGB三通道时还需要处理字节对齐问题。默认情况下，OpenGL假定每行像素按4字节对齐，如果你的图片宽度是奇数且用RGB格式，就会出现错位。强制RGBA直接绕开这个坑。
解码完成后，data就是一块连续的RGBA像素内存，大小是width * height * 4字节。这块内存是stb_image在堆上分配的，用完必须stbi_image_free(data)释放，否则内存泄漏。
3.2 纹理对象的创建与参数配置
纹理创建这一步，参数配置直接决定了渲染质量和性能。
GLuint textureId; glGenTextures(1, &textureId); glBindTexture(GL_TEXTURE_2D, textureId); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data); glGenerateMipmap(GL_TEXTURE_2D);逐条解释一下这些参数背后的逻辑。GL_TEXTURE_MIN_FILTER设为GL_LINEAR_MIPMAP_LINEAR，意思是当纹理被缩小时，使用三线性过滤，配合mipmap能有效减少摩尔纹和闪烁。GL_TEXTURE_MAG_FILTER设为GL_LINEAR，放大时用双线性插值，画面平滑。GL_CLAMP_TO_EDGE是防止纹理坐标超出[0,1]范围时出现边缘重复，贴图场景下这个设置最安全。
glTexImage2D的第二个参数是mipmap层级，0表示基础层。内部格式和外部格式都传GL_RGBA，数据类型GL_UNSIGNED_BYTE。这里有个性能优化点：如果你的图片不需要mipmap，把MIN_FILTER改成GL_LINEAR并去掉glGenerateMipmap，能省不少显存和生成时间。但贴图如果会被缩放显示，mipmap还是建议加上。
注意：
glGenerateMipmap必须在glTexImage2D之后调用，且纹理必须已经绑定了完整的像素数据，否则会生成错误的mipmap。
3.3 着色器编写与纹理采样
顶点着色器负责把顶点坐标从模型空间变换到裁剪空间，同时传递纹理坐标：
#version 300 es layout(location = 0) in vec4 aPosition; layout(location = 1) in vec2 aTexCoord; out vec2 vTexCoord; void main() { gl_Position = aPosition; vTexCoord = aTexCoord; }片段着色器做纹理采样：
#version 300 es precision mediump float; in vec2 vTexCoord; uniform sampler2D uTexture; out vec4 fragColor; void main() { fragColor = texture(uTexture, vTexCoord); }这里顶点坐标我直接用了NDC（标准化设备坐标），也就是[-1,1]范围，省去了矩阵变换。实际项目里你肯定需要MVP矩阵，但作为最小可复现Demo，这样写最直观。纹理坐标的Y轴要注意，PNG解码出来的像素数据是自上而下的，而OpenGL的纹理坐标原点在左下角，所以要么在着色器里翻转Y，要么在顶点数据里把纹理坐标的Y反过来。
我习惯在顶点数据里处理：
const GLfloat vertices[] = { // 位置 // 纹理坐标 -1.0f, -1.0f, 0.0f, 1.0f, 1.0f, -1.0f, 1.0f, 1.0f, -1.0f, 1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 1.0f, 0.0f, };这样纹理坐标的(0,0)对应图片左上角，渲染出来就是正的。
3.4 绘制调用与缓冲区管理
用VBO管理顶点数据：
GLuint vbo; glGenBuffers(1, &vbo); glBindBuffer(GL_ARRAY_BUFFER, vbo); glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW); glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 4 * sizeof(GLfloat), (void*)0); glEnableVertexAttribArray(0); glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, 4 * sizeof(GLfloat), (void*)(2 * sizeof(GLfloat))); glEnableVertexAttribArray(1);步长是4 * sizeof(GLfloat)，因为每个顶点有4个float（2个位置+2个纹理坐标）。偏移量用(void*)强转，这是OpenGL ES 3.0的写法，2.0里得用(const GLvoid*)。
绘制：
glClearColor(0.0f, 0.0f, 0.0f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glUseProgram(program); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, textureId); glUniform1i(uTextureLoc, 0); glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); eglSwapBuffers(display, surface);用GL_TRIANGLE_STRIP画四个顶点，比GL_TRIANGLES少两个顶点索引，效率更高。glUniform1i把纹理单元0绑定到着色器的uTexture，这一步不能漏，否则采样不到纹理。
4. 常见问题排查与性能优化实录
4.1 黑屏问题排查速查表
黑屏是Native层OpenGL最常见的症状，原因可能出在任何一个环节。我整理了一个排查表：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 完全黑屏 | EGL上下文未成功创建 | 检查eglMakeCurrent返回值 |
| 黑屏但有日志 | 着色器编译失败 | 打印glGetShaderInfoLog |
| 纹理不显示 | 纹理未绑定或uniform未设置 | 检查glBindTexture和glUniform1i |
| 画面花屏 | 像素对齐问题 | 强制RGBA格式上传 |
| 图片上下颠倒 | 纹理坐标Y轴方向 | 翻转顶点数据中的纹理坐标 |
| 边缘有黑边 | 纹理环绕模式 | 设为GL_CLAMP_TO_EDGE |
我遇到最多的是着色器编译失败但没打印日志，导致程序静默黑屏。建议在glCompileShader之后一定要检查GL_COMPILE_STATUS，失败就打印info log。
GLint success; glGetShaderiv(shader, GL_COMPILE_STATUS, &success); if (!success) { char infoLog[512]; glGetShaderInfoLog(shader, 512, nullptr, infoLog); LOGE("Shader compile error: %s", infoLog); }4.2 内存泄漏与资源释放
Native层的资源不会自动回收，纹理、缓冲区、着色器程序、EGL上下文都得手动释放。我见过不少项目跑久了OOM，就是因为纹理创建了没删。
释放顺序很重要：先删纹理和缓冲区，再删着色器程序，最后销毁EGL上下文和display。
glDeleteTextures(1, &textureId); glDeleteBuffers(1, &vbo); glDeleteProgram(program); eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT); eglDestroySurface(display, surface); eglDestroyContext(display, context); eglTerminate(display);提示：
eglMakeCurrent解绑当前上下文时，surface和context都传EGL_NO_SURFACE和EGL_NO_CONTEXT，这是标准做法。
4.3 大图纹理的性能优化
如果贴的是4K甚至8K的大图，直接glTexImage2D可能会卡顿甚至失败。几个优化方向：
第一，检查GL_MAX_TEXTURE_SIZE，确保设备支持你的图片尺寸。大部分现代设备支持4096或8192，但低端机可能只有2048。
GLint maxTextureSize; glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxTextureSize);第二，考虑用glTexStorage2D替代glTexImage2D。前者创建不可变纹理，驱动可以提前优化内存布局，性能更好。
glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGBA8, width, height); glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE, data);第三，如果图片不需要全尺寸显示，解码时就缩小。stb_image支持stbi_load_from_memory配合自定义缩放，或者用stbir_resize_uint8做高质量缩放，比上传大图再让GPU缩放更省显存。
4.4 线程与上下文绑定注意事项
OpenGL上下文是绑定到线程的。如果你在A线程创建了上下文，在B线程调用GL函数，必须先在B线程eglMakeCurrent。多线程渲染时，通常的做法是渲染线程独占上下文，其他线程通过消息队列把数据传过来。
我踩过的坑：在渲染线程之外调用glGenTextures，结果纹理ID无效。原因是当前线程没有绑定上下文，所有GL调用都是空操作。解决办法就是在渲染线程里做所有GL相关操作，或者用共享上下文（eglCreateContext时传入共享context）。
5. 从Demo到生产：工程化扩展思路
5.1 封装成可复用的渲染类
Demo跑通之后，下一步是封装。我通常会把EGL管理、着色器编译、纹理加载拆成独立的类。比如EglCore负责上下文生命周期，TextureLoader负责PNG解码和纹理创建，Renderer负责绘制逻辑。这样换图片、换着色器都不用动核心代码。
接口设计上，TextureLoader可以暴露一个loadFromFile(const char* path)返回GLuint纹理ID，内部处理解码、上传、释放像素内存。Renderer的draw()方法只负责绑定纹理和绘制。
5.2 支持多张图片与纹理图集
实际项目里往往不止一张图。如果每张图都单独创建纹理，纹理切换会有开销。优化方案是纹理图集（Texture Atlas），把多张小图打包到一张大图里，渲染时通过调整纹理坐标来采样不同区域。这样一次绑定就能画多个元素，减少glBindTexture调用。
图集的生成可以在构建时用工具完成，也可以在运行时用stb_image加载多张图后手动拼接到一块大内存里，再一次性上传。
5.3 与SurfaceTexture配合实现动态贴图
静态PNG贴图只是起点。更常见的场景是把相机预览或视频帧作为纹理来源，这就需要SurfaceTexture。Native层可以通过ANativeWindow_fromSurface拿到Java层SurfaceTexture对应的原生窗口，然后用eglCreateWindowSurface创建EGLSurface，再通过glEGLImageTargetTexture2DOES把图像绑定到纹理。
这条链路比静态贴图复杂得多，涉及OES扩展和图像同步，但核心思路一致：拿到像素数据，上传纹理，渲染。静态PNG跑通了，动态纹理就是水到渠成的事。
5.4 调试工具与验证手段
Native层调试不如Java层方便，我常用的手段有几个。一是glGetError()，每个关键GL调用后检查一次，能快速定位错误。二是用glReadPixels把渲染结果读回内存，保存成PNG对比，确认渲染是否正确。三是Android Studio的GPU Inspector，可以抓取Native层的GL调用序列，分析性能瓶颈。
glReadPixels的用法：
std::vector<unsigned char> pixels(width * height * 4); glReadPixels(0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE, pixels.data()); // 然后用stbi_write_png保存 stbi_write_png("/sdcard/output.png", width, height, 4, pixels.data(), width * 4);这个手段在排查纹理坐标错误、颜色空间问题时特别有用，肉眼对比原图和渲染结果，一眼就能看出问题。
我个人在实际操作中的体会是，Native层OpenGL ES的门槛主要不在API本身，而在环境搭建和资源管理。EGL的初始化、上下文的线程绑定、资源的释放时机，这些才是最容易翻车的地方。把静态PNG贴图这个最小闭环跑通，后面做视频渲染、滤镜链、离屏渲染，都是在这个基础上叠加。建议一开始就把错误检查和日志打全，别等到黑屏了再回头找问题，那时候排查成本会高很多。
