一个内存 BUG 的定位与解决

先侃两句

最近在做跨平台，因为我们是SDK，所以不是Flutter那种跨平台，跨的是PC,iOS,MacOS,Android，是用的纯C++，只是在最外层的时候会用一点平台语言或者实在设计到平台特性会使用到，我们的SDK的作用是AI+图像处理。这里推荐一下跨平台纹理库bgfx，但是bgfx也是有很多的不足，所以最好是进行封装，否则会写很多预编译宏来控制平台Texture。最后一个小Tips，bgfx画线很麻烦，且在OpenGL环境不支持线宽大于1.0

BUG定位

其实App的BUG真的都很好解，但是涉及到GPU和CPU的BUG，就不好定位了，我想详细讲一下我定位BUG的过程希望给读者一些灵感，大佬就不用看了。我们有一个逻辑，Texture需要经过AI检测模块A，然后再进行后处理模块B，这次遇到的BUG的是在iOS平台内存持续增长，10S后能把iPhone11 Pro给弄Crash（这个问题一个级别比我高的工程师搞了两天没搞定，我因为依赖他的东西，所以我就来看了）。

熟悉iOS的开发首先想到的就是instrument查leak和Allocation，但是果不其然，一堆地址信息，看不懂（这里想说明第一件事，我在近两年排查过很多BUG，如果是一般业务型App，instrument非常好用，内存，CPU基本都能搞定，但是一旦涉及到GPU的东西或者不是纯OC,Swift的东西，instrument非常不好搞定，而且用instrument查c++泄漏基本等同找死），但是我这里得到一个很关键的信息，我发现Leak给到的泄漏对象最多只有十几K，那么说明系统不认为我内存持续性增长的部分是泄漏问题，这一步耗费我接近两小时。

那么既然系统不认为持续增长部分是内存泄漏问题，说明对象本身应该有合理的引用，因为我们的代码规范规定C++对象必须使用智能指针，所以我想的是看看有没有哪位同事在这个逻辑链里面的代码没有使用智能指针且没有delete掉裸指针，但是没有收获，所有C++对象都是智能指针。而且整个逻辑链都比较长，这样排查其实很费时间，但是我不认为这是效率低，因为我觉得这是必要的步骤。这一步也耗费我接近两小时。

接下来我使用的就是多次帮我解决了大问题的方式（业务型App不推荐使用这个方法，业务型App有其他方法，解决BUG还是要因地制宜），二分插桩法，我固定读取一张图片的Texture并全局保存起来，第一桩我插在检测模块检测前，就是不走检测，将全局纹理作为间谍类返回回去供后处理使用，这一步的作用是看内存泄漏到底是在检测模块还是后处理模块。我发现内存并没有暴涨，然后再把桩打到检测模块检测后，但是还是不返回真实数据，只返回间谍数据，发现内存暴涨，说明内存泄漏一定发生在检测模块A里面。再通过两次打桩排除CPU到GPU拷贝可能引起的一些问题。最后定位到一个.mm文件里面的方法，我确定就是因为调用了这个.mm文件引起了内存泄漏。

BUG解决

项目是C++项目，基本上所有的实现文件都是cpp文件，看到.mm文件我首先会不会是OC对象出问题了，这里说一个前提，我们的原始Texture是OpenGL的，在iOS和MacOS平台上，送到检测模块A的时候需要将OpenGL或OpenGLES的Texture转变为Metal的Texture，检测是在一个子线程的同步队列执行（std::condition_variable好东西啊），熟悉Metal库的人应该知道，Metal的纹理被放在了一个id<MTLTexture>里面。我进入.mm文件的这个方法里面去打桩，就是在生成id<MTLTexture>的前后进行打桩，并且很快定位到就是id<MTLTexture>除了问题。难道是因为这个文件我没有改成ARC？于是马上去查验CMakeList，发现已经改成了ARC，不放心，加宏#if __has_feature(objc_arc)还是暴涨，这里一时没想明白。

ARC对象什么时候释放？没有强引用的时候释放；从运行时角度看呢？在下一次消息循环开始前；释放前会干什么呢？放入autoreleasepool。于是我就在这个方法前后加上了autoreleasepool，问题得以解决，因为线程是C++开的，不会有autoreleasepool，最后留一个小作业：“为什么我们在写纯iOS工程时候，我们不需要手动加上autoreleasepool呢？”

解决BUG一定要因地制宜，要根据不同类型的代码，不同语言的代码找到合适的方法