1. 从零理解纯Native层PNG贴图的核心链路Android图形显示系统这个系列一路写下来从SurfaceFlinger到BufferQueue再到硬件合成器基本上把上层框架的脉络摸了一遍。但真正落到GPU渲染这一层很多做应用开发的朋友就卡住了——平时用Glide加载一张PNG往ImageView里一塞就完事了底下到底发生了什么OpenGLES是怎么把一张PNG变成屏幕上像素的中间要过几道手这些问题在应用层是看不到的。这篇要聊的就是把Android的Java层完全剥掉在纯Native环境里用OpenGLES把一张PNG图片贴到屏幕上。先说清楚这个内容适合谁看。如果你已经写过OpenGLES的Hello Triangle知道VBO、Shader、纹理这些基本概念但一直是在Java层用GLSurfaceView做实验想搞清楚Native层到底怎么把EGL、GLES、图片解码这几块拼起来那这篇就是给你准备的。如果你还没接触过OpenGLES建议先把渲染管线的基本流程过一遍再来看不然会有点吃力。核心链路其实就四步解码PNG拿到像素数据、创建EGL上下文和Surface、把像素数据上传成GL纹理、用Shader采样纹理画到Surface上。听起来简单但每一步在Native层都有坑。比如PNG解码后拿到的RGBA数据到底是RGB还是BGRalpha通道预乘没预乘纹理坐标的Y轴方向和图片Y轴方向是反的EGL上下文和线程绑定关系搞错了直接黑屏——这些问题在Java层被封装掉了在Native层全部暴露出来。我这次用的方案是libpng做解码 EGL 3.0 GLES 3.0 一个最小化的Shader程序。为什么选libpng而不是stb_imagestb_image确实更轻一个头文件搞定但libpng对PNG格式的支持更完整尤其是带gamma、带ICC、带多种位深的PNGstb_image在某些边缘case上会翻车。做图形系统底层的东西稳定性比省事重要。EGL用3.0是因为要拿eglCreatePlatformWindowSurface或者eglCreateWindowSurface配合ANativeWindowGLES用3.0是因为要写#version 300 es的Shader语法比2.0干净很多in/out替代attribute/varying少很多心智负担。整个流程跑通之后你会发现Android图形显示系统在Native层的纹理上传路径其实非常直接glTexImage2D把CPU内存里的像素拷到GPU显存glDrawArrays触发绘制EGL的eglSwapBuffers把后台缓冲提交给SurfaceFlinger去合成。中间没有Java层的Bitmap、没有Canvas、没有Skia纯GPU路径。这也是为什么游戏引擎、相机预览、视频渲染这些场景都倾向于走Native GLES延迟低、可控性强。下面我按实际编码顺序把每个环节拆开讲包括参数怎么算、坑在哪里、怎么验证。2. 环境搭建与依赖选型为什么是libpng EGL GLES 3.02.1 解码库的取舍libpng vs stb_image vs 系统Bitmap在Native层解码PNG常见的选择有三个libpng、stb_image、以及通过JNI回调Java层的BitmapFactory。第三个方案直接排除因为我们的目标就是纯Native回调Java就破坏了整个链路的纯粹性而且多一次JNI跨界的开销。剩下libpng和stb_image二选一。stb_image的优势是极简stbi_load一个函数调用就返回像素指针宽高通道数都通过出参给你。但它的PNG解码实现是单文件的简化版对以下情况支持不好16位深PNG、交错PNGAdam7、带tRNS调色板的PNG、以及某些带异常chunk的PNG。我在一个项目里遇到过一张设计稿导出的PNGstb_image解码出来颜色整体偏绿换成libpng就正常后来定位是那张图带了非标准的gAMA chunkstb_image的处理逻辑和libpng不一致。libpng的代价是要写更多的初始化代码要处理png_read_info、png_set_expand、png_read_update_info、png_read_image这一套流程但换来的是对PNG规范的完整支持。而且libpng在Android NDK里是有预编译库的直接链接就行不需要自己交叉编译。注意Android NDK从r21开始libpng和libz都作为NDK的一部分提供在ndk-bundle/toolchains/llvm/prebuilt/.../sysroot/usr/lib下面。CMake里直接find_package(PNG REQUIRED)就能找到不需要自己下载源码编译。如果你用的是更老的NDK版本可能需要手动引入。2.2 EGL版本选择与Surface创建方式EGL的版本选择取决于你的目标API level。EGL 1.4是基础EGL 1.5增加了eglCreatePlatformWindowSurface等扩展。实际开发中如果你要拿到一个能渲染到屏幕的Surface标准做法是从Java层通过SurfaceHolder或SurfaceTexture拿到一个ANativeWindow指针通过JNI传到Native层。用eglCreateWindowSurface(display, config, nativeWindow, attribs)创建EGLSurface。但既然我们追求纯Native更彻底的做法是用ANativeWindow_fromSurface之外的方式——比如直接用ASurfaceControlAPI 29或者通过AHardwareBuffer创建离屏Surface再合成。不过后者复杂度陡增对于演示PNG贴图这个目标来说从Java层传一个Surface到Native层是合理的折中因为Surface本身只是BufferQueue的生产者端不涉及渲染逻辑。EGL配置的选择关键在EGL_RED_SIZE、EGL_GREEN_SIZE、EGL_BLUE_SIZE、EGL_ALPHA_SIZE这四个属性。对于PNG贴图如果你需要alpha混合必须确保config支持alpha通道。我一般用EGL_RED_SIZE8, GREEN8, BLUE8, ALPHA8EGL_DEPTH_SIZE02D贴图不需要深度缓冲EGL_RENDERABLE_TYPEEGL_OPENGL_ES3_BIT。2.3 GLES 3.0的Shader语法优势GLES 2.0的Shader用attribute和varyingGLES 3.0改成in和out顶点着色器的输出变量在片段着色器里用同名的in接收。这个改动看起来小但写复杂Shader的时候心智负担小很多。另外GLES 3.0支持texture()函数替代texture2D()支持整数纹理、纹理数组、实例化渲染等特性。对于PNG贴图这个场景GLES 3.0带来的直接好处是可以用#version 300 es并且可以用layout(location 0) in vec4 aPosition;直接指定顶点属性位置不需要在CPU端调glGetAttribLocation去查。少一次查询少一个出错点。CMake配置大概长这样cmake_minimum_required(VERSION 3.18.1) project(png_texture_demo) find_package(PNG REQUIRED) find_package(EGL REQUIRED) find_package(GLES3 REQUIRED) add_library(png_texture_demo SHARED native_render.cpp png_decoder.cpp egl_core.cpp shader_program.cpp) target_link_libraries(png_texture_demo PNG::PNG EGL::EGL GLES3::GLES3 android log)实操心得find_package(GLES3)在部分NDK版本里可能找不到可以直接用-lGLESv3链接。EGL同理-lEGL。libpng用-lpng -lz。如果链接报undefined reference先检查是不是漏了-lzlibpng依赖zlib。3. PNG解码的完整实现与像素格式陷阱3.1 libpng解码流程逐行拆解libpng的解码流程是固定的模板代码但每一步的参数选择会影响最终拿到的像素格式。我先把完整代码贴出来然后逐段解释。#include png.h #include cstdio #include cstdlib #include cstring struct ImageData { uint8_t* pixels; int width; int height; int channels; }; bool decodePng(const char* filePath, ImageData* outImage) { FILE* fp fopen(filePath, rb); if (!fp) { LOGE(Failed to open PNG file: %s, filePath); return false; } png_structp pngPtr png_create_read_struct( PNG_LIBPNG_VER_STRING, nullptr, nullptr, nullptr); if (!pngPtr) { fclose(fp); return false; } png_infop infoPtr png_create_info_struct(pngPtr); if (!infoPtr) { png_destroy_read_struct(pngPtr, nullptr, nullptr); fclose(fp); return false; } if (setjmp(png_jmpbuf(pngPtr))) { png_destroy_read_struct(pngPtr, infoPtr, nullptr); fclose(fp); return false; } png_init_io(pngPtr, fp); png_read_info(pngPtr, infoPtr); png_uint_32 width png_get_image_width(pngPtr, infoPtr); png_uint_32 height png_get_image_height(pngPtr, infoPtr); png_byte colorType png_get_color_type(pngPtr, infoPtr); png_byte bitDepth png_get_bit_depth(pngPtr, infoPtr); // 统一转换为RGBA8888 if (bitDepth 16) { png_set_strip_16(pngPtr); } if (colorType PNG_COLOR_TYPE_PALETTE) { png_set_palette_to_rgb(pngPtr); } if (colorType PNG_COLOR_TYPE_GRAY bitDepth 8) { png_set_expand_gray_1_2_4_to_8(pngPtr); } if (png_get_valid(pngPtr, infoPtr, PNG_INFO_tRNS)) { png_set_tRNS_to_alpha(pngPtr); } if (colorType PNG_COLOR_TYPE_RGB || colorType PNG_COLOR_TYPE_GRAY || colorType PNG_COLOR_TYPE_PALETTE) { png_set_filler(pngPtr, 0xFF, PNG_FILLER_AFTER); } if (colorType PNG_COLOR_TYPE_GRAY || colorType PNG_COLOR_TYPE_GRAY_ALPHA) { png_set_gray_to_rgb(pngPtr); } png_read_update_info(pngPtr, infoPtr); int rowBytes png_get_rowbytes(pngPtr, infoPtr); int channels png_get_channels(pngPtr, infoPtr); uint8_t* pixels (uint8_t*)malloc(rowBytes * height); png_bytep* rowPointers (png_bytep*)malloc(sizeof(png_bytep) * height); for (int i 0; i height; i) { rowPointers[i] pixels i * rowBytes; } png_read_image(pngPtr, rowPointers); png_read_end(pngPtr, nullptr); free(rowPointers); png_destroy_read_struct(pngPtr, infoPtr, nullptr); fclose(fp); outImage-pixels pixels; outImage-width width; outImage-height height; outImage-channels channels; return true; }这段代码的核心逻辑是不管原始PNG是什么格式统一转成RGBA8888。png_set_strip_16把16位深降到8位png_set_palette_to_rgb把调色板展开成RGBpng_set_tRNS_to_alpha把透明色键转成alpha通道png_set_filler给没有alpha的图补上0xFF的alphapng_set_gray_to_rgb把灰度转成RGB。经过这一套组合拳最终png_get_channels返回的一定是4rowBytes等于width * 4。3.2 像素格式的坑RGB vs BGR、预乘Alpha、行对齐第一个坑是通道顺序。libpng输出的RGBA是标准的R、G、B、A顺序但OpenGLES的glTexImage2D在GL_RGBA格式下期望的也是RGBA顺序所以这里是对齐的。但如果你用GL_BGRA格式某些平台支持就要注意顺序问题。我建议统一用GL_RGBA避免平台差异。第二个坑是预乘Alpha。PNG文件里存储的alpha是直通alphastraight alpha即颜色值没有乘以alpha。但Android的SurfaceFlinger在合成时默认期望的是预乘alphapremultiplied alpha。如果你直接把直通alpha的纹理画到Surface上边缘会出现黑边或者颜色发暗。解决办法有两个一是在Shader里手动做预乘gl_FragColor vec4(color.rgb * color.a, color.a);二是在上传纹理前在CPU端做预乘。我一般选前者因为GPU做乘法比CPU快而且不破坏原始像素数据。第三个坑是行对齐。OpenGL默认假设每行像素按4字节对齐glPixelStorei(GL_UNPACK_ALIGNMENT, 4)是默认值。对于RGBA8888每行本来就是4字节的倍数所以没问题。但如果你解码出来的是RGB8883通道每行字节数可能不是4的倍数这时候要么设glPixelStorei(GL_UNPACK_ALIGNMENT, 1)要么在CPU端补齐。我统一转RGBA就是为了绕开这个问题。注意png_read_end之后一定要调png_destroy_read_struct否则内存泄漏。另外setjmp的错误处理分支里也要记得释放资源libpng的错误处理是longjmp机制不释放会漏。3.3 大图解码的内存优化一张4096x4096的RGBA8888图片内存占用是4096 * 4096 * 4 64MB。如果同时解码多张图很容易OOM。优化手段有几个按需解码如果图片显示尺寸远小于原始尺寸可以在解码时用png_set_scale_16或者自己写降采样逻辑但libpng本身不支持任意比例缩放需要解码后自己resize。使用png_set_keep_unknown_chunks跳过不需要的chunk减少解析开销。解码后立即上传纹理然后释放CPU内存。纹理上传到GPU后CPU端的像素数据就没用了free掉能省不少内存。我在一个图片浏览器项目里做过测试同时解码20张1080P的PNG不释放CPU内存的话峰值到过300MB释放后降到80MB左右。这个差距在低端机上就是闪退和不闪退的区别。4. EGL上下文初始化与Surface绑定4.1 EGL初始化完整流程EGL的初始化是一套固定流程eglGetDisplay→eglInitialize→eglChooseConfig→eglCreateContext→eglCreateWindowSurface→eglMakeCurrent。每一步都有返回值要检查任何一步失败后面都跑不起来。#include EGL/egl.h #include EGL/eglext.h #include GLES3/gl3.h #include android/native_window.h struct EglContext { EGLDisplay display; EGLConfig config; EGLContext context; EGLSurface surface; }; bool initEgl(ANativeWindow* window, EglContext* outEgl) { EGLDisplay display eglGetDisplay(EGL_DEFAULT_DISPLAY); if (display EGL_NO_DISPLAY) { LOGE(eglGetDisplay failed); return false; } EGLint major, minor; if (!eglInitialize(display, major, minor)) { LOGE(eglInitialize failed); return false; } LOGI(EGL version: %d.%d, 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_DEPTH_SIZE, 0, EGL_STENCIL_SIZE, 0, EGL_NONE }; EGLint numConfigs; EGLConfig config; if (!eglChooseConfig(display, configAttribs, config, 1, numConfigs) || numConfigs 0) { LOGE(eglChooseConfig failed); return false; } const EGLint contextAttribs[] { EGL_CONTEXT_CLIENT_VERSION, 3, EGL_NONE }; EGLContext context eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs); if (context EGL_NO_CONTEXT) { LOGE(eglCreateContext failed: 0x%x, eglGetError()); return false; } EGLSurface surface eglCreateWindowSurface(display, config, window, nullptr); if (surface EGL_NO_SURFACE) { LOGE(eglCreateWindowSurface failed: 0x%x, eglGetError()); return false; } if (!eglMakeCurrent(display, surface, surface, context)) { LOGE(eglMakeCurrent failed: 0x%x, eglGetError()); return false; } outEgl-display display; outEgl-config config; outEgl-context context; outEgl-surface surface; return true; }eglChooseConfig的attribs里EGL_SURFACE_TYPE必须是EGL_WINDOW_BIT因为我们是要渲染到窗口。EGL_RENDERABLE_TYPE用EGL_OPENGL_ES3_BIT对应GLES 3.0。EGL_DEPTH_SIZE和EGL_STENCIL_SIZE设0因为2D贴图不需要。4.2 上下文与线程绑定关系EGL的context是绑定到当前线程的eglMakeCurrent之后这个线程才能调GLES函数。如果你在A线程创建context并makeCurrent然后在B线程调glDrawArrays会直接崩或者静默失败。这是Native GLES最常见的坑之一。正确的做法是渲染线程自己创建context自己makeCurrent所有GLES调用都在这个线程里。如果需要在多个线程共享纹理可以用eglCreateContext的share_context参数把主context传进去这样两个context共享纹理和buffer对象。但共享context的同步需要自己用fence或者glFinish来保证。我在一个视频渲染项目里踩过这个坑解码线程解码完帧直接调glTexImage2D上传纹理结果纹理内容随机花屏。原因是解码线程没有makeCurrentGLES调用作用在了错误的context上。后来改成解码线程把像素数据传给渲染线程由渲染线程统一上传问题消失。4.3 Surface尺寸与视口设置eglCreateWindowSurface创建的Surface尺寸由ANativeWindow决定。在eglMakeCurrent之后要调glViewport(0, 0, width, height)设置视口。width和height从ANativeWindow_getWidth和ANativeWindow_getHeight拿。如果Surface尺寸和图片尺寸不一致有两种处理方式一是调整顶点坐标让图片铺满Surface会拉伸变形二是保持图片宽高比在Surface里居中显示留黑边。我一般选后者因为拉伸变形在视觉上不可接受。计算方式float surfaceAspect (float)surfaceWidth / surfaceHeight; float imageAspect (float)imageWidth / imageHeight; float scaleX 1.0f, scaleY 1.0f; if (imageAspect surfaceAspect) { scaleY surfaceAspect / imageAspect; } else { scaleX imageAspect / surfaceAspect; }然后把scaleX和scaleY乘到顶点坐标上就能实现等比缩放居中。5. 纹理上传与Shader绘制的完整实现5.1 纹理创建与参数设置纹理上传的核心是glGenTextures→glBindTexture→glTexParameteri→glTexImage2D。参数设置决定了纹理的采样行为。GLuint createTexture(const ImageData image) { GLuint textureId; glGenTextures(1, textureId); glBindTexture(GL_TEXTURE_2D, textureId); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_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); glPixelStorei(GL_UNPACK_ALIGNMENT, 4); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, image.width, image.height, 0, GL_RGBA, GL_UNSIGNED_BYTE, image.pixels); glBindTexture(GL_TEXTURE_2D, 0); return textureId; }GL_TEXTURE_MIN_FILTER和GL_TEXTURE_MAG_FILTER都设GL_LINEAR因为PNG贴图通常需要平滑缩放。如果设GL_NEAREST放大时会有明显的马赛克。GL_TEXTURE_WRAP_S/T设GL_CLAMP_TO_EDGE防止纹理坐标超出[0,1]范围时出现重复边缘像素。实操心得如果图片尺寸不是2的幂次NPOTGLES 3.0是支持NPOT纹理的但某些老设备对NPOT纹理的mipmap和wrap模式有限制。保险起见GL_CLAMP_TO_EDGEGL_LINEAR不用mipmap的组合在所有设备上都没问题。5.2 Shader编写顶点着色器与片段着色器顶点着色器负责把顶点坐标从模型空间变换到裁剪空间同时传递纹理坐标。片段着色器负责采样纹理并输出颜色。顶点着色器#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; out vec4 fragColor; uniform sampler2D uTexture; void main() { vec4 color texture(uTexture, vTexCoord); fragColor vec4(color.rgb * color.a, color.a); }注意片段着色器里的fragColor vec4(color.rgb * color.a, color.a)这就是前面说的预乘alpha处理。color.rgb * color.a把直通alpha转成预乘alphacolor.a保持不变。顶点数据是一个全屏四边形坐标范围[-1, 1]纹理坐标范围[0, 1]。但要注意纹理坐标的Y轴方向OpenGL的纹理坐标原点在左下角而PNG图片的像素原点在左上角。所以纹理坐标的Y要翻转float vertices[] { // 位置x, y 纹理u, v -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, };如果不翻转图片会上下颠倒。这个坑我第一次写的时候踩过调了半天以为是解码问题后来发现是纹理坐标没翻。5.3 绘制调用与双缓冲交换绘制流程是glClear→glUseProgram→ 绑定VBO和纹理 →glDrawArrays→eglSwapBuffers。void renderFrame(GLuint program, GLuint textureId, GLuint vbo) { 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(glGetUniformLocation(program, uTexture), 0); glBindBuffer(GL_ARRAY_BUFFER, vbo); glEnableVertexAttribArray(0); glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 4 * sizeof(float), (void*)0); glEnableVertexAttribArray(1); glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, 4 * sizeof(float), (void*)(2 * sizeof(float))); glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); eglSwapBuffers(display, surface); }glDrawArrays用GL_TRIANGLE_STRIP画4个顶点形成一个矩形。eglSwapBuffers把后台缓冲提交给SurfaceFlinger触发合成和显示。注意glGetUniformLocation每次绘制都调用会有性能开销建议在初始化时查一次把location缓存起来。glVertexAttribPointer的offset参数是字节偏移不是float偏移所以2 * sizeof(float)不能写成2。6. 常见问题排查与性能优化实录6.1 黑屏问题排查清单黑屏是Native GLES最让人头疼的问题因为没有任何报错。我整理了一个排查清单按优先级排序排查项检查方法常见原因EGL context是否makeCurrent检查eglMakeCurrent返回值在非渲染线程调GLESShader是否编译链接成功检查glGetShaderiv和glGetProgramivGLSL语法错误、版本不匹配纹理是否绑定到正确的unit检查glActiveTexture和glUniform1iunit编号不一致顶点数据是否正确用glGetBufferSubData读回验证VBO没绑定、offset算错纹理坐标是否翻转临时改成纯色输出测试Y轴方向反了Surface尺寸是否为0检查ANativeWindow_getWidthSurface还没就绪我遇到最多的是Shader编译失败但没检查返回值程序继续跑结果画出来全黑。glGetShaderiv(shader, GL_COMPILE_STATUS, status)和glGetProgramiv(program, GL_LINK_STATUS, status)一定要检查失败时用glGetShaderInfoLog和glGetProgramInfoLog打印日志。6.2 纹理上传的性能陷阱glTexImage2D是一个同步调用它会把CPU内存里的像素数据拷贝到GPU显存。对于大图这个拷贝可能耗时几十毫秒阻塞渲染线程。优化手段用PBOPixel Buffer Object异步上传先把像素数据传到PBO再glTexImage2D从PBO读取。这样CPU不用等GPU拷贝完成。用glTexSubImage2D更新纹理如果纹理已经创建只是更新内容glTexSubImage2D比glTexImage2D快因为它不需要重新分配显存。压缩纹理如果图片是ETC2或ASTC格式直接用压缩纹理显存占用和带宽都大幅降低。但PNG需要先转成压缩格式这一步可以在构建时做。我在一个图片轮播项目里测过1080P的RGBA纹理glTexImage2D平均耗时8ms用PBO后降到2ms左右。对于60fps的渲染8ms已经占了半帧时间必须优化。6.3 内存泄漏与资源释放Native层的资源释放比Java层麻烦因为GC不管Native内存。必须手动释放的资源包括malloc出来的像素数据freepng_create_read_struct创建的pngPtrpng_destroy_read_structglGenTextures创建的纹理glDeleteTexturesglGenBuffers创建的VBOglDeleteBuffersglCreateProgram创建的programglDeleteProgrameglCreateContext创建的contexteglDestroyContexteglCreateWindowSurface创建的surfaceeglDestroySurface漏掉任何一个都会导致内存泄漏。我一般写一个cleanup()函数把所有释放逻辑集中在一起在ANativeActivity的onDestroy或者渲染循环退出时调用。实操心得用eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT)解绑当前context然后再销毁context和surface顺序反了会报错。销毁纹理和program之前确保context还是current状态否则glDeleteTextures会失败。6.4 不同设备的兼容性差异Android设备碎片化严重GPU厂商有Adreno、Mali、PowerVR、Tegra等各家对GLES的实现有细微差异。常见兼容性问题Mali GPU对NPOT纹理的mipmap支持不完整如果用了NPOT纹理又设了GL_LINEAR_MIPMAP_LINEAR可能黑屏。解决办法是只用GL_LINEAR或者把NPOT纹理padding到POT。Adreno GPU对precision要求严格片段着色器里必须声明precision mediump float;否则编译失败。PowerVR GPU对gl_FragColor和out变量混用报错GLES 3.0里必须用out声明输出变量不能用gl_FragColor。我在一个跨平台项目里做过统计同样的Shader代码在Adreno上正常在Mali上黑屏原因是Mali对layout(location 0)的支持有bug必须用glBindAttribLocation手动绑定。后来统一改成手动绑定兼容性就好了。7. 从贴图到渲染管线这个Demo还能怎么扩展跑通PNG贴图之后这个Native渲染框架可以往几个方向扩展。一是多纹理混合同时绑定多张PNG在Shader里做混合或者过渡动画这是做UI动效的基础。二是离屏渲染用FBOFrame Buffer Object把渲染结果画到纹理而不是屏幕然后把这个纹理作为输入再做二次处理这是做滤镜和后处理的标准流程。三是接入视频解码把MediaCodec解码出来的帧通过glTexImage2D上传成纹理实现视频渲染这是播放器内核的核心链路。我自己在实际项目里把这个框架扩展成了一个轻量级的2D渲染引擎支持图层、变换、混合模式代码量控制在3000行以内比Skia轻很多适合对包体积敏感的场景。关键是把EGL上下文管理、纹理缓存、Shader程序管理这几块抽象好上层只需要调drawImage(textureId, x, y, width, height)就行。最后分享一个小技巧调试GLES的时候glGetError()要频繁调用但每次调用都有开销。我的做法是写一个宏在Debug构建里每次GLES调用后检查错误Release构建里关掉。这样既不漏错误又不影响性能。#ifdef DEBUG #define GL_CHECK(call) do { \ call; \ GLenum err glGetError(); \ if (err ! GL_NO_ERROR) { \ LOGE(GL error at %s:%d: 0x%x, __FILE__, __LINE__, err); \ } \ } while(0) #else #define GL_CHECK(call) call #endif这个宏帮我定位过无数次问题尤其是那种不报错但画面不对的情况往往是某个GLES调用悄悄失败了。