谈谈iOS内存管理

解析iOS ARC与内存管理

最近读道长新书《iOS面试之道》里边大概提了下什么是ARC?为什么会出现循环引用?读后感觉讲的不够痛快,自己把这块理了下,抽着周末把整理的知识点分享出来。

内存管理是个宽泛的概念,涉及操作系统的内存管理(如果感兴趣可以读《深入理解计算机系统》虚拟内存有详细介绍),运行程序编程语言层面的内存管理,今天我们主要聊狭义的iOS开发中的内存管理。

在计算机科学中自动的存储器管理机制主要有2类:

引用计数算法

最早期的垃圾回收实现方法,通过对数据存储的物理空间附加多一个计数器空间,当有其他数据与其相关时则加一,反之相关解除时减一,定期检查各储存对象的计数器,为零的话则认为已经被抛弃而将其所占物理空间回收。是最简单的实现,但存在无法回收循环引用的存储对象的缺陷。(目前Cocoa采用的机制)

可达性分析算法

近现代的垃圾回收实现方法,通过定期对若干根储存对象开始遍历,对整个程序所拥有的储存空间查找与之相关的存储对象和没相关的存储对象进行标记,然后将没相关的存储对象所占物理空间回收。(Java等语言采用的机制)

引用计数算法可以很快地执行,交织在程序的运行之中。这个特性对于程序不能被长时间打断的实时环境很有利。

但很难处理循环引用,比如图中相互引用的两个对象则无法释放。应用:Python 和 Cocoa 采用引用计数方案。如下图所示 A被B,C引用,那么RetainCount为2,D,E互相循环引用为1,无法打破环造成MEM Leak,F引用RetainCount为0自动释放。

640?wx_fmt=jpeg

可达性分析算法从GC Roots(每种具体实现对GC Roots有不同的定义)作为起点,向下搜索它们引用的对象,可以生成一棵引用树,树的节点视为可达对象,反之视为不可达。如下图所示E,F不可达,G不可达,即使E,F成环也可释放。

640?wx_fmt=jpeg

正是语言底层采用不同的内存回收算法,才导致Objc会有循环引用这种问题,而Java木有,道长的书里92页有这样的表述“ARC与Carbage Collection的区别在于GC在运行时管理内存,可以解决Retain Cycle,而ARC在编译时管理内存”,这个表述并不准确,已于道长确认,确定再版时更为更准确的表述,插句题外话,老峰希望,iOSTips的读者朋友们,不管读书,看博客,在学习研究的过程中辩证的看问题,有自己的独立思考能力。

刚提到了ARC,那么什么是ARC呢?ARC的全称Auto Reference Counting. 也就是自动引用计数。在早期iOS农耕时代是MRC由开发者手动维护引用计数;从iOS5,LLVM 3.0开始增加了编译器的一项特性ARC,从而简化开发者内存管理。画个重点ARC是编译器的特性,是从编译阶段在判定位置中插入代码,帮我们维护引用计数。所以就ARC本身而言,它并不负责管理内存,它只是编译器层面帮我们维护引用计数的一种编译选项。

Talk Is Cheap ,Show Me The Code ,那么直接上OC代码

640?wx_fmt=png

编译后的汇编代码如下图,可以看到在代码退出作用域前有objc_storeStrong(id *object, id value);

640?wx_fmt=png

查看 llvm官方的ARC文档 可知objc_storeStrong函数的实现如下图,分析代码,这里传入的object为&a,而value为null,所以这个函数实际操作为:对null进行了retain,而对a进行了release。即释放了a对象。这里我们可以总结,在__strong类型的变量的作用域结束时,自动添加release函数进行释放。

640?wx_fmt=png

好了,折腾了半天,只为了论证LLVM确实在我们的代码中智能的对失去作用域的对象插入了release代码。

上面提到了引用计数法管理内存为我们iOS猿挖了一个容易写出Retain Cycle的坑,造成内存泄露或一些诡异的bug,那么在语言层面如何规避这种问题,或者如何解开这个环,没错weak关键字,关于weak的实现,有很多写的不错的博客讲,这里不再多讲,有兴趣的读者可以自己研读探究。

实际上社区也有一些检测Memory Leak开源框架,大概原理是通过method swizzled hook 对象生命周期的方法,在对象结束生命周期的时候,在指定时间之后给对象发送某个消息。如果这个时候对象已经被释放,消息不会被执行,如果没有释放说明发生了内存泄漏,消息就会被执行,从而提醒开发人员。通过递归的方式,会记录下某个视图或者controller的树形节点的位置,能更好的帮助定位到具体哪个对象没有被释放。如MLLeaksFinder,FBRetainCycleDetector等。

