[√]Android平台ParticleSystem内存泄露的排查过程

简介: [√]Android平台ParticleSystem内存泄露的排查过程

测试代码/问题表现

local node = cc.ParticleSystemQuad:create(filename)
local size = cc.Director:getInstance():getWinSize()
node:setPosition(cc.p(size.width / 2, size.height / 2))
scene:addChild(node)

每创建一个粒子,就会发生一次泄露,使用leak-tracer检测内存泄露,指向的位置为Image.cpp,起初我以为是误报,后来经过验证,也就是将image的malloc地址缓存起来,image析构的时候再移除,最后观察是否还有image没有移除,确认就是image造成的内存泄露。

问题定位

只有在Android平台,才启用了CC_ENABLE_CACHE_TEXTURE_DATA,看到网上有说这个是为了安卓切换到后台再返回的时候,避免因为重新加载纹理导致的黑屏问题。

c++

复制代码

#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID) || (CC_TARGET_PLATFORM == CC_PLATFORM_WINRT) 
    #define CC_ENABLE_CACHE_TEXTURE_DATA       1
#else
    #define CC_ENABLE_CACHE_TEXTURE_DATA       0
#endif

在CCParticleSystem中,解析plist并加载设置纹理

 if( dictionary.find("textureImageData") != dictionary.end() ){
     // ...
     // For android, we should retain it in VolatileTexture::addImage which invoked in Director::getInstance()->getTextureCache()->addUIImage()
    image = new (std::nothrow) Image(); //image.ref=1  就是这个new导致的泄露
    bool isOK = image->initWithImageData(deflated, deflatedLen);
    CCASSERT(isOK, "CCParticleSystem: error init image with Data");
    CC_BREAK_IF(!isOK);
    // texture.ref=1,CC_ENABLE_CACHE_TEXTURE_DATA的原因,image.ref=2
    auto texture = Director::getInstance()->getTextureCache()->addImage(image, _plistFile + textureName);
    setTexture(texture);// texture.ref=2
    image->release();// image.ref=2 无法释放
}

注释中也说明了,在Android平台,Image会额外的retain一次,所以这个的image->release()是无法释放的,乍一看应该是这个image的问题,其实不然,解析往后看。

image->release()无法释放的原因,CCTextureCache.cpp中相关代码:

Texture2D* TextureCache::addImage(Image* image, const std::string& key){
    // ...
    #if CC_ENABLE_CACHE_TEXTURE_DATA
        VolatileTextureMgr::addImage(texture, image); // 重点逻辑
    #endif
}
std::list<VolatileTexture*> VolatileTextureMgr::_textures;
void VolatileTextureMgr::addImage(Texture2D* tt, Image* image)
{
    if (tt == nullptr || image == nullptr)
        return;
    // 相当于Texture2D和VolatileTexture是一一映射的关系
    VolatileTexture* vt = findVolotileTexture(tt);
    image->retain(); // retain
    // 同一个plist,第二次创建时texture都是同一个,因为都是从TextureCache中获取的,所以上边的vt也是同一个
    // 但是image发生了变化,直接赋值就让之前的image变成了野指针
    // CC_SAFE_RELEASE_NULL(vt->_uiImage); // 修复内存泄露的代码
    vt->_uiImage = image;
    vt->_cashedImageType = VolatileTexture::kImage;
}
VolatileTexture* VolatileTextureMgr::findVolotileTexture(Texture2D* tt)
{
    VolatileTexture* vt = nullptr;
    for (const auto& texture : _textures)
    {
        VolatileTexture* v = texture;
        if (v->_texture == tt)
        {
            vt = v;
            break;
        }
    }
    if (!vt)
    {
        vt = new (std::nothrow) VolatileTexture(tt);
        _textures.push_back(vt);
    }
    return vt;
}
VolatileTexture::VolatileTexture(Texture2D* t)
    : _texture(t) // 对应的纹理
{
}

