IOS中内存管理那些事

Objective-C 和 Swift 语言的内存管理方式都是基于引用计数「Reference Counting」的,引用计数是一个简单而有效管理对象生命周期的方式。引用计数分为手动引用计数「ARC: AutomaticReference Counting」和自动引用计数「MRC: Manual Reference Counting」,现在都是用 ARC 了,但是我们还是很有必要了解 MRC。

1. 引用计数的原理是什么?

当我们创建一个新对象时,他的引用计数为1;

当有一个新的指针指向这个对象时,他的引用计数就加1;

当对象关联的某个指针不再指向他时,他的引用计数就减1;

当对象的引用计数为0时,说明此对象不再被任何指针指向,这时我们就可以将对象销毁,回收内存。

由于引用计数简单有效,除了 Objective-C 语言外,Microsoft 的 COM「Component Object Model」、C++11(基于引用计数的智能指针 share_prt)等语言也提供了基于引用计数的内存管理方式。

举个例子:

新建工程,Xcode 默认开启的是 ARC,我们这里针对「AppDelegate.m」文件使用 MRC,进行以下配置:

选择目标工程,然后在「Build Phases」的「Compile Sources」下的「AppDelegate.m」文件配置编译器参数「Compiler Flags」值为「-fno-objc-arc」

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  NSObject *objO = [NSObject new];
  NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 1
  NSObject *objB = [objO retain];
  NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 2
  [objO release];
  NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 1
  [objO release];
  NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 1

  [objO setValue:nil forKey:@"test"]; // 僵尸对象,向野指针发送消息会报错(EXC_BAD_ACCESS)

  return YES;
}

Xcode 默认不会监控僵尸对象,这里我们配置开启他,然后就可以看到具体的跟踪信息了:

也可以通过选择「Product」下的「Profile」来打开「Instruments」工具集。然后选择「Zombies」,再单击右下角的「Choose」按钮进入检测界面,这时点击左上角的「Record」红色圆点按钮开始检测。

1.1 上面例子,为什么最后一次通过 retainCount 获取的值为1,而不是为0呢?

因为该对象的内存已经被回收,我们向一个被回收的对象发送 retainCount 消息,他的输出结果是不确定的,如果该对象所占内存被复用了,那么就可能造成程序异常崩溃。

而且当最后一次执行 release 时,系统已经知道马上要回收内存了,就没必要再将 retainCount 减1,因为不管减不减1,该对象都会被回收,回收后他所在内存区域(包括 retainCount 值)就没有意义了。不将retainCount 减1变为0,可以减少一次内存操作,加快对象的回收。

1.2 什么是僵尸对象、野指针、空指针呢?

僵尸对象:所占用内存已经被回收的对象,僵尸对象不能再使用。

野指针:指向僵尸对象(不可用内存)的指针,给野指针发送消息会报错(EXC_BAD_ACCESS)。

空指针:没有指向任何对象的指针(存储的是 nil、NULL),给空指针发送消息不会报错;空指针的一个经典使用场景就是在开发中获取服务器 API 数据时,转换野指针为空指针,避免发送消息报错。

2. 为什么需要引用计数?

从上面简单例子,我们还看不出引用计数真正的用处,因为该对象的生命周期只是在一个方法内。在真实的应用场景中,我们在方法内使用临时对象,通常不需要修改他的引用计数,只需要在方法返回前销毁对象就可以了。

然而,引用计数真正派上用场的场景是在面向对象的程序设计架构中,用于对象之间传递和共享数据。

举个例子:

假如对象 A 生成了一个对象 O,需要调用对象 B 的某个方法,将对象 O 作为参数传递过去。

在没有引用计数的情况下,一般内存管理的原则是「谁申请谁释放」,那么对象 A 就需要在对象 B 不再需要对象 O 的时候,将对象 O 销毁。但对象 B 可能临时用一下对象 O,也可以觉得他重要,将他设置为自己的一个成员变量,在这种情况下,什么时候销毁对象 O 就成了一个难题了。

对于以上情况有两种做法:

(1)对象 A 在调用完对象 B 的某个方法之后,马上销毁参数对象 O,然后对象 B 需要将对象 O 复制一份,生成另一个对象 O2,同时自己来管理对象 O2 的生命周期。但是这种做法有一个很大的问题,就是他带来更多的内存申请、复制、释放的工作。本来可以复用的对象,因为不方便管理他的生命周期,就简单地把他销毁,又重新构造一份一样的,实在太影响性能。

(2)对象 A 只负责生成对象 O,之后就由对象 B 负责完成对象 O 的销毁工作。如果对象 B 只是临时用一下对象 O,就可以用完后马上销毁,如果对象 B 需要长时间使用对象 O,就不销毁他。这种做法看似解决了对象复制的问题,但是他强烈依赖于 A 和 B 两个对象的配合,代码维护者需要明确地记住这种编程约定。而且,由于对象 O 的生成和释放在不同对象中,使得他的内存管理代码分散在不同对象中,管理起来也很费劲。如果这个时候情况更加复杂一些,例如对象 B 需要再向对象 C 传递参数对象 O,那么这个对象在对象 C 中又不能让对象 C 管理。所以这种方法带来的复杂度更高,更加不可取。

