一、开篇
最近几天在做APP的性能优化问题，遇到了很多问题，所以来总结和分享一下。
内存泄露解决分为了三步：
- 静态分析：Instruments的Analyze。通过静态分析我们可以最初步的了解到代码的一些不规范的地方和一些代码逻辑上的错误；
- 解决ViewController不释放的问题；
- Instruments的Leaks。运行时分析内存泄露情况并解决；
根据这三步的解决内存泄露问题，每一步包含的内容比较多，所以我分为三篇文章来写。
这篇文章是总结静态分析代码的时候遇到的常见的几类问题，及解决方法。首先会介绍下内存泄露相关的基础知识。
二、内存泄露相关的基础知识
1.概念
内存泄露：如果程序运行时一直分配内存而不及时释放无用的内存，程序占用的内存越来越大，直到把系统分配给该APP的内存消耗殚尽，程序因无内存可用导致崩溃，这样的情况我们称之为内存泄漏。
2. 可能引起的问题
1)内存消耗殆尽的时候，程序会因没有内存被杀死，即crash。
2)当内存快要用完的时候，会非常的卡顿
3)如果是ViewController没有释放掉，引起的内存泄露，还会引起其他很多问题，尤其是和通知相关的。没有被释放掉的ViewController还能接收通知，还会执行相关的动作，所以会引起各种各样的异常情况的发生。
三、Analyze检测出的几种常见问题
使用Analyze能够发现一些代码不规范的地方。下面是我调试的过程中遇到的一些问题。
-
value stored to ‘width’during its initialization is never read。
该问题的原因是：变量申请了内存并初始化了，但没有用使此变量，接着将此变量又从新赋值. - (CGSize)sizeForContent:(MGCMessageBaseEntity*)message { float width = size.width < 20 ? 20 : size.width + 5; width = size.width > MAX_CHAT_TEXT_WIDTH ? MAX_CHAT_TEXT_WIDTH : size.width; return CGSizeMake(width, size.height + 3); } 规范的写法是：float width = size.width > MAX_CHAT_TEXT_WIDTH ? MAX_CHAT_TEXT_WIDTH : size.width; 还有一种情况是：为同一个数据源分配了两块内存，这里不会引起内存泄露，因为为arr1分配的内存块虽然一直是空闲块，但是在生命周期结束时，这块内存会被释放掉。跟前面说的，内存泄露是内存一直得不到释放，才会造成内存泄露。 NSArray *arr1 = [[NSArray alloc]init]; if(index == 1){ arr1 = self.usersArray; }else{ arr1 = self.editArray; } 因为self.usersArray和self.editArray都是被初始化过的数组，将它们赋值给了arr1，arr1又申请了内存。规范的写法是：NSArray *arr1；不为arr1分配内存。 -
Value stored to 'titleString' is never read
该变量从来没有被使用 -
Potential leak of an object allocated on line 101 and stored into ''
潜在的内存泄露：这里主要是一些非OC对象，ARC不会对它进行释放，所以造成了一直没有释放。比如一些类型：CGImageRef（对应调用CGImageRelease）、CGContextRef（对应调用CGContextRelease）CGColorSpaceRef（对应CGColorSpaceRelease） 这些都是非OC对象，所以要自己记着释放掉。 Analyze还能检查出一些逻辑上的错误，并且指出原因，简直太好用了。不出例子了，因为代码已经解决了好几天了，现在不存在有逻辑错误的代码了。