粒子销毁时,析构函数的逻辑,因为粒子对应的texture在TextureCache中有一份,所以粒子的texture在游戏过程中永远也无法释放,除非手动清理TextureCache,

ParticleSystem::~ParticleSystem()
{
    _particleData.release();
    CC_SAFE_RELEASE(_texture);// texture.ref=2,texture无法释放
}
Texture2D::~Texture2D()
{
#if CC_ENABLE_CACHE_TEXTURE_DATA
    VolatileTextureMgr::removeTexture(this);// 导致vt绑定的_uiImage也无法释放
#endif
}
void VolatileTextureMgr::removeTexture(Texture2D* t)
{
    for (auto& item : _textures)
    {
        VolatileTexture* vt = item;
        if (vt->_texture == t)// 对应的纹理
        {
            _textures.remove(vt);
            delete vt;
            break;
        }
    }
}
VolatileTexture::~VolatileTexture()
{
    CC_SAFE_RELEASE(_uiImage);
}

整理下思路: TextureCache::addImage的逻辑中存在一条映射链

image / particle.texture / VolatileTexture._texture / VolatileTexture._uiImage

按照这个逻辑推理,如果image想要释放那么只需要particle.texture释放即可,很明显particle.texture释放不了,原因我上边的注释也写了,因为TextureCache的原因,注释我已经写的很清楚了,可以回过头再仔细理解下。

所以,问题就变成了我们不能指望着particle.texture释放,它也释放不了,所以保存image指针前,就需要看texture绑定的是否有_uiImage,有的话,就把之前的释放掉,这样简单粗暴的就修复了内存泄露的问题。

扩展

重复创建同一个粒子,你会发现其实这个image的内容没有发生变化,还有一种修复办法就是CC_ENABLE_CACHE_TEXTURE_DATA模式下把image缓存起来,粒子纹理从image cache中取,还能提升一定的性能,可扩展的修复结果:

void VolatileTextureMgr::addImage(Texture2D* tt, Image* image)
{
    if (tt == nullptr || image == nullptr)
        return;
    VolatileTexture* vt = findVolotileTexture(tt);
    image->retain();
    // release previous image, otherwise case memory leak
    if (vt->_uiImage != image){ //万一image是从cache里面取的呢?
        CC_SAFE_RELEASE_NULL(vt->_uiImage);
    }
    vt->_uiImage = image;
    vt->_cashedImageType = VolatileTexture::kImage;
}

Sprite为啥没有这个问题呢?

