iOS开发篇-内存管理（下）

现在iOS开发已经是ARC甚至是swift的时代，但是内存管理仍是一个重点关注的问题，如果只知盲目开发而不知个中原理，踩坑就跳不出来了，理解好内存管理，能让我们写出更有质量的代码。

思考

__strong NSTimer * timer和 NSTimer * __strong timer哪个写法是正确的 为什么编译器不报错

使用__autoreleasing可能会遇到哪些问题

3.4属性的内存管理

ObjC2.0引入了 property 提供成员变量访问方法、权限、环境、内存管理类型的声明 下面主要说明ARC中属性的内存管理.

属性的参数分为三类 基本数据类型默认为 atomic readwrite assign 对象类型默认为(atomic,readwrite,strong),其中第三个参数就是该属性的内存管理方式修饰 修饰词可以是以下之一

assign: 直接赋值

assign 一般用来修饰基本数据类型

property(nonatomic,assign)NSInteger count;

当然也可以修饰ObjC对象 但是不推荐 因为assign被修饰的对象释放后 指针还是释放前的内存 在后续操作中可能会导致内存问题引发崩溃。

retain: release旧值 再retain新值 引用计数 1

retain和strong一样 都用来修饰ObjC对象

使用set方法赋值时 实质上是会先保留新值 再释放旧值 再设置新值 避免新旧值一样时导致对象被释放的问题

MRC写法

-(void)setCount:(NSInteger)count

 [count retain];

 [_count release];

 _count count;

}

ARC对应写法

-(void)setCount:(NSInteger)count

 _count count;

}

copy: release旧值 再copy新值 拷贝内容

一般用来修饰String、Dict、Array等需要保护其封装性的对象 尤其是在其内容可变的情况下 因此会拷贝 深拷贝 一份内容给属性使用 避免可能造成的对源内容进行改动。

使用set方法赋值时 实质上是会先拷贝新值 再释放旧值 再设置新值

实际上 遵守NSCopying的对象都可以使用copy 当然 如果你确定是要共用同一份可变内容 你也可以使用strong或retain

 property (nonatomic, copy) NSString * name;

weak:ARC新引入修饰词 可代替assign 比assign多增加一个特性:置nil。
weak和strong一样用来修饰ObjC对象。

使用set方法赋值时实质上不保留新值 也不释放旧值 只设置新值

比如常用的代理的声明

 property (weak)id myDelegate delegate;

XIb控件额引用

 property (weak, nonatomic) IBOutlet UILabel *nickNameLabel;

strong ARC新引入修饰词 可代替retain

可参照retain 这里不再做描述

思考

各个属性修饰词和3.3中的修饰词的对应关系

属性的本质是什么

3.5 block的内存管理

iOS中使用block必须自己管理内存 错误的内存管理将导致循环引用等内存泄露问题 这里主要说明在ARC下block声明和使用的时候需要注意的两点

如果你使用 property去声明一个block的时候 一般使用copy来进行修饰 当然也可以不写 编译器自动进行copy操作 尽量不要使用retain。

 property (nonatomic, copy) void(^block)(NSData * data);

block会对内部使用的对象进行强引用 因此在使用的时候应该确定不会引起循环引用 当然保险的做法就是添加弱引用标记。

__weak typeof(self)weakSelf self;

深入了解

block的内部实现原理是什么

从内存位置来看block有几种类型 他们的内存管理方式各是怎样的

对于不同类型的外部变量 block的内存管理都是怎样的

4 经典内存泄露及其解决方案

虽然ARC好处多多 然而也无法避免内存泄露问题 下面介绍在ARC中常见的内存泄露。

4.1 僵尸对象和野指针

僵尸对象 内存已经被回收的对象

野指针 指向僵尸对象的指针 向野指针发送消息会导致崩溃

野指针错误形式在Xcode中通常表现为 Thread 1 EXC_BAD_ACCESS 因为你访问了一块已经不属于你的内存

例子代码 没有出现错误的话多运行几遍 因为获取野指针指向的结果是不确定的

Dog * dog [[Dog alloc]init];