我们都知道OC对象在RetainCount为0后就会被释放,那么什么时机释放呢,出了作用域,最后一次release后,RetainCount为0就立刻释放?关于这个问题老峰上周在某开发群里抛出来讨论,发现就算一些有经验的开发者也并不一定能给出相对准确的答案,最后为了更深刻的理解这一问题老峰这里留2道题目,有兴趣的读者可以下来自己研究,或者后台留言一起探讨交流。

题目1写出打印log,reference何时会变为nil

640?wx_fmt=png

题目2分析该函数执行后,内存状态,比如内存使用量恒定?线性增加?还是其他?

640?wx_fmt=png

推荐阅读:

  1.   https://clang.llvm.org/docs/AutomaticReferenceCounting.html

  2. 《深入理解计算机系统》

  3.   iOStips,高级进阶电子书干货分享!

PS:公号后台回复关键词【深入理解计算机系统】可获得电子版

640?wx_fmt=png

更多骚操作,尽在iOSTips,关注公众号,第一时间get新姿势,欢迎加入移动开发前线技术交流微信群。

内容概要:本文介绍了一个基于多传感器融合的定位系统设计方案,采用GPS、里程计和电子罗盘作为定位传感器,利用扩展卡尔曼滤波(EKF)算法对多源传感器数据进行融合处理,最终输出目标的滤波后位置信息,并提供了完整的Matlab代码实现。该方法有效提升了定位精度与稳定性,尤其适用于存在单一传感器误差或信号丢失的复杂环境,如自动驾驶、移动采用GPS、里程计和电子罗盘作为定位传感器,EKF作为多传感器的融合算法,最终输出目标的滤波位置(Matlab代码实现)机器人导航等领域。文中详细阐述了各传感器的数据建模方式、状态转移与观测方程构建,以及EKF算法的具体实现步骤,具有较强的工程实践价值。; 适合人群:具备一定Matlab编程基础,熟悉传感器原理和滤波算法的高校研究生、科研人员及从事自动驾驶、机器人导航等相关领域的工程技术人员。; 使用场景及目标:①学习和掌握多传感器融合的基本理论与实现方法;②应用于移动机器人、无人车、无人机等系统的高精度定位与导航开发;③作为EKF算法在实际工程中应用的教学案例或项目参考; 阅读建议:建议读者结合Matlab代码逐行理解算法实现过程,重点关注状态预测与观测更新模块的设计逻辑,可尝试引入真实传感器数据或仿真噪声环境以验证算法鲁棒性,并进一步拓展至UKF、PF等更高级滤波算法的研究与对比。
内容概要:文章围绕智能汽车新一代传感器的发展趋势,重点阐述了BEV(鸟瞰图视角)端到端感知融合架构如何成为智能驾驶感知系统的新范式。传统后融合与前融合方案因信息丢失或算力需求过高难以满足高阶智驾需求,而基于Transformer的BEV融合方案通过统一坐标系下的多源传感器特征融合,在保证感知精度的同时兼顾算力可行性,显著提升复杂场景下的鲁棒性与系统可靠性。此外,文章指出BEV模型落地面临大算力依赖与高数据成本的挑战,提出“数据采集-模型训练-算法迭代-数据反哺”的高效数据闭环体系,通过自动化标注与长尾数据反馈实现算法持续进化,降低对人工标注的依赖,提升数据利用效率。典型企业案例进一步验证了该路径的技术可行性与经济价值。; 适合人群:从事汽车电子、智能驾驶感知算法研发的工程师,以及关注自动驾驶技术趋势的产品经理和技术管理者;具备一定自动驾驶基础知识,希望深入了解BEV架构与数据闭环机制的专业人士。; 使用场景及目标:①理解BEV+Transformer为何成为当前感知融合的主流技术路线;②掌握数据闭环在BEV模型迭代中的关键作用及其工程实现逻辑;③为智能驾驶系统架构设计、传感器选型与算法优化提供决策参考; 阅读建议:本文侧重技术趋势分析与系统级思考,建议结合实际项目背景阅读,重点关注BEV融合逻辑与数据闭环构建方法,并可延伸研究相关企业在舱泊一体等场景的应用实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值