引用计数的出现很好地解决这个问题,在参数对象 O 的传递过程中,哪些对象需要长时间使用他,就把他的引用计数加1,使用完就减1。所有对象遵守这个规则,对象的生命周期管理就可以完全交给引用计数了。我们也可以很方便地享受到共享对象带来的好处。

2.1 什么是循环引用「Reference Cycles」问题,怎么解决呢?

引用计数这种内存管理方式虽然简单,但有一个瑕疵就是他不能自动解决循环引用的问题。

举个例子:

对象 A 和对象 B 相互引用对方作为自己的成员变量,只有当自己销毁时,才将自己的成员变量的引用计数减1,因为对象 A 和对象 B 的销毁相互依赖,这样就造成我们所说的循环引用问题了。

循环引用会导致即使外界已经没有任何指针能够访问他们了,但是他们所占资源仍然无法释放的情况。

解决循环引用问题主要有两种方法:

(1)明确知道哪里存在循环引用,合理时机主动断开环中的一个引用,使得对象得以回收。这种方法不常用,因为他依赖开发人员自己手工显式控制,相当于回到以前「谁申请谁释放」的内存管理年代。

(2)使用弱引用「Weak Reference」,「weak」「__weak」类型,这种方法常用。弱引用虽然持有对象,但是并不增加他的引用计数。弱引用的一个经典使用场景就是委托代理「delegate」协议模式。

2.2 Xcode 中有什么工具可以检测循环引用吗?

在 Xcode 中有「Instruments」工具集可以很方便地检测循环引用。

举个例子:

- (void)viewDidLoad {
  [super viewDidLoad];

  NSMutableArray *mArrFirst = [NSMutableArray array];
  NSMutableArray *mArrSecond = [NSMutableArray array];
  [mArrFirst addObject:mArrSecond];
  [mArrSecond addObject:mArrFirst];
}

可以选择「Product」下的「Profile」来打开「Instruments」工具集。

然后选择「Leaks」,再单击右下角的「Choose」按钮进入检测界面,这时点击左上角的「Record」红色圆点按钮开始检测。

3. Core Foundation 对象的内存管理

ARC 是编译器特性,他不是运行时特性,更不是垃圾回收器「GC」。

ARC 能够解决 iOS 开发中90%的内存管理问题,但是另外10%的内存管理问题是需要开发人员自己处理的,这主要是与底层 Core Foundation 对象交互的部分,底层 Core Foundation 对象由于不在 ARC 的管理下,所以需要自己维护这些对象的引用计数。

实际上 Core Foundation 对象使用的 CFRetain 和 CFRelease 方法,可以认为与 Objective-C 对象的 retain 和 release 方法等价,所以我们可以以 MRC 的方式进行类似管理。

3.1 在 ARC 中,通过什么方式可以把 Core Foundation 对象转换为 Objective-C 对象呢?

转换的过程,其实是告诉编译器,对象的引用计数如何调整。

这里我们可以使用桥接「bridge」相关关键字来进行转换工作,以下是这些(双下划线)关键字的说明:

(1)__bridge:只做类型转换,不修改相关对象的引用计数,原来的 Core Foundation 对象在不用时,需要调用 CFRelease 方法。

(2)__bridge_retained:类型转换后,将相关对象的引用计数加1,原来的 Core Foundation 对象在不用时,需要调用 CFRelease 方法。

(3)__bridge_transfer:类型转换后,将相关对象的引用计数交给 ARC 管理,原来的 Core Foundation 对象在不用时,不需要调用 CFRelease 方法。

我们根据具体的业务逻辑,合理使用上面的三种转换关键字,就可以解决Core Foundation 对象 与 Objective-C 对象相对转换的问题了。

(0)