NSLog( ---before 

NSLog( ---%s ,object_getClassName(dog));

[dog release];

NSLog( ---after 

NSLog( ---%s ,object_getClassName(dog));

运行结果

2017-03-29 13:35:42.806557 TextARC[3235:116238] ---before

2017-03-29 13:35:42.806763 TextARC[3235:116238] ---Dog

2017-03-29 13:35:42.806827 TextARC[3235:116238] 小狗回到宠物中心

2017-03-29 13:35:42.806845 TextARC[3235:116238] ---after

(11db)

可以看到 当运行到弟六行的时候崩溃了 并给出了EXC_BAD_ACCESS的提示。

解决方案

对象已经被释放后 应将其指针置为空指针 没有指向任何对象的指针 给空指针发送消息不会报错 。

然而在实际开发中实际遇到EXC_BAD_ACCESS错误时 往往很难定位到错误点 幸好Xcode提供方便的工具给我们来定位及分析错误。

1.在produce - scheme - edit scheme - diagnostics中将zombie objects勾选上 下次再出现这样的错误就可以准确定位了。

运行结果

2017-03-29 13:35:42.806557 TextARC[3235:116238] ---before

2017-03-29 13:35:42.806763 TextARC[3235:116238] ---Dog

2017-03-29 13:35:42.806827 TextARC[3235:116238] 小狗回到宠物中心

2017-03-29 13:35:42.806845 TextARC[3235:116238] ---after

2017-03-29 13:35:42.806845 TextARC[3235:116238]_NSZombie_Dog

可以看到 当运行到第六行时并没有崩溃 并给出了NSZOmbie的提示

在Xcode- Open Developer Tool- Instruments打开工具集 选择Zombies工具可以对已安装的应用进行僵尸检测。

4.2 循环引用

循环引用是ARC中最常出现的问题

一般来讲循环引用也是可以使用工具来检测的 分为两种

在peoduct - Analyze中使用静态分析来检测代码中可能存在循环引用的问题。

在Xcode - Open Developer Tool - Instruments打开工具集 选择Leaks工具可以对已安装的应用进行内存泄露检测 此工具能检测静态分析不会提示 但是到运行时才会出现的内存泄露问题。

Leaks工具虽然强大 但是它不能检测到block循环引用导致的内存泄露 这种情况一般需要自行排查问题 傻瓜式的方案当然是重写对象的dealloc方法来监测对象是否正常释放 来确认没有形成循环引用.

4.3 循环中对象占用内存大

这个问题常见于循环次数较大 循环体生成的对象占用内存较大的情景。

代码示例

for (int i i 10000; i ) {

 Dog * dog [[Dog alloc]init];

 [dog eat];

}

该循环内产生大量的临时对象 直至循环结束才释放 可能导致内存泄露 解决方法方法和自动释放池常见问题类似 在循环中创建自己额autoreleasePool 及时释放占用内存大的临时变量 减少内存占用峰值。

for (int i i 10000; i ) {

 autoreleasepool {

 Dog * dog [[Dog alloc]init];

 [dog eat];

 }

当然有时候autoreleasePool也不是万能的

例子 假如有20000张图片 每张1M左右 现在要获取所有图片的尺寸 你会怎么做

如果这样做

for (int i i 2000; i ) {

 CGSize size [UIImage imageNamed:[NSString stringWithFormat: %d ,i]].size;

 }

用imageNamed方法加载图片占用Cache的内存 autoreleasePool也不能释放 对此问题需要另外的解决办法 最保险的当然是双管齐下了

for (int i i 2000; i ) {

 autoreleasepool {

 CGSize size [UIImage imageWithContentsOfFile:filePath].size;

 }

4.4 无限循环

这个是比4.3更极端的情况 无论你出于什么原因 当你启动了一个无限循环的时候 ARC会默认该方法不会执行完毕 方法里面的对象就永不释放 内存无限上涨 导致内存泄露

代码示例

NSLog( start! 

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

 BOOL isSucc YES;

 while (isSucc) {

 [NSThread sleepForTimeInterval:1.0];

 NSLog( create an obj 

});

输出结果为

2017-03-29 15:00:41.371 duiduipeng[4311:156775] start!

2017-03-29 15:00:42.440 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:43.514 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:44.552 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:45.625 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:46.626 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:47.696 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:48.770 duiduipeng[4311:157083] create an obj

2017-03-29 15:00:49.836 duiduipeng[4311:157083] create an obj

可以看到 当控制器释放后该循环还在继续

对于这类问题解决方案是什么呢

提示 解决方法有autoreleasePool、block、timer等

iOS开发篇-内存管理（中） 现在iOS开发已经是ARC甚至是swift的时代，但是内存管理仍是一个重点关注的问题，如果只知盲目开发而不知个中原理，踩坑就跳不出来了，理解好内存管理，能让我们写出更有质量的代码。
iOS开发篇-内存管理（上） 现在iOS开发已经是ARC甚至是swift的时代，但是内存管理仍是一个重点关注的问题，如果只知盲目开发而不知个中原理，踩坑就跳不出来了，理解好内存管理，能让我们写出更有质量的代码。
理解 iOS 和 macOS 的内存管理 本文将会介绍 iOS 和 macOS 应用开发过程中，如何进行内存管理，以及介绍一些内存管理使用的场景，帮助大家理解内存方面的问题