-
pageSize:指的是当前设备物理内存页的大小,当前设备是
iPhoneXs Max
,大小是 16KB,苹果 A7 芯片之前的设备物理内存页大小则是 4KB。 -
states:当前应用的运行状态,对于
Heimdallr-Example
这个应用而言是正在前台运行的状态,这类崩溃我们称之为FOOM
(Foreground Out Of Memory);与此相对应的也有应用程序在后台发生的 OOM 崩溃,这类崩溃我们称之为BOOM
(Background Out Of Memory)。 -
rpages:是
resident pages
的缩写,表明进程当前占用的内存页数量,Heimdallr-Example 这个应用占用的内存页数量是 92800,基于 pageSize 和 rpages 可以计算出应用崩溃时占用的内存大小:16384 * 92800 / 1024 /1024 = 1.4GB。 -
reason:表明进程被终止的的原因,
Heimdallr-Example
这个应用被终止的原因是超过了操作系统允许的单个进程物理内存占用的上限。
Jetsam
机制清理策略可以总结为下面两点:
1. 单个 App 物理内存占用超过上限
2. 整个设备物理内存占用收到压力按照下面优先级完成清理:
-
- 后台应用>前台应用
-
内存占用高的应用>内存占用低的应用
-
用户应用>系统应用
Jetsam
的代码在开源的XNU
代码中可以找到,这里篇幅原因就不具体展开了,具体的源码解析可以参考本文最后第 2 和第 3 篇参考文献。
为什么要监控 OOM 崩溃
前面我们已经了解到,OOM 分为FOOM
和BOOM
两种类型,显然前者因为用户的感知更明显,所以对用户的体验的伤害更大,下文中提到的 OOM 崩溃仅指的是FOOM
。那么针对 OOM 崩溃问题有必要建立线上的监控手段吗?
答案是有而且非常有必要的!原因如下:
-
重度用户也就是使用时间更长的用户更容易发生
FOOM
,对这部分用户体验的伤害导致用户流失的话对业务损失更大。 -
头条,抖音等多个产品线上数据均显示
FOOM
量级比普通崩溃还要多,因为过去缺乏有效的监控和治理手段导致问题被长期忽视。 -
内存占用过高即使没导致
FOOM
也可能会导致其他应用BOOM
的概率变大,一旦用户发现从微信切换到我们 App 使用,再切回微信没有停留在之前微信的聊天页面而是重新启动的话,对用户来说,体验是非常糟糕的。
OOM 线上监控
========
Jetsam 强杀代码截图
翻阅XNU
源码的时候我们可以看到在Jetsam
机制终止进程的时候最终是通过发送SIGKILL
异常信号来完成的。
#define SIGKILL 9 kill (cannot be caught or ignored)
从系统库 signal.h 文件中我们可以找到SIGKILL
这个异常信号的解释,它不可以在当前进程被忽略或者被捕获,我们之前监听异常信号的常规 Crash 捕获方案肯定也就不适用了。那我们应该如何监控 OOM 崩溃呢?
正面监控这条路行不通,2015 年的时候Facebook
提出了另外一种思路,简而言之就是排除法。具体流程可以参考下面这张流程图:
排除法判定OOM崩溃的流程
我们在每次 App 启动的时候判断上一次启动进程终止的原因,那么已知的原因有:
-
App 更新了版本
-
App 发生了崩溃
-
用户手动退出
-
操作系统更新了版本
-
App 切换到后台之后进程终止
如果上一次启动进程终止的原因不是上述任何一个已知原因的话,就判定上次启动发生了一次FOOM
崩溃。
曾经Facebook
旗下的Fabric
也是这样实现的。但是通过我们的测试和验证,上述这种方式至少将以下几种场景误判:
-
WatchDog 崩溃
-
后台启动
-
XCTest/UITest 等自动化测试框架驱动
-
应用 exit 主动退出
在字节跳动 OOM 崩溃监控上线之前,我们已经排除了上面已知的所有误判场景。需要说明的是,因为排除法毕竟没有直接的监控来的那么精准,或多或少总有一些 bad case,但是我们会保证尽量的准确。
自研线上 Memory Graph,OOM 崩溃率下降 50%+
================================
OOM 生产环境归因
目前在 iOS 端排查内存问题的工具主要包括 Xcode 提供的 Memory Graph 和 Instruments 相关的工具集,它们能够提供相对完备的内存信息,但是应用场景仅限于开发环境,无法在生产环境使用。由于内存问题往往发生在一些极端的使用场景,线下开发测试一般无法覆盖对应的问题,Xcode 提供的工具无法分析处理大多数偶现的疑难问题。
对此,各大公司都提出了自己的线上解决方案,并开源了例如MLeaksFinder
、OOMDetector
、FBRetainCycleDetector
等优秀的解决方案。
在字节跳动内部的使用过程中,我们发现现有工具各有侧重,无法完全满足我们的需求。主要的问题集中在以下两点:
-
基于 Objective-C 对象引用关系找循环引用的方案,适用范围比较小,只能处理部分循环引用问题,而内存问题通常是复杂的,类似于内存堆积,Root Leak,C/C++层问题都无法解决。
-
基于分配堆栈信息聚类的方案需要常驻运行,对内存、CPU 等资源存在较大消耗,无法针对有内存问题的用户进行监控,只能广撒网,用户体验影响较大。同时,通过某些比较通用的堆栈分配的内存无法定位出实际的内存使用场景,对于循环引用等常见泄漏也无法分析。
为了解决头条,抖音等各产品日益严峻的内存问题,我们自行研发了一款基于内存快照技术的线上方案,我们称之为——线上 Memory Graph。上线后接入了集团内几乎所有的产品,帮助各产品修复了多年的历史问题,OOM 率降低一个数量级,3 个月之内抖音最新版本 OOM 率下降了 50%,头条下降了 60%。线上突发 OOM 问题定位效率大大提升,彻底告别了线上 OOM 问题归因“两眼一抹黑”的时代。
线上 Memory Graph 核心的原理是扫描进程中所有 Dirty 内存,通过内存节点中保存的其他内存节点的地址值建立起内存节点之间的引用关系的有向图,用于内存问题的分析定位,整个过程不使用任何私有 API。这套方案具备的能力如下:
-
完整还原用户当时的内存状态。
-
量化线上用户的大内存占用和内存泄漏,可以精确的回答 App 内存到底大在哪里这个问题。
-
通过内存节点符号和引用关系图回答内存节点为什么存活这个问题。
-
严格控制性能损耗,只有当内存占用超过异常阈值的时候才会触发分析。没有运行时开销,只有采集时开销,对 99.9%正常使用的用户几乎没有任何影响。
-
支持主要的编程语言,包括 OC,C/C++,Swift,Rust 等。
线上 Memory Graph 采集及上报流程示意图
内存快照采集
线上 Memory Graph 采集内存快照主要是为了获取当前运行状态下所有内存对象以及对象之间的引用关系,用于后续的问题分析。主要需要获取的信息如下:
-
所有内存的节点,以及其符号信息(如
OC/Swift/C++
实例类名,或者是某种有特殊用途的 VM 节点的 tag 等)。 -
节点之间的引用关系,以及符号信息(偏移,或者实例变量名),
OC/Swift
成员变量还需要记录引用类型。
由于采集的过程发生在程序正常运行的过程中,为了保证不会因为采集内存快照导致程序运行异常,整个采集过程需要在一个相对静止的运行环境下完成。因此,整个快照采集的过程大致分为以下几个步骤:
-
挂起所有非采集线程。
-
获取所有的内存节点,内存对象引用关系以及相应的辅助信息。
-
写入文件。
-
恢复线程状态。
下面会分别介绍整个采集过程中一些实现细节上的考量以及收集信息的取舍。
内存节点的获取
程序的内存都是由虚拟内存组成的,每一块单独的虚拟内存被称之为VM Region
,通过 mach 内核的vm_region_recurse/vm_region_recurse64
函数我们可以遍历进程内所有VM Region
,并通过vm_region_submap_info_64
结构体获取以下信息:
-
虚拟地址空间中的地址和大小。
-
Dirty 和 Swapped 内存页数,表示该
VM Region
的真实物理内存使用。 -
是否可交换,Text 段、共享 mmap 等只读或随时可以被交换出去的内存,无需关注。
-
user_tag,用户标签,用于提供该
VM Region
的用途的更准确信息。
大多数 VM Region 作为一个单独的内存节点,仅记录起始地址和 Dirty、Swapped 内存作为大小,以及与其他节点之间的引用关系;而 libmalloc 维护的堆内存所在的 VM Region 则由于往往包含大多数业务逻辑中的 Objective-C 对象、C/C++对象、buffer 等,可以获取更详细的引用信息,因此需要单独处理其内部节点、引用关系。
在 iOS 系统中为了避免所有的内存分配都使用系统调用产生性能问题,相关的库负责一次申请大块内存,再在其之上进行二次分配并进行管理,提供给小块需要动态分配的内存对象使用,称之为堆内存。程序中使用到绝大多数的动态内存都通过堆进行管理,在 iOS 操作系统上,主要的业务逻辑分配的内存都通过libmalloc
进行管理,部分系统库为了性能也会使用自己的单独的堆管理,例如WebKit
内核使用bmalloc
,CFNetwork
也使用自己独立的堆,在这里我们只关注libmalloc
内部的内存管理状态,而不关心其它可能的堆(即这部分特殊内存会以VM Region
的粒度存在,不分析其内部的节点引用关系)。
我们可以通过malloc_get_all_zones
获取libmalloc
内部所有的zone
,并遍历每个zone
中管理的内存节点,获取 libmalloc 管理的存活的所有内存节点的指针和大小。
符号化
获取所有内存节点之后,我们需要为每个节点找到更加详细的类型名称,用于后续的分析。其中,对于 VM Region 内存节点,我们可以通过 user_tag 赋予它有意义的符号信息;而堆内存对象包含 raw buffer,Objective-C/Swift、C++等对象。对于 Objective-C/Swift、C++这部分,我们通过内存中的一些运行时信息,尝试符号化获取更加详细的信息。
Objective/Swift 对象的符号化相对比较简单,很多三方库都有类似实现,Swift
在内存布局上兼容了Objective-C
,也有isa
指针,objc
相关方法可以作用于两种语言的对象上。只要保证 isa 指针合法,对象实例大小满足条件即可认为正确。
C++对象根据是否包含虚表可以分成两类。对于不包含虚表的对象,因为缺乏运行时数据,无法进行处理。
对于对于包含虚表的对象,在调研 mach-o 和 C++的 ABI 文档后,可以通过 std::type_info 和以下几个 p 的信息获取对应的类型信息。
-
type_name string
- 类名对应的常量字符串,存储在__TEXT/__RODATA
段的__const p
中。 -
type_info
- 存放在__DATA/__DATA_CONST
段的__const p
中。 -
vtable
- 存放在__DATA/__DATA_CONST
段的__const p
中。
C++实例以及 vtable 的引用关系示意图
在 iOS 系统内,还有一类特殊的对象,即CoreFoundation
。除了我们熟知的CFString
、CFDictionary
外等,很多很多系统库也使用 CF 对象,比如CGImage
、CVObject
等。从它们的 isa 指针获取的Objective-C
类型被统一成__NSCFType
。由于 CoreFoundation 类型支持实时的注册、注销类型,为了细化这部分的类型,我们通过逆向拿到 CoreFoundation 维护的类型 slot 数组的位置并读取其数据,保证能够安全的获取准确的类型。
CoreFoundation 类型获取
引用关系的构建
整个内存快照的核心在于重新构建内存节点之间的引用关系。在虚拟内存中,如果一个内存节点引用了其它内存节点,则对应的内存地址中会存储指向对方的指针值。基于这个事实我们设计了以下方案:
-
遍历一个内存节点中所有可能存储了指针的范围获取其存储的值 A。
-
搜索所有获得的节点,判断 A 是不是某一个内存节点中任何一个字节的地址,如果是,则认为是一个引用关系。
-
对所有内存节点重复以上操作。
对于一些特定的内存区域,为了获取更详细的信息用于排查问题,我们对栈内存以及 Objective-C/Swift 的堆内存进行了一些额外的处理。
其中,栈内存也以VM Region
的形式存在,栈上保存了临时变量和 TLS 等数据,获取相应的引用信息可以帮助排查诸如 autoreleasepool 造成的内存问题。由于栈并不会使用整个栈内存,为了获取 Stack 的引用关系,我们根据寄存器以及栈内存获取当前的栈可用范围,排除未使用的栈内存造成的无效引用。
栈使用范围
而对于Objective-C/Swift
对象,由于运行时包含额外的信息,我们可以获得Ivar
的强弱引用关系以及Ivar
的名字,带上这些信息有助于我们分析问题。通过获得Ivar
的偏移,如果找到的引用关系的偏移和Ivar
的偏移一致,则认为这个引用关系就是这个Ivar
,可以将Ivar
相关的信息附加上去。
数据上报策略
我们在 App 内存到达设定值后采集 App 当时的内存节点和引用关系,然后上传至远端进行分析,可以精准的反映 App 当时的内存状态,从而定位问题,总的流程如下:
线上 Memory Graph 整体工作流程
整个线上 Memory Graph 模块工作的完整流程如上图所示,主要包括:
-
后台线程定时检测内存占用,超过设定的危险阈值后触发内存分析。
-
内存分析后数据持久化,等待下次上报。
-
原始文件压缩打包。
-
检查后端上报许可,因为单个文件很大,后端可能会做一些限流的策略。
-
上报到后端分析,如果成功后清除文件,失败后会重试,最多三次之后清除,防止占用用户太多的磁盘空间。
后台分析
这是字节监控平台 Memory Graph 单点详情页的一个 case:
线上 Memory Graph 详情页概览
我们可以看到这个用户的内存占用已经将近 900MB,我们分析时候的思路一般是:
-
从对象数量和对象内存占用这两个角度尝试找到类列表中最有嫌疑的那个类。
-
从对象列表中随机选中某个实例,向它的父节点回溯引用关系,找到你认为最有嫌疑的一条引用路径。
-
点击引用路径模块右上角的
Add Tag
来判断当前选中的引用路径在同类对象中出现过多少次。 -
确认有问题的引用路径之后再判断究竟是哪个业务模块发生的问题。
当前引用路径在同类型对象中出现频率统计
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![](https://i-blog.csdnimg.cn/blog_migrate/df8d149cc6f5a650a5564bfda10715a8.jpeg)
尾声
以薪资待遇为基础,以发展为最终目标,要在高薪资的地方,谋求最好的发展!
下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
中…(img-rzteAvn5-1713380843941)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![](https://i-blog.csdnimg.cn/blog_migrate/df8d149cc6f5a650a5564bfda10715a8.jpeg)
尾声
以薪资待遇为基础,以发展为最终目标,要在高薪资的地方,谋求最好的发展!
下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。
[外链图片转存中…(img-PuFeoQoC-1713380843942)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!