一、前言
移动端性能优化相关的技术已经发展到了深水区，微信移动端技术团队出品的Matrix APM套件就是对性能优化的一个全集解决方案。高途移动端团队对微信移动端团队一直敬佩有佳，着手落地Matrix APM套件，在众多的套件里，有一个套件叫MemGuard，Matrix的GitHub主页有说明式的介绍，但在落地上的内容却少的可怜，本篇内容正是对MemGuard的重铸改造，并基于此的落地实践。
二、背景
高途移动端最核心的场景是上课，上课主要形式是直播和录播，底层大量使用C/C++，我们在享受高性能的同时，也在承受不稳定的侵袭，而在这不稳定中，内存问题一直是困扰C/C++开发的一大难题，Google一直致力于探索并解决C/C++的内存问题，并在Chromium上了落地了GWP-Asan这个开发套件，目前已经在Chrome上得到了充分的线上验证，微信客户端技术团队基于GWP-Asan推出了MemGuard套件，我们着手落地，但却遇到了不少问题。
三、MemGuard的实现原理
MemGuard是基于GWP-Asan修改的堆内存检测工具，通过阅读源码可以知道，微信的改造力度还是非常彻底的，但原理基本是一致的，下图为MemGuard实现原理图。
MemGuard实现原理
上面三层比较简单，MemGuard的Java API->JNI API->C++ API，提供初始化API和Builder的参数设置以及顺序初始化底层的6个模块，对于这6个模块可以把它分为两层，应用处理层和操作系统处理层。
应用处理层
1.PagePool
PagePool的功能，主要包含两部分
【1】申请一块虚拟地址空间，用来进行后续的内存检查，通过syscall调用mmap来进行内存映射（这是一种kernel层的调用方式，正常我们使用C函数mmap来进行内存映射），mmap的使用有标准的API，这里不赘述，但有几个技术细节需要关注
①通过sysconf(_SC_PAGESIZE)获取以字节为单位的Page的大小
②mmap的flag设置了MAP_PRIVATE和MAP_ANONYMOUS（用户空间内存分配分为两类，一类是file-backed，一类是 anonymous），前者是防止其他进程访问到这块虚拟地址空间，后者因为是anonymous内存空间，所以为了方便调试以及排查问题，使用如下去设置anonymous内存空间的名称。
设置当前进程匿名虚拟内存区域的名字
PagePool申请四类内存地址空间，这个策略与GWP-ASan是一致的，四类内存地址空间包括GUARD_PAGE，ALLOC_PAGE，FREE_SLOT，META_AREA，下图描述了每类内存地址空间的意义。
MemGuard内存检测原理
【2】申请完虚拟地址空间后，要对地址空间做可读可修改的保护，这样后续可操作这块地址空间。
使用syscall的方式设置指定内存空间的读和写保护属性
2.Interception
Interception在MemGuard里的核心功能主要是用xhook拦截libc.so里的free函数，拦截下来后，如果是在MemGuard的监控范围内，则记录在FREE_SLOTS内存地址空间，用于后续检测Use-After-Free的问题。
3.Allocation
Allocation的逻辑相对比较简单，主要用于触发左对齐，右对齐，内存free的逻辑，但核心逻辑还是会调用PagePool的方法。
操作系统处理层
1.Unwind
Matrix内部用于native backtrace的技术，具体原理可以参考文章【5】。
2.SoLoadMonitor
SoLoadMonitor的功能，主要包含两部分
【1】自实现了系统dlopen，dlsym，dlclose等函数的功能，名叫semi_dlfcn，为什么要自实现呢？原因是从Android7以后系统会阻止动态链接非公开的C/C++库，标准的解决方案都是自实现，下面让我们看看各个函数是如何实现的？
semi_dlopen：Android5以上依赖系统dl_iterate_phdr函数来查询应用程序已加载的共享对象，Android5以下通过一行一行读取/proc/thread-self/maps文件来查询应用程序已加载的共享对象，其中会做一些异常校验，比如ELF文件合法性校验，是否是linker加载，文件权限检查等。
semi_dlsym：通过指定的符号名字，从semi_dlopen获取的共享对象列表里查找，如果ELF的类型是FUNC或者OBJECT，并且符号名字相等，则视为找到。
【2】有了以上两个重要函数的实现后，首先通过semi_dlsym查找系统dlopen，android_dlopen_ext和dlclose函数，然后利用xhook去接管系统dlopen，android_dlopen_ext和dlclose函数，进而走到自实现的dlopen，android_dlopen_ext和dlclose函数里，这里需要注意一点，SoLoadMonitor并未适配24和25，下面我们看看dlopen，android_dlopen_ext和dlclose函数系统兼容性的问题。
dlopen：大于等于24，dlopen对应的Linker符号表是__dl___loader_dlopen或__dl__Z8__dlopenPKciPKv，小于24对应的Linker符号表是__dl_dlopen。
android_dlopen_ext：大于等于24，android_dlopen_ext对应的Linker符号表是__dl___loader_android_dlopen_ext或__dl__Z20__android_dlopen_extPKciPK17android_dlextinfoPKv，小于24对应的Linker符号表是__dl_android_dlopen_ext。
dlclose：大于等于24，dlclose对应的Linker符号表是__dl___loader_dlclose或__dl__Z9__dlclosePv，小于24对应的Linker符号表是__dl_dlclose。
注：以上符号可以在/system/bin/linker或/system/bin/linker64可执行程序中查看。
3.SignalHandler
SignalHandler主要功能是通过系统的sigaction函数注册监听SIGSEGV（是POSIX上的标准，代表段错误）信号量，细分code是SEGV_ACCERR（代表访问内存时发生的错误），要在Allocation的内存分配地址内，满足以上条件才会将dump的文件路径回传给应用层。
四、落地实践遇到的问题
虽然我们已经搞清楚了MemGuard的核心原理和代码实现细节，但在落地实践中还是遇到了一些问题。
【1】在阅读源码的时候，发现MemGuard组件和MemHook组件的初始化是互斥的，原因是两者都进行了C/C++函数内存创建和销毁API的hook，两遍初始化会造成性能和稳定性的问题，所以进行了初始化互斥操作。
【2】SEGV_ACCERR发生在堆内存的异常情况，SEGV_MAPERR发生在栈内存的异常情况，SignalHandler模块处理的是SEGV_ACCERR的异常情况，所以栈内存的异常情况MemGuard不会捕捉处理，实际测试已验证。
【3】每次检测到内存问题，MemGuard都会将问题记录在cache目录下memguard目录下的一个文件里，一个内存崩溃会生成一个文件，再次生成文件会覆盖原文件，那如何保证日志都采集上来呢？因为在检测出内存问题的时候处于一个极其不稳定的状态，立即上报存在失败情况，所以高途选择在下一次冷启动的时候进行上报，上报源是bugly，上报的时候带上关键字，在bugly后台可以非常方便的查询。
【4】MemGuard的思想是源于GWP-Asan，而GWP-Asan为了性能，每次发生SEGV_ACCERR内存崩溃，都会采样进行文件的生成，但高途是在Debug环境下使用，故需要添加外部可以100%采样的接口。
【5】MemGuard每次遇到SEGV_ACCERR的异常，App都会直接崩溃，为了提升用户体验，高途进行了规避崩溃操作，目前采用文件保护的方式，但在不同系统上实验发现并不能完全起到作用。
【6】上边我们提到MemGuard的SoLoadMonitor模块存在兼容性问题，故高途只在Android6以上开启MemGuard，保证App整体的稳定性。
【7】MemGuard堆栈解析出来的是符号表的信息，无法分析，故我们在线下使用addr2line命令还原带有符号表的so文件。
【8】因为我们对源码进行了二次订制开发，所以需要对源码进行二次打包发布，通过gradlew assembleRelease和gradlew assembleDebug可打出aar的二进制产物，再将二进制产物发布到高途的Maven上去（包括matrix-hooks组件，matrix-android-lib组件，matrix-android-commons组件，matrix-backtrace组件），最后在App里直接依赖集成。
五、结语
Meta从IDE开发环境阶段，代码审查差异阶段，生产环境发布上线阶段出发，对修复问题的时效性进行了总结，如下图所示
Meta fix fast
高途对MemGuard的重铸改造，主要是在Diff阶段前的实践落地，结果发现了很多潜在的C/C++的内存问题，也算是一个不大不小的里程碑。
六、参考资料
【1】GWP-ASan
网友评论