思考：
__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 = 0; i < 10000; i++) { Dog * dog = [[Dog alloc]init]; [dog eat]; }
该循环内产生大量的临时对象，直至循环结束才释放，可能导致内存泄露，解决方法方法和自动释放池常见问题类似，在循环中创建自己额autoreleasePool，及时释放占用内存大的临时变量，减少内存占用峰值。
for (int i = 0; i < 10000; i++) { @autoreleasepool { Dog * dog = [[Dog alloc]init]; [dog eat]; } }
当然有时候autoreleasePool也不是万能的
例子：假如有20000张图片，每张1M左右，现在要获取所有图片的尺寸，你会怎么做？
如果这样做
for (int i = 0; i < 2000; i++) { CGSize size = [UIImage imageNamed:[NSString stringWithFormat:@"%d",i]].size; }
用imageNamed方法加载图片占用Cache的内存，autoreleasePool也不能释放，对此问题需要另外的解决办法，最保险的当然是双管齐下了
for (int i = 0; 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等
