嗯嗯，getContents这个接口比我说的更通用，只是增加一顶点复杂性，可以接受， 呵呵，我个人比较纠结，对于简易接口，喜欢one input, one output 原则。
这个我想，只能有开发者自己决定了，哪些需要加密，哪些不需要加密，分类的方法应该有很多，例如文件后缀什么的，引擎层面肯定无法控制的。这个表不应该在引擎层，而是由开发者自己管理，是否加密的逻辑也由开发者自行控制， 例如:
这里，hook需要在增加一个文件名参数, 让开发者来决定该文件是否需要解密
嗯，那我就加个接口用于设置这个hook函数吧，类似 FileUtils::setReadCallback(callback);。
已经建立了issue
1赞
@halx99 不知道你是怎么支持ETC1 alpha通道的，从该文章 了解到，要支持alpha通道的话主要有两种：
- 把alpha数据和图片数据打在一个图片文件里
- alpha数据和图片分开位两个图片
对于方法2需要自己写shader，类似这个测试例子：https://github.com/cocos2d/cocos2d-x/blob/v3/tests/cpp-tests/Classes/ShaderTest/ShaderTest.cpp#L665
方法1正如文章所说的，在scale时有性能下降，而且wrap时也只有一个方向是对的。
所以没太明白你说的支持指的是哪种。如果是方法2的话，那么其实是要自己写shader比较好控制。
OK,赞一个
我是用的方法二，直接在引擎层面支持，存储alpha通道的文件名和原文件名一致,仅仅多加一个Alpha后缀字符，引擎以此来判断纹理ETC1是否使用了有Alpha通道
但是这样也有问题：
1、你是在哪个阶段创建alpha后缀的纹理？Sprite初始化还是？那图集呢？
2、引擎应该尽量少对文件名、目录做限制，使用Alpha后缀区分比较过分，如果是完全工具化，那么没问题，工具和引擎配合不需要注意这种规则
在TextureCache 加载贴图时:
这里s_etc1_alpha_endix可以提出一个全局接口cocos2d::setETC1AlphaEndix
可以把我分享的 https://github.com/halx99/cocos2d-x-pc-port down下来， 所以设计etc1 alpha 支持修改的地方，我都加了注释:
目前的问题在于引擎对多纹理的支持不友好，需要自己写shader来达到目的。你的方法相当于在目前的实现上的一个“hack”，引擎里到处需要对ETC进行特殊处理，使得逻辑变得很复杂，所以我觉得维持现状，自己写shader解决吧。
嗯，不过如果引擎能实现，那么开发者应该会更加便利
嗯，如果要实现多纹理工作量不少，而且可能带来兼容性问题。目前兼容性问题被开发者认为是很严重的问题，很多时候也是没办法。
嗯，明白你的顾虑，不过Andorid平台采用ETC1纹理，带来的优势还是很可观的，由于是硬件解码，加载速度其实会快很多，另外最后APK包体是总资源的1/5, 甚至更小. 我们总资源370M， 最后apk 70M
4赞
@minggo 至于多纹理支持工作量大，这个我已经在3.10上实现， 我可以在3.11正式版发布后，提个pull request贡献我的代码, 到时候，多多审核斟酌. 兼容性问题倒是没什么，如果不用ETC1也不影响原有渲染
2赞
好啊，欢迎。
其实我们对硬件纹理支持的那块地方，是应该做成插件形式方便大家扩展。很早以前不是还有网龙自己的一套pnx格式么，类似的这种纹理优化、硬件纹理格式很多公司都有自己一套。
这个赞
自己搞一套pnx，还是软件层面的吧？目前我所知道Android 和 ios平台分别是etc和pvr, directx的dds
各家公司都有各自的解决方案，所以还是在引擎层面做到可扩展会更通用一些。
1赞
各家公司都有各自的解决方案，这里公司指的什么公司，硬件公司还是游戏软件开发公司，
如果说的是硬件生产商，各家硬件厂商对的硬件纹理格式都不一样? 硬件驱动上实现不遵循OpenGL或者DX标准？难道不是主流ios,android阵营？这个实在不理解呢，据我了解，硬件市场不是这样的， 求详解
各家CP，都有自己的纹理压缩解决方案。他们甚至自己会生出一些很奇怪的图片纹理压缩格式。一方面的确是压缩，另一方面也是资源加密，两者可得兼。