相关推荐

  • 剖析iOS开发中Cocos2d-x的内存管理相关操作

    一,IOS与图片内存 在IOS上,图片会被自动缩放到2的N次方大小.比如一张1024*1025的图片,占用的内存与一张1024*2048的图片是一致的.图片占用内存大小的计算的公式是:长*宽*4.这样一张512*512 占用的内存就是 512*512*4 = 1M.其他尺寸以此类推.(ps:IOS上支持的最大尺寸为2048*2048). 二,cocos2d-x 的图片缓存 Cocos2d-x 在构造一个精灵的时候会使用spriteWithFile或者spriteWithSpriteFrameNa

  • shell脚本监控linux系统内存使用情况的方法(不使用nagios监控linux)

    一.安装linux下面的一个邮件客户端msmtp软件(类似于一个foxmail的工具) 1.下载安装: 复制代码 代码如下: # tar jxvf msmtp-1.4.16.tar.bz2# cd msmtp-1.4.16# ./configure --prefix=/usr/local/msmtp# make# make install 2.创建msmtp配置文件和日志文件(host为邮件域名,邮件用户名test,密码123456) 复制代码 代码如下: # vim ~/.msmtprcacc

  • iOS内存错误EXC_BAD_ACCESS的解决方法

    iOS开发,最郁闷的莫过于程序毫无征兆地就崩溃了,用bt命令打出调用栈,给出的是一堆系统EXC_BAD_ACCESS的信息,根本没办法定位问题出现在哪里. 首先说一下 EXC_BAD_ACCESS 这个错误,可以这么说,90%的错误来源在于对一个已经释放的对象进行release操作.举一个简单的例子来说明吧,首先看一段Java代码: 复制代码 代码如下: public class Test{ public static void main(String[] args){ String s = "

  • iOS通过逆向理解Block的内存模型

    前言 正常情况下,通过分析界面以及 class-dump 出来头文件就能对某个功能的实现猜个八九不离十.但是 Block 这种特殊的类型在头文件中是看不出它的声明的,一些有 Block 回调的方法名 dump 出来是类似这样的: - (void)FM_GetSubscribeList:(long long)arg1 pageSize:(long long)arg2 callBack:(CDUnknownBlockType)arg3; 因为这种回调看不到它的方法签名,我们无法知道这个 Block

  • IOS 调整内存中的图片大小实例详解

    IOS 调整内存中的图片大小实例详解 在从网路download图片,或者从相册读取图片的时候,如果ImageView的本身就是固定的300*200,那么载入2000*2000的图片是很浪费内存的. 2000*2000的内存占用是2000*2000*4bit 以下两个函数可以用来创建一个新的按照固定大小的图片.简单来说,就是Core Graphics来创建一个bitmap,然后生成一个图片. - (UIImage*)imageWithImage:(UIImage*)image scaledToSi

  • 详解关于iOS内存管理的规则思考

    关于iOS内存管理的规则思考 自己生成的生成的对象,自己持有. 非自己生成的对象,自己也能持有. 不在需要自己持有的对象时释放. 非自己持有的对象无法释放. 注:这里的自己是对象使用的环境,理解为编程人员本身也没有错 对象操作和Objective-C方法对应 对象操作 Objectivew-C方法 生成并持有对象 alloc/copy/mutableCopy/new或以此开头的方法 持有对象 retain 释放对象 release 废弃对象 dealloc 自己生成的对象,自己持有 //自己生成

  • IOS 常见内存泄漏以及解决方案

    IOS 常见内存泄漏以及解决方案 整理了几个内存泄漏的例子,由于转载地址已经找不到了,在这里就不一一列出来了. 1 OC和CF转化出现的内存警告 CFStringRef cfString = CFURLCreateStringByAddingPercentEscapes(kCFAllocatorDefault,(CFStringRef)picDataString,NULL,CFSTR(":/?#[]@!$&'()*+,;="),kCFStringEncodingUTF8); N

  • 解析iOS内存不足时的警告以及处理过程

    内存警告 ios下每个app可用的内存是被限制的,如果一个app使用的内存超过了这个阀值,则系统会向该app发送Memory Warning消息.收到消息后,app必须尽可能多的释放一些不必要的内存,否则OS会关闭app. 几种内存警告级别(便于理解内存警告之后的行为)  Memory warning level: 复制代码 代码如下: typedef enum {                      OSMemoryNotificationLevelAny      = -1,     

  • 详解iOS应用开发中的ARC内存管理方式

    提示:本文中所说的"实例变量"即是"成员变量","局部变量"即是"本地变量" 零.简介 ARC是自iOS 5之后增加的新特性,完全消除了手动管理内存的烦琐,编译器会自动在适当的地方插入适当的retain.release.autorelease语句.你不再需要担心内存管理,因为编译器为你处理了一切 注意:ARC 是编译器特性,而不是 iOS 运行时特性(除了weak指针系统),它也不是类似于其它语言中的垃圾收集器.因此 ARC

  • 详解使用Xcode7的Instruments检测解决iOS内存泄露(最新)

    作为一名iOS开发攻城狮,在苹果没有出ARC(自动内存管理机制)时,我们几乎有一半的开发时间都耗费在这么管理内存上.后来苹果很人性的出了ARC,虽然在很大程度上,帮助我们开发者节省了精力和时间.但是我们在开发过程中,由于种种原因,还是会出现内存泄露的问题.内存泄露是一个很严重的问题.下面就简单介绍下怎么使用Xcode7自带的Instruments中的Leaks检测我们的程序有没有内存泄露和定位内存泄露的代码.(分析内存泄露不能把所有的内存泄露查出来,有的内存泄露是在运行时,用户操作时才产生的)

随机推荐