检测和诊断内存问题

检测和诊断内存问题

探究如何了解和诊断 Xcode 的内存性能问题。我们将带您了解 Xcode 工具的最新更新，探索 Metrics，查看 XCTest 中的 memgraph 集合功能，并学习如何使用 Performance XCTest 发现性能退化。

资源
相关视频

WWDC23
- 优化空间计算 App 的功耗和性能
WWDC22
- 分析并优化您的游戏内存
WWDC21
- 应用性能终极生存指南
WWDC19
- Instruments 入门
WWDC18
- 深入了解 iOS 内存
下载

嗨我是坦努加我是一位程序员任职于OS性能团队今天斯特凡和我将会谈及如何侦测并诊断存在于你的应用程序上的内存问题我们首先要来探讨内存占用对一个应用程序所带来的影响
再来我们会讨论到可以用来分析你的内存用量性能的工具以及你可能会遇到的内存问题类型
让我们直接切入主题吧
你可能马上想问的第一个问题是为什么我需要在乎应用程序的内存占用？最关键的原因是它会让你的应用程序用户体验变得更好在系统里有一定的内存量通过监控应用程序内存来避免系统终止运行以回收该内存
这表示你的应用程序可持续在背景保持它的状态这样很棒因为运行内存需要时间而让你的内存占用保持紧凑会增加你的应用程序维持在内存的机会让程序被激活得更快
降低你的内存使用也会引起更活跃反应更为敏捷的体验这就是你的用户在探索新功能时最为需要的
通过策略性安排你的应用程序将如何被写入内存它将免去用户使用程序时等待回收内存的时间成本
策略性安排你的内存使用也会让你能将更广泛的功能加到你的应用程序中像是加载视频包括动画短片以及其他更多
最后我们的设备随着时间不断进化而我们的新设备比以前有更多物理内存通过减少你的内存占用你的程序在旧设备上也会表现得一样好并增加能愉快使用你的程序的人
通过监控你的程序内存占用能让程序更快被激活也更敏捷能处理复杂的功能并在更广泛的设备上有好的表现我们现在来看内存占用的组成
我们将你的内存占用分成三个类别做性能分析脏内存、压缩内存与干净内存我们很快地来看一下它们分别涵盖什么
脏内存包含你的程序写入的内存也包括了所有的堆分配内存像是你使用的malloc函数已解码的图像缓冲以及框架
压缩内存是指任何被内存压缩器进行过压缩的那些近期未被访问过的脏页这些页面会在被访问时被解压缩
要注意在iOS系统里没有swap分区的概念它是专属于macOS系统的
最后我们有干净内存干净内存指的是那些尚未被写入或可被系统清出并重新加载的数据举例来说这些可能是内存映射文件像是存储在磁盘上但已加载到内存的图片或者它们也可能是框架
当我们提到你的程序内存占用我们真的是在讨论程序的脏内存以及压缩内存不算进干净内存
这是对你的内存占用较为高层的理解要有更深入、更细节的说明我们建议你查看2018年WWDC 所发布的iOS内存深入研究我们现在来看一下你可以用来对你的内存做性能分析的一些工具
Xcode提供一套可协助全面监控你的程序内存表现的工具涵盖开发及生产环境工作流程
XCTest测试框架直接在程序项目单元和界面测试中帮助你监控程序内存占用而MetricKit跟Xcode Organizer 能让你在生产环境中监控从你的用户身上获得的内存指标
这个讨论将会延伸到使用ＸTest的成效分析但这些技术仍适用于一般内存分类跟侦测
通过XCTest成效分析你可以估量系统资源像是内存利用、CPU使用量磁盘写入还有其他很多信息让我们一起来看一下一个测试范例吧
如果我是Meal Planner的程序员这个程序帮助你安排一个星期会吃的每一餐然后我想要测量我新加入的存储餐点功能所占用的内存使用量它让用户能下载食谱到他们的设备上
在我的成效分析中我使用measureWithMetrics API 而我特别指出我想要测量目标程序的内存用量在测量指令的程序代码区块里我要启动该程序手动调用测量的API 开始测量然后点击存储餐点的按钮
通过查看界面上的更新我等了快30秒直到食谱下载完成
现在我可以直接在Xcode的界面上跑这个测试来获得我的测量结果
我可以点击测试旁边的灰色钻石图示来查看我的测量结果该结果的弹出框界面有下拉选单让我知道有哪些被测量的指标
底部的条线图则展示了每个迭代的测量结果
五个迭代的整体平均会被算出来并显示在上面
我现在可以决定是否设定这次测试的平均为未来测试的比较底线
未来测试平均如果比设定的底线大就是失败了我们将这个与底线间的偏差称作回归
回归代表我们应该停下来和侦测并修复我们的程序代码让测试能够通过
我们很兴奋能在Xcode 13与大家分享我们加入了一个能够搜集诊断结果的功能来协助将这些回归测试加以分类有两个非常有价值的诊断结果 ktrace档案和memory graphs
Ktrace非常强大并具有多种功能它们可以用于普通的系统侦测或独立追踪特定问题像是在侦测技术问题时深入探讨渲染管线或是查看你的主线程阻塞的原因造成无响应的表现
这些ktrace档案可以用Instruments 在你正常的工作流程内被打开并加以分析
第二个诊断结果对特定内存进行侦测来说特别好 Memory graphs可以跟Xcode visual debugger 以及许多命令行工具一起使用我们稍后会谈到其中一些
Memory graph本质上就是你的进程地址空间的实时映射 Memgraphs记录每个虚拟内存区域的地址跟尺寸大小以及每个malloc分配模块以及那些区域及模块间的重点信息这让你能够进一步查看堆内存上的个别对象一览跟相连框架有关的区域数据以及更多
XCTest会自动化malloc日志堆栈会为刚分配的对象获取backtrace函数
要开始搜集诊断结果使用xcodebuild命令行工具并结合 enablePerformance TestsDiagnostics旗标这个旗标会为了nonmemory指标让ktrace搜集开始运行也为了内存指标驱动memgraphs
一旦我们之前写入的性能测试跑完了之后我们会看到下列信息被打印在管理中心这还挺多的但可以查看其中特别关键的几个东西
第一件事情是要看测试是否通过在这个范例里测试失败了
输出信息内也指出测试失败特别归咎于一个回归我们新的平均值比底线差了12%
最后我们能够找到 xcresult bundle的路径
当我们在Xcode里打开xcresult bundle 我们会在顶端看到内存测量结果就在测试名称的旁边
我们就能展开测试日志并在最底部能够找到我们相连的memgraphs
下载并解压缩后我们会有两个memgraphs 这是因为我们在你的测试上加了一个迭代来运行mallock日志堆栈我们在被测量的迭代开始的时候搜集最初的memgraph 文件名前缀为pre 然后在迭代结束之际我们搜集到第二个memgraph 文件名前缀为post 这让你能够在需要的时候分析内存在单个迭代过程中的成长
有了ktrace档案跟memory graphs 以及malloc日志堆栈的运行你不但能判断回归是否发生也能知道它为何会发生了我现在会交棒给我的同事斯特凡来谈谈你可能在查看搜集到的memgraph诊断所碰到的不同内存问题的种类谢谢坦努加嗨大家好我是斯特凡是一位任职于 OS开发表现团队的程序员我将会谈到一些你可能会在程序里所发现的常见内存问题以及你能如何诊断修复并且避开它们
我会谈到两种内存问题内存泄漏和堆区内存可以进一步被归类为堆分配回归以及碎片化问题这不会是一张令人疲惫的列表但已涵盖了最常见的一些问题我也会谈到一些命令行工作流程可以用来诊断这些问题如果想要深入探讨命令式工具请查看WWDC2018的 iOS内存深入研究谈话
我们先从内存泄漏开始讨论吧
在进程分配一个对象但没有释放它的情况下却失去所用相关引用时就会产生泄漏我在这里有一个范例对象图标灰色箭头标示出对象之间的引用注意每个对象都至少有一个相关引用
也看到对象A到B以虚线表示的引用比方我把这个引用设定为nil 移除它
而那个引用不见了之后对象B就被泄漏了它就完全没有相关引用了它还是脏的但进程没有办法引用它在它exit之前都没有办法释放它因此你应该一直修复泄漏
对象在Swift很常因为循环引用被泄漏在这个图示里对象Ａ和B在一个循环引用中它们互相引用但没有其他外部的引用跟任一相关这表示进程没有办法调用或释放它们所以它们被判定为泄漏
很幸运地大多在Swift的对象是被 Swift的自动引用计数系统也就是ARC所管理的以避免更多的泄漏如果你使用不是被ARC管理的对象像是UnsafePointers 那要确保你在失去所有相关引用前要先释放它们
即使是ARC管理的对象都很容易落入循环引用因此要避免在你的程序代码里创造强循环引用如果循环引用真的很必要那就考虑用一个弱引用吧因为弱引用不会阻挡对象被释放
我们来看Meal Planner程序的例子坦奴加寄给我一些从失败的XCTest里获取的pre跟post memgraphs 我马上想要查看 post memgraph里的泄漏信息
为此我要在memgraph上运行Leaks 这会显示一些有用的信息让我知道任何有发生的泄漏
输出结果显示我有占240泄漏位元的4个泄漏
再来在输出结果内也包含了每个泄漏的对象图内的细节面貌给我一些线索找出可能泄漏的东西
在对象图的顶端标示着ROOT CYCLE 这表示我在处理一个循环引用
这边有一些有用的代号看起来这个循环引用可能包含了 MealPlan跟MenuItem两个对象
因为XCTests有运行malloc日志堆栈输出结果也同样包括每个泄漏分配调用的堆栈这对要找出哪些对象被泄漏是非常有帮助的
常常你会想找出程序码里那段有着代号的调用堆栈这是我的程序码内调用堆栈的部分
泄漏的MealPlan对象被分配在 populateMealData功能里我会打开Xcode 来看我可否修复该问题
这是我在泄漏中看到的 populateMealData功能这里我正在分配一个MealPlan对象跟一个MenuItem对象是我在循环引用里所查看到的两个对象嗯这个addMealToMealPlan功能看起来有点可疑我来看一下
所以看起来我是在Mealplan上调用addItem 但我也在MenuItem上调用addPlan 这是个让我们能够一览餐点上所有项目的功能但也跟规划一份餐点有相关
在MealPlan里 addItem把MenuItem 加入到一个数组里存储相关的引用而在MenuItem中 addPlan则存储了跟mealplan的引用所以这肯定是一个循环引用因为它们同样对彼此拥有强引用
一旦populateMealData exit MealPlan跟MenuItem对象也会不再作用也就不会有相关的外部引用了但它们还是会彼此引用造成泄漏
我应该要来寻找一个不用循环引用的解法但先用快解我会把MenuItem 对它的Mealplan对象换成使用一个弱引用这样就会打破那个循环引用因为我们不再有两个强循环引用
我们现在转换一下去看堆分配回归
堆就是你的进程地址空间区存放动态分配对象的地方堆分配回归就是由于进程分配比以前还多的对象在堆上所造成的内存占用为了减少堆分配回归要移除没有使用的分配并缩小非必要的巨大分配你也应该要注意你同时掌控的内存有多大释放你没有在使用的内存等到你需要的时候再分配内存这就会减少你的程序高峰占用值让它不太会被终止运行
那我们回头来看Mealplanner程序失败的XCTest 并查看是否有堆分配回归为了了解我应该查看哪里我会同时在在pre跟post memgraphs上跑vmmap-summary 来获得一个不错的已使用内存总览
我在pre memgraph上的内存占用大约有112兆字节而在post memgraph 我的内存占用约有125兆字节所以大概有13兆字节的差异
再来在输出结果中也看到我的进程内存使用被分作不同区
由于我怀疑这是个堆分配回归问题我想要开始用MALLOC_ 来查看那些区因为那些区涵盖了我所有在堆区内的对象
记得坦奴加的公式内存占用=脏内存+压缩内存在这个工具里 “交换”代表“压缩” 所以在这些栏位中我只在乎 “脏尺寸”跟“交换尺寸”
而当然输出结果也显示 MALLOC_LARGE区大概有13兆字节的脏内存那跟我的回归尺寸大小差不多所以我当然想要进一步查看它下一步要来找出是哪些种类的对象造成那些13兆字节回归为了获取那样的信息我会在post memgraph上跑heap -diffFrom
我会传pre跟postmemgraphs当作参数这会显示什么对象存在于post memgraph的堆区内但不存在于pre memgraph的堆区里
靠近顶端输出结果显示我大概有 13兆字节大小的新对象在post memgraph上
在下面堆区内存用对象类别来分类针对每个对象类别输出结果都会展示对象数量以及那些对象以兆字节计量的所占大小我马上就发觉我有大约13兆字节左右大小的 non-object类别在Swift语言里这通常代表原生的malloced字节这种对象通常有点难追踪但我可以用某些工具来获取一些信息首先我想要这些non-object的地址
我会跑heap --addresses来找出它们
我会指定我只要尺寸大小至少500千字节的non-objects
啊哈！这个non-object大概有13兆字节所以它会是这次调查的首要可疑之处我会获取这个地址来看我能不能有一些线索来找出它究竟是什么至此我有几个选择根据情境分别有个别的好处所以我会简单地一个个说明
其中一个选择是我可以在这个地址上跑leaks --traceTree
这可以让我看到引用这个地址的树状对象图当我想要获得一个特定对象的更多信息时这就会相当有用或当我的memgraph 没有Malloc日志堆栈或MSL运行时也很有用我们记得XCTest memgraphs 自动允许MSL运行但如果你碰到了一个没有这样做的memgraph 记得用这个工具
我标记出在树状图里看起来有关联的对象我的巨大non-object 可能跟在MKTCustomMeal PlannerCollectionViewCell里这个mealData对象有关我也可以跑leaks --referenceTree
这给我一个从上至下的引用树状图包含我的进程里的所有内存来猜想哪些对象会是根源根据这个输出结果我可以推论出我的程序里内存都集中在哪当我知道我有一个巨大的回归但我不知道是哪些特定的对象所造成的时候这个工具会非常有帮助我可以传-groupByType参数来将同样类别绑在一起缩小输出让它更容易被解析
常常有很大一部分的回归会在这个树状图里一起被绑在一个节点下让找到一些跟这个内存相关的线索更为容易
同样地我也标记出那个显示相关对象的段落这是同样的mealData对象跟我在leaks-traceTree输出结果中看到的一样输出结果显示大约有 13兆字节大小的内存被分配给这个mealData对象我会很想知道这个对象是怎么被分配的因为我的memgraph有MSL运行我可以用malloc_history-fullStacks 找出来
我会传巨大non-object的地址是我之前从heap-addresses中获取的
然后我会针对在那个地址的对象获得分配调用堆栈当我有MSL在运行并且有我在乎的对象地址时这是非常有用的
所以看起来我的mealData对象是被分配到 saveMeal功能里的第三行里列出来了我会换去Xcode看看到底发生什么事这个saveMeal功能在我的自定义表格视图控制器里而这就是罪魁祸首我要重新分配这个原生缓冲区域然后用这个mealData对象将它包起来我重新分配这个缓冲区域是为了复用它并将结果写入磁盘写入磁盘完成后我就不再需要这个缓冲区域了那为什么它还在？
这个嘛 mealData是类别的一员所以只要这个类别单例存在引用也还是会存在这表示当我在任何表格内点击saveMeal 那个表格会被分配并有一个很大的缓冲区域直到表格被移除前都会存在着如果我存储多个餐点那个内存会变得相当大
那我要怎么修复它？有一个选择是在saveMeal功能里定义mealData 但我知道这在某处类别里已被用过所以我不想这么做另外一个方法是在我完成磁盘写入之后将mealData设定为nil 在Swift里的Data对象很聪明能在我没了最后的引用时自动释放缓冲这样在功能跑完后这个缓冲就不会存在了
最后我们来谈谈碎片化
我们很快地来看看页在iOS里是如何运作的一个页是固定大小、独立的内存单元是系统给予你的进程的
也由于页是独立的当你的进程写入任何一部分的页整页就变成脏页也会占到你的进程就算大多都是未使用的也一样
碎片化会在进程有了脏页却没有100%利用它时发生为了了解发生的原因我们看一下一个范例首先我有三张连续的干净页面
当进程开始运行分配会开始填入这些页并弄脏它们
当对象被释放后它们原本的空间会留下空区块在图表里标记为“空闲内存” 但是这些页还是脏的因为它们上面还是有些分配对象
系统会尝试着将未来的分配填入这些空区块我有一个很大的新内存分配像是右边的盒子标示出的一样不幸地这个新的分配对我的空闲内存空间来讲过大了即使总空闲空间的大小是够的它们也没有连续性所以没办法被用于单次的分配
因为它无法被写入任何已存的空闲空间系统会开辟一个新的脏页来放置我的分配就如图表的右边部分所示空闲内存空间仍然未被填满也就被视为碎片化的内存了
减少碎片化的最佳方法是让有相似生命周期的对象在内存里尽可能连续靠近彼此这会帮助确保全部的对象都能同时被释放让进程中比较巨大的连续性内存能够被利用在未来的分配上
在这个例子中我手动分配所有标记为“我的对象”的对象同时间我打算要释放它们但我编码的时候不够小心让系统最后将我的对象与其他对象交错了
现在当我释放全部对象后我有四个空闲内存空间没有任何一个是连续的因为它们都被这些已分配的对象分割了这造成50%碎片化以及四张脏页不太好
那如果我换成写一段编码来将我的对象分配到一起呢？它们现在就会一起在两张页面上而当我释放我的对象进程就会为系统释出两张干净页面最后只会造成两张脏页跟0%碎片化要注意碎片化会加大内存占用从两张到四张脏页我的内存占用就双倍放大为 50%碎片化在大多数的真实情境中有些碎片化是无可避免的所以依据经验法则把目标放在大概25% 或更少的碎片化即可
一种减少碎片化的方法是用自动释放池自动释放池会让系统知道只要对象不再作用就要释放其中所有的对象这会帮助确保所有在自动释放池内的对象有着相似的生命周期
虽然所有的进程都有可能碰到碎片化问题但特别可能发生在长时间运行的进程中有可能是因为很多分配跟释放导致地址空间被分成碎片比方说如果你的程序使用长时间运行的套件记得要查看那些进程中的碎片化状况
我们很快地来看一下我的进程碎片化率我可以跑vmmap -summary 然后下拉到输出结果底部
这个段落会以malloc zone分类每一区都包含了不同种类的分配通常我只会在乎DefaultMallocZone 因为这是默认情况下堆分配最终结束的地方
但是因为这个memgraph有MSL运行我真的在乎的是 MallocStackLoggingLiteZone 只要MSL有在运行这个区就是最终所有堆分配最终结束的地方
% FRAG栏位则告诉我有多少占比的内存因为每个malloc zone的碎片化而被浪费掉有些数字还满大的但我就只专注在 MallocStackLoggingLiteZone
那是因为MallocStackLoggingLiteZone 有着最大比例的脏内存总共五兆字节里占了4.3 所以这次我可以忽略其他区
“脏+交换Frag大小”栏位会告诉我准确来说有多少内存浪费是跟每个malloc区里的碎片化有关
在我的例子里因为碎片化我浪费掉大约800K的空间看起来好像很多但就如同我提过的有些碎片化是无可避免的所以只要我的碎片化小于25% 我就会认定这样的浪费尚可接受
看起来我好像有19％碎片化在MallocStackLoggingLiteZone里还在经验法则的25%之下所以我并不担心
如果我真的有碎片化的内存问题我可以使用Instruments工具里的 Allocations track
我特别想要查看 Allocations表单的总览来看哪些对象在我有兴趣的范围里分别被persist跟destroy
以碎片化的本质来说 destroy对象会释放出空闲内存空间而persist对象被视为仍未被释放的对象即为脏页存在的原因如果你想要深入探讨碎片化两者都值得进一步的调查
要获得更多有关使用Instruments工具的信息查看我们在WWDC 2019的 Instruments入门指南
那现在我已经查看完内存泄漏跟堆内存回归也确认碎片化不是个问题了我会再跑一次XCTest
太棒了！ XCTest现在通过了而回归也被解决了现在你学会了如何侦测并诊断内存问题我们来回顾你可以在程序内使用的作业流程加入新功能的时候写入一个XCTest的性能分析来监控内存或是用任何其他提供的系统指标针对每一次测试设定一个底线然后用测试抓出回归并用搜集的ktrace及memgraph档案进一步调查问题
使用任何失败XCTests的memgraphs 来协助侦测你的内存问题首先你要做的是查看内存泄漏使用Leaks工具和MSL backtrace函数来帮助找到及修复任何内存泄漏如果回归不包含泄漏那就去查看堆区从vmmap -summary开始以确认内存是否在堆里
如果是跑heap -diffFrom来查看哪种对象类别造成内存增加如果原因很明显用heap -addresses来获取它们的地址如果不是利用leaks-referenceTree 来找线索最后调查罪魁祸首的对象地址可以用leaks -traceTree和malloc_history
最后确保你在开发的时候有将这些最佳范例记在心上力求程序内无内存泄漏如果你在处理的是unsafe类别记得要释放每个你分配的东西并注意你的程序代码里是否有循环引用
想办法减少你的堆内存分配无论是缩小它们减少运行它们的时间或是移除不必要的分配也可以都一起用记得要将碎片化放在心上将有相似生命周期的对象分配到一起之后才能创造很好的较大空闲内存空间有了这些最佳范例和XCTest作业流程你就能够侦测、诊断并排除你的应用程序中的内存问题仅代表坦努加和我自己跟观看的各位说声谢谢 [打击乐]

4:52 - Monitor memory performance with XCTests

// Monitor memory performance with XCTests

func testSaveMeal() {
    let app = XCUIApplication()
        
    let options = XCTMeasureOptions()
    options.invocationOptions = [.manuallyStart]
        
    measure(metrics: [XCTMemoryMetric(application: app)],
            options: options) {

        app.launch()

        startMeasuring()

        app.cells.firstMatch.buttons["Save meal"].firstMatch.tap()
            
             let savedButton = app.cells.firstMatch.buttons["Saved"].firstMatch
        XCTAssertTrue(savedButton.waitForExistence(timeout: 30))
    }
}

正在查找特定内容？在上方输入一个主题，就能直接跳转到相应的精彩内容。

提交你查询的内容时出现错误。请检查互联网连接，然后再试一次。

资源

相关视频

WWDC23

WWDC22

WWDC21

WWDC19

WWDC18