TODO List:
1.Try to finish clean up all git and fabric issue.2
2.Write an article about the Memory performance optimization
Actual List:
1.Still pending for the git and fabric issues.
Memory Optimization
前言：最近遇到iPad在刚启动之后，过1分钟就会Crash的问题，然后在Fabric上查不到对应的崩溃栈信息。根据经验，找不到Crash要么是系统安全退出（切换设置），要么就是OOM。
调查：1.首先这个crash 是可以稳定重现的，这个是能修复该逻辑的前提
2.通过观察在控制台的log输出情况发现了：
Nov 30 16:09:18 -iPad MyApp(UIKit)[35527]: Received memory warning.
Nov 30 16:09:25 -iPad SpringBoard(FrontBoard)[4918]:was killed by jetsam.
Nov 30 16:09:25 -iPad SpringBoard[4918]: Process exited:->
就在收到Memory Warning 时便被杀掉，这样就可以断定是OOM引起的。
分析：1.确定了是OOM之后，我们左手开始分析原因
Activity Monitor: 能给从全局看到当前App在整个设备中的使用情况，包括真实占用内存（当然也可以看到在应用被杀掉 的内存情况），线程数量，CPU使用情况等。
Allocations:在使用AM有了一个总体概括是，这时候需要使用它对内存分配能够比较细致的观察，它提供了几个比较有用的视图：
Statistics: 可以看到整个看到整个内存配分对象的概况
CallTree:个人觉得非常有用，特别是配合“Invert Call Tree” 和 “Hide the system libraries”使用时，能给帮助你很快定位到耗内存最多的对象是如何通过应用代码调用过去的。（同理也可以应用在Time Profile）.
2.通过用Call Tree 视图分析发现是由于开机后反复大量调用该方法造成的问题，自此找到了核心问题点。
3.总结：个人认为解决内存或CPU问题的核心在于：
1.能稳定重现（包括固定的起始点），比如每次开机之后什么都不做过30s就崩溃
2.使用Activity Monitor 粗略且全局观察应用当前的内存/CPU消耗，从而了解到这一问题带来的内存/CPU开销值
3.使用 如Allocations/Time Profiler 进行细节调查，按照消耗内存最多/CPU最多排序，快速定位应用代码中最多的调用
4.定位到问题代码后，通过尝试简单去掉，观察是否解决了这一问题，如果是，找到优化这块代码的方法，如果否，说明并没有找到根源，需要重复步骤3.
5.完成步骤四之后，我们可以在使用Activity Monitor记录优化后的结果，以便可以跟优化前做对比。
