之前版本正常么？
你大概有多少资源呀？
这个例子是dragonball那边提供的demo吧，这个比较老了，麻烦参考下cocos官方文档中的demo
感觉可能跟内存分配有关，要不尝试下换一种方式写文件试试，先看下是不是这个GetString出的问题
回收只是挂到一个链表里啊，以便下次使用。
删除纹理的操作应该是发现这张纹理的空白范围比较多，且可以合并到另外一张纹理才会去做吧。
这种合并操作应该尽量减少的，因为耗时问题
而且从可用链表里分配出纹理范围时，应该不需要完全匹配rect。。
而是找一个“大于且最接近需要的rect”的纹理范围，
再从可用链表里断开，
再局部更新为新的Label内容，
最后将这个范围的uvs交给对应的Label使用。
现在就是这么做的
那这块的内存占用应该是各平台一致的吧。。。。
为啥原生占用会更多呢？
因为原生的image对象是我们封装的，占用内存很大，再合到大图里面是双倍内存占用。而web上是用的web的HTMLImageElement对象，对应平台有优化的，内存会小很多
吃惊了。
我自己写一个Stringbuffer，然后尝试存文件，居然也失败了，也会崩，可能不是string的事，是不是路径有啥问题，再或者权限？奇了怪了
看权限好像也没问题
更神奇的是 
直接返回就能避免报错。
而如果单单注释 
错误依旧，太神奇了！
Label的话，
不应该是双倍吧。。。
合到大图，拿着的应该是大图的引用？而不是同时拿着一份原数据和一份大图的区域纹理数据？
类比从内存池里分配内存应该是对这个池的一部分内存的引用，而不是自己malloc一份，从mempool也拿一份。。。
其他的图片资源数据就不好说，
因为可能需要持有一份“原始数据”。。。
其实如果这个“原始数据”除了渲染没有其他作用的话，也可以直接丢掉。
可能是权限的问题，看下这个路径有权限么
这里并不会执行到。
注释
std::ofstream outfile;
outfile.open(filepath);
这两句就能避免错误，
注释不注释
outfile << buf.GetString() << std::endl; 并不能避免。
这是什么神奇的问题
gradle 构建的时候有个这个提示
ABIs [x86,armeabi-v7a,armeabi] set by ‘android.injected.build.abi’ gradle flag contained ‘ARMEABI’ not targeted by this project.
和这个有关系吗
label应该还好，我们调整下应该是没问题的
应该是文件打不开
你好，没复现你这个问题哎，能给个demo么
这个已修复，会合到下个版本
能给个demo么，复现不出来