安卓GLES20应用中以明文存储OpenGL ES着色器代码的风险有哪些？

安卓Raw目录存储GLSL着色器的注意事项与潜在风险 #

• 资源加载稳定性问题
  即使Raw资源内置在APK中，也不能默认加载必然成功。需要注意两类常见错误：

  1. 开启混淆后如果没有正确keep R类的资源ID字段，会导致R.raw.xxx引用失效
  2. 多Flavor构建时如果对应渠道漏放着色器文件，也会触发资源找不到异常
     必须给资源加载逻辑加异常捕获，同时预置最简的默认着色器做降级兜底，避免加载失败直接崩溃。

• IO性能开销风险
  单个着色器文件体积很小，但频繁读写仍然会带来不必要的耗时。禁止每次创建GL程序、切换滤镜时都重读Raw文件，建议首次加载后将着色器字符串缓存到内存中，常用滤镜可以提前预加载，避免切换场景时出现卡顿。

• 构建工具的兼容坑

  1. 开启shrinkResources true资源压缩后，如果是通过动态拼接资源名的方式获取ID，未被静态引用的着色器文件会被构建工具误删，需要在res/raw/keep.xml中主动声明保留对应文件
  2. 使用AndResGuard等资源混淆工具时，要确保着色器文件不会被错误重命名或压缩
  3. 建议给着色器统一设置.frag/.vert后缀，在aapt配置中声明该类后缀不压缩，避免读取出乱码。

• 文本编码与格式风险

  1. 所有着色器文件必须统一使用UTF-8无BOM编码，加载时明确指定UTF-8编码读取，不要用系统默认编码，避免不同地区设备解析出乱码导致编译失败
  2. 读取文件时必须正确保留换行符，不要直接拼接所有行内容——如果着色器内有单行注释//，换行符丢失会导致注释后所有代码被注释，直接编译报错
  3. 尽量不要在着色器内使用中文或特殊字符作为注释，部分老旧设备的GL驱动对非ASCII字符解析存在兼容问题。

• GL编译兼容性问题
  拆分文件后更容易引入不同设备不支持的GLSL扩展语法，需要在glCompileShader编译后主动读取错误日志，把编译失败的原因和对应着色器内容写入埋点或日志，方便排查不同机型的兼容问题，同时要有编译失败的降级逻辑。

• GL上下文丢失后的恢复问题
  安卓GL上下文丢失（比如应用切后台被回收、锁屏后恢复）时需要重新编译着色器，要确保缓存的着色器字符串在进程生命周期内一直可用，不要放在和GL上下文绑定的生命周期内存中，避免恢复时还要重读文件。

内容的提问来源于stack exchange，提问作者GhostCoder77