Texture2D* addImage(Image *image, const std::string &key);// 有vt
Texture2D* addImage(const std::string &filepath, bool bSpriteFrame);// sprite调用的是这个,没有vt
目录
相关文章
|
2月前
|
监控 Android开发 数据安全/隐私保护
批量发送短信的平台,安卓群发短信工具插件脚本,批量群发短信软件【autojs版】
这个Auto.js脚本实现了完整的批量短信发送功能,包含联系人管理、短信内容编辑、发送状态监控等功能
|
4月前
|
缓存 编解码 Android开发
Android内存优化之图片优化
本文主要探讨Android开发中的图片优化问题,包括图片优化的重要性、OOM错误的成因及解决方法、Android支持的图片格式及其特点。同时介绍了图片储存优化的三种方式:尺寸优化、质量压缩和内存重用,并详细讲解了相关的实现方法与属性。此外,还分析了图片加载优化策略,如异步加载、缓存机制、懒加载等,并结合多级缓存流程提升性能。最后对比了几大主流图片加载框架(Universal ImageLoader、Picasso、Glide、Fresco)的特点与适用场景,重点推荐Fresco在处理大图、动图时的优异表现。这些内容为开发者提供了全面的图片优化解决方案。
164 1
|
6月前
|
存储 编解码 监控
Android平台GB28181执法记录仪技术方案与实现
本文介绍了大牛直播SDK的SmartGBD在执法记录仪场景中的应用。GB28181协议作为视频监控联网的国家标准,为设备互联互通提供规范。SmartGBD专为Android平台设计,支持音视频采集、编码与传输,具备自适应算法和多功能扩展优势。文章分析了执法记录仪的需求,如实时音视频传输、设备管理及数据安全,并详细阐述了基于SmartGBD的技术实现方案,包括环境准备、SDK集成、设备注册、音视频处理及功能扩展等步骤。最后展望了SmartGBD在未来智慧物联领域的广阔应用前景。
241 13
|
6月前
|
存储 编解码 开发工具
Android平台毫秒级低延迟HTTP-FLV直播播放器技术探究与实现
本文详细探讨了在Android平台上实现HTTP-FLV播放器的过程。首先介绍了FLV格式的基础,包括文件头和标签结构。接着分析了HTTP-FLV传输原理,通过分块传输实现流畅播放。然后重点讲解了播放器的实现步骤,涵盖网络请求、数据解析、音视频解码与渲染,以及播放控制功能的设计。文章还讨论了性能优化和网络异常处理的方法,并总结了HTTP-FLV播放器的技术价值,尤其是在特定场景下的应用意义。
253 11
|
6月前
|
监控 Shell Linux
Android调试终极指南:ADB安装+多设备连接+ANR日志抓取全流程解析,覆盖环境变量配置/多设备调试/ANR日志分析全流程,附Win/Mac/Linux三平台解决方案
ADB(Android Debug Bridge)是安卓开发中的重要工具,用于连接电脑与安卓设备,实现文件传输、应用管理、日志抓取等功能。本文介绍了 ADB 的基本概念、安装配置及常用命令。包括:1) 基本命令如 `adb version` 和 `adb devices`;2) 权限操作如 `adb root` 和 `adb shell`;3) APK 操作如安装、卸载应用;4) 文件传输如 `adb push` 和 `adb pull`;5) 日志记录如 `adb logcat`;6) 系统信息获取如屏幕截图和录屏。通过这些功能,用户可高效调试和管理安卓设备。
|
9月前
|
IDE 开发工具 Android开发
移动应用开发之旅:探索Android和iOS平台
在这篇文章中,我们将深入探讨移动应用开发的两个主要平台——Android和iOS。我们将了解它们的操作系统、开发环境和工具,并通过代码示例展示如何在这两个平台上创建一个简单的“Hello World”应用。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和技巧,帮助你更好地理解和掌握移动应用开发。
233 17
|
10月前
|
监控 Java Android开发
深入探讨Android系统的内存管理机制
本文将深入分析Android系统的内存管理机制,包括其内存分配、回收策略以及常见的内存泄漏问题。通过对这些方面的详细讨论,读者可以更好地理解Android系统如何高效地管理内存资源,从而提高应用程序的性能和稳定性。
371 16
|
9月前
|
监控 Java Android开发
深入探索Android系统的内存管理机制
本文旨在全面解析Android系统的内存管理机制,包括其工作原理、常见问题及其解决方案。通过对Android内存模型的深入分析,本文将帮助开发者更好地理解内存分配、回收以及优化策略,从而提高应用性能和用户体验。
|
10月前
|
Android开发 开发者
Android性能优化——内存管理的艺术
Android性能优化——内存管理的艺术
|
11月前
|
Linux API 开发工具
FFmpeg开发笔记(五十九)Linux编译ijkplayer的Android平台so库
ijkplayer是由B站研发的移动端播放器,基于FFmpeg 3.4,支持Android和iOS。其源码托管于GitHub,截至2024年9月15日,获得了3.24万星标和0.81万分支,尽管已停止更新6年。本文档介绍了如何在Linux环境下编译ijkplayer的so库,以便在较新的开发环境中使用。首先需安装编译工具并调整/tmp分区大小,接着下载并安装Android SDK和NDK,最后下载ijkplayer源码并编译。详细步骤包括环境准备、工具安装及库编译等。更多FFmpeg开发知识可参考相关书籍。
362 0
FFmpeg开发笔记(五十九)Linux编译ijkplayer的Android平台so库

热门文章

最新文章