很多的开发人员会将注意力放在业务模块，以至于疏忽了内存部分的优化，刚开始看不出什么问题，当上线之后或者项目慢慢庞大的时候，会出现各种各样的问题，因为内存问题相对于一般的问题来说，比较难以定位和查找，所以需要我们时时注意，在每一个小功能点做好内存控制。
我总结了一些在项目开发过程中，所做的一些优化以及需要注意的点。
4.第三方工具
微信读书团队开源的一个检测UI方面泄漏的工具，更加贴合项目需要，可以解决很大部分的问题。集成简单，在新功能开发时可以很好的检测bug及时解决。
Facebook 在前阵子开源了一个循环引用检测工具 FBRetainCycleDetector。当传入内存中的任意一个 OC 对象，FBRetainCycleDetector 会递归遍历该对象的所有强引用的对象，以检测以该对象为根结点的强引用树有没有循环引用。
FBRetainCycleDetector 的使用存在两个问题：
- 需要找到候选的检测对象
- 检测循环引用比较耗时
正是由于这两个问题，FBRetainCycleDetector 通常是结合其它工具一起使用，通过其它工具先找出候选的检测对象，然后进行有选择的检测。当 MLeaksFinder 与 FBRetainCycleDetector 结合使用时，能达到很好的效果。先通过 MLeaksFinder 找到内存泄漏的对象，然后再过 FBRetainCycleDetector 检测该对象有没有循环引用即可。
相关文档
1.1 NSTimer循环引用
基于平时使用NSTimer，我们分析一下NSTimer的强引用。
// 标记1 NSTimer *timer = [[NSTimer alloc] initWithFireDate:[NSDate date] interval:1 target:self selector:@selector(timerFire) userInfo:nil repeats:YES]; // 标记2 [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode]; // 标记3 self.timer = timer;
第一步：新建timer，timer对self进行强引用。
第二步：NSRunLoop对timer进行强引用。
第三步：self对timer进行强引用。
当停止计时时，必须要调用invalidate方法，这是唯一将timer从runloop中移除的方法，同时他会释放timer强引用的对象，也就是将第二步和第三步的的强引用去除，需要注意的是一定要在同一个线程调用invalidate方法，在另一个线程调用将会失效。
1.2 block的循环引用
在使用 block 的时候，为了避免产生循环引用，通常需要使用 weakSelf 与 strongSelf，写下面这样的代码：
__weak typeof(self) weakSelf = self; [self doSomeBlockJob:^{ }];
不过需要注意的是当 block 本身不被 self 持有，而被别的对象持有，同时不产生循环引用的时候，就不需要使用 weak self 了。最常见的代码就是 UIView 的动画代码，我们在使用 UIView 的 animateWithDuration:animations 方法做动画的时候，并不需要使用 weak self，因为引用持有关系是：
- UIView 的某个负责动画的对象持有了 block
- block 持有了 self
还有一种情况是为了避免在block的执行过程中，self被突然释放，我们需要在内部写一个strongself，保证在block执行完之后self才会得到释放。
2、imageWithContentsOfFile
- Resource图片加载方式
resource图片加载方式是指使用
imageWithContentsOfFile:创建图片的图片管理方式.导入方式
直接将图片拖入目录中。
使用方式
NSString *path = [NSBundle.mainBundle pathForResource:@"image@2x" type:@"png"]; UIImage *image = [UIImage imageWithContentsOfFile:path];
原理
就是通过文件路径将图片转化成data数据，将data数据再通过图片加载出来显示。
在 Resource 的图片管理方式中, 所有的图片创建都是通过读取文件数据得到的, 读取一次文件数据就会产生一次NSData以及产生一个UIImage, 当图片创建好后销毁对应的NSData, 当UIImage的引用计数器变为0的时候自动销毁UIImage. 这样的话就可以保证图片不会长期地存在在内存中.
一般Resource图片都是数据较大的图片，并且不需要使用多次的图片，例如引导页，启动页面等。
- ImageAssets 图片加载方式
ImageAssets图片加载方式是为了适配不同比例的屏幕，在工程中导入两张或者三张不同像素的图片，在使用的时候会根据不同的屏幕来获取不同大小的图片。
导入方式
放进ImageAssets文件夹
使用方式
UIImage *image = [UIImage imageNamed:@"image"];
原理
也是将图片数据转化成UIImage，只不过这些图片数据都打包在 ImageAssets 中。还有一个最大的区别就是图片缓存。相当于有一个字典, key 是图片名, value是图片对象。调用imageNamed:方法时候先从这个字典里取, 如果取到就直接返回, 如果取不到再去文件中创建, 然后保存到这个字典后再返回。由于字典的key和value都是强引用, 所以一旦创建后的图片永不销毁。
一般ImageAssets图片都是icon类型的图片，大小在3-20kb。
- 解决方案
项目的启动动画使用的是多张连续的图片组合成Gif动画，使用的是定时器定时切换图片播放，完成之后从界面上移除。
但是在使用时用的是imageNamed的加载方式，改成imageWithContentsOfFile，在动画播放完成之后将imageView.image置为nil，再次运行之后内存降了8M左右。
3、SDWebImage内存暴涨
在进入app之后，加载图片内容列表，使用instruments检测时发现内存暴涨。
在SDWebImage的issue中找到了解决方案。Memory problem or leak on iOS 7 ? · Issue #538 · rs/SDWebImage · GitHub
- 原因
在源文件的描述中发现SDImageCache维护一个内存缓存和一个可选的磁盘缓存。磁盘缓存异步执行写操作所以不会对UI增加不必要的延迟。属性shouldCacheImagesInMemory默认为YES，shouldDecompressImages默认也为YES。而shouldDecompressImages属性会对下载和缓存的图片进行解压缩来提高性能，但是会消耗很多内存，并且默认为开启，问题就出在这里，当我们大量在线加载图片的时候会使内存过度消耗。
- 解决方案
- 将shouldDecompressImages参数设置为NO。
[SDImageCache sharedImageCache].shouldDecompressImages = NO; [SDWebImageDownloader sharedDownloader].shouldDecompressImages = NO;
- 在ViewController的viewDidDisappear方法中clearMemory，如果使用BaseViewController，可以在加到基类的viewDidDisappear方法中。
[[SDImageCache sharedImageCache] clearMemory];
- 在MemoryWarning的时候clearMemroy，可以加到AppDelegate中。
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application { [[SDImageCache sharedImageCache] clearMemory]; }
3、使用正确的API
- 选择合适的容器,能够使用UITableView重用cell的地方就尽量使用UITableView；
- 选择正确的存储方式，在使用缓存时会有性能消耗的问题，而且要注意线程安全问题，一个原则就是缓存所需要的，不大可能改变但是经常需要读取的东西。
- 正确的选择imageNamed：和imageWithContentsOfFile：方法
- 在真正需要打印的地方才使用NSLog()
- 当试图获取磁盘中一个文件的属性信息时，使用 [NSFileManager attributesOfItemAtPath:error:] 会浪费大量时间读取可能根本不需要的附加属性。这时可以使用 stat 代替 NSFileManager，直接获取文件属性：
#import <sys/stat.h> struct stat statbuf; const char *cpath = [filePath fileSystemRepresentation]; if (cpath && stat(cpath, &statbuf) == 0) { NSNumber *fileSize = [NSNumber numberWithUnsignedLongLong:statbuf.st_size]; NSDate *modificationDate = [NSDate dateWithTimeIntervalSince1970:statbuf.st_mtime]; NSDate *creationDate = [NSDate dateWithTimeIntervalSince1970:statbuf.st_ctime]; }
4、定期更新三方库
最近解决的很多问题都是因为第三方的一些问题导致的，如果发现第三方的原因，首先在github的issue中寻找有没有人提出相同的问题，如果没有可以及时在github上反馈，还有一种情况是github上有人提出了解决方案，但是库开发者并没有及时解决并更新代码，这时候我们可以先fork一份代码到自己的库中，然后在库中进行修改，之后将pod源对应到自己的库，例如解决GPUIamge录制视频时前后几帧出现黑屏的问题。
5.1 MLeakFinder
微信读书团队在github开源的一款内存泄露检测工具，具体原理和使用方法可以参见这篇文章。内存泄露引起的性能问题是很难被察觉的，只有泄露到了相当严重的程度，然后通过Instrument工具，不断尝试才得以定位。MLeakFinder能在开发阶段，把内存泄露问题暴露无遗，减少了很多潜在的性能问题。
