一：性能优化策略
性能问题的处理流程
1 发现/重现问题
2 利用工具剖析
3 形成假设
4 改进代码和设计
在以上的四个步骤中循环反复，直到问题解决。
Profile!不要猜!
性能优化的主要策略：
1、不要做无用功：不要在启动时花几百ms来做logging，不要为同样的数据做多次查询
试图重用：对于创建过程昂贵的对象，要重用而不是重新创建
1 Table View的cell
2 Date/Number的formatter
3 正则表达式
4 SQLite语句
2、使用更快的方式设计、编程：选择正确的集合对象和算法来进行编程、选择适合的数据存储格式（plist、SQLite）、优化SQLite查询语句
3、事先做优化
1 对于昂贵的计算，要进行事先计算。iCal中的重复事件，是预先计算出来的，并保存到数据库中。
2 事先计算并缓存一些对象，可能会占用大量的内存。注意不要将这些对象声明为static并常驻内存。
4、事后做优化：异步加载、懒加载
5、为伸缩性而做优化：当数据有10条、100条、1000条甚至更多的时候，应用程序的性能不应该对应的呈数量级式的增长，否则无法使用。
6、给iOS app做加密保护优化：本地数据加密、URL编码加密、网络传输数据加密、方法体，方法名高级混淆、程序结构混排加密
二：iOS应用启动速度优化
很多app的开发者都不重视app的启动速度，这对于碎片化使用情景的用户来说，简直是灾难。
iOS应用的启动速度
应用启动时，会播放一个放大的动画。iPhone上是400ms，iPad上是500ms。最理想的启动速度是，在播放完动画后，用户就可以使用。
如果应用启动过慢，用户就会放弃使用，甚至永远都不再回来。抛开代码不谈，如果抱着PC端游和单机游戏的思维，在游戏启动时强加公司Logo，启动动画，并且用户不可跳过，也会使用户的成功使用率大大降低。
iOS系统的“看门狗”
为了防止一个应用占用过多的系统资源，开发iOS的苹果工程师门设计了一个“看门狗”的机制。在不同的场景下，“看门狗”会监测应用的性能。如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者们在crashlog里面，会看到诸如0x8badf00d这样的错误代码(“看门狗”吃了坏的食物，它很不高兴)。
场景 “看门狗”超时时间
启动 20秒
恢复运行 10秒
悬挂进程 10秒
退出应用 6秒
后台运行 10分钟
值得注意的是，Xcode在Debug的时候，会禁止“看门狗”。
如何测试启动时间
两种方法：一种使用NSLog，另外一种使用Time Profiler。
1 使用NSLog
[pre]
[/pre]
2 使用Time Profiler
1）Instruments->Time Profiler
2）Profile你的app
3）切换到CPU strategy view，找到你的app启动的第一帧
4）搜索-[UIApplication _reportAppLaunchFinished]
5）找到包含-[UIApplication _reportAppLaunchFinished]的最后一帧，即可计算出启动时间
iOS App启动过程
1 链接并加载Framework和static lib
2 UIKit初始化
3 应用程序callback
4 第一个Core Animation transaction
链接并加载Framework及static lib时需要注意：
1 每个Framework都会增加启动时间和占用的内存
2 不必要的Framework，不要链接
3 必要的Framework，不要票房为Optional
4 只在使用在Deployment Target之后发布的Framework时，才使用Optional（比如你的Deployment Target是iOS 3.0，需要链接StoreKit的时候）
5 避免创建全局的C++对象
初始化UIKit时需要注意：
1 字体、状态栏、user defaults、main nib会被初始化
2 保持main nib尽可能的小
3 User defaults本质上是一个plist文件，保存的数据是同时被反序列化的，不要在user defaults里面保存图片等大数据
应用程序的回调：
1 application:willFinishLaunchingWithOptions:
2 恢复应用程序的状态
3 application:didFinishLaunchingWithOptions:
我一直认为设计的本质是折衷。当你为了100ms的启动速度优化欢欣不已，而无视那长达10秒的启动动画时，应该想想究竟什么是应该做的。做正确的事情比把事情做好更重要。
三：事件处理-拯救主线程
用户经常评论app的一个用词是“卡顿”，很大的因素是因为主线程被占用了。用户的事件是在主线程被处理的，包括点击、滚动、加速计、Proximity Sensor。
为了保证事件的平滑处理，需要进行如下优化：
1 最小化主线程的CPU占用
2 将工作“搬离”主线程
3 不要阻塞主线程
最小化主线程的CPU占用
使用Time Profiler可以剖析不同线程的CPU使用情况，并给出调用堆栈的CPU时间占用百分比。如果app“卡顿”，并且在Time Profiler的结果可以找到明确的高占用堆栈，你需要把它优化掉。
将工作“搬离”主线程 – 隐式并发
为了得到更流畅的交互体验，iOS已经帮我们做了很多事情，Android就没有这么好运了。iOS将以下这些事情搬离了主线程：
1 View和layer的动画（动画绘制前的计算，而不是drawing过程）
2 Layer的组合计算（drawing后的叠加）
3 PNG的解码（是的，你没看错；而且利用了CPU的多核心）
注意滚动（Scrolling）不是一个动画，而是在Main Run Loop中不断接收事件并且处理。
将工作“搬离”主线程 – 显式并发
这里是需要开发者们搞定的部分。磁盘、网络等I/O会阻塞线程，不要把它们放到主线程里。常用的技术有：
1 Grand Central Dispatch(GCD)
2 NSOperationQueue
3 NSThread
iOS 4.0后，易用的GCD技术被广泛使用。例如：
[pre]
[/pre]
GCD的陷阱
GCD其实就是线程，只不过提供了一个更高层次的抽象。过多的线程一定会带来性能损失，因此GCD设计了一个最高允许的线程值（对开发者透明，不用管到底有多少）。那么如何解决这个问题呢？
1 将队列串行化
2 使用Dispatch sources
3 使用带有限制的NSOperationQueue
4 使用Cocoa Touch提供的异步方法
另外一个陷阱是线程安全：
1 UIKit必须要在主线程使用，除了UIGraphics，UIBezierPath，UIImage
2 大多数CG、CA、Foundation的类，不是线程安全的
3 如果你使用了ojbc runtime来进行introspection，由于它是thread safe的，可能会导致竞争
此外，iOS 4.3添加了DISPATCH_QUEUE_PRIORITY_BACKGROUND，它拥有非常低的优先级。这个优先级只用于不太关心完成时间的真正的后台任务，如果要表示较低的优先级，你通常需要的是DISPATCH_QUEUE_PRIORITY_LOW。
不要阻塞主线程
即使占用了很少的CPU时间（如果你在Time Profiler中看到这些的数据），也可能会阻塞主线程。磁盘、网络、Lock、dispatch_sync以及向其它进程/线程发送消息都会阻塞主线 程。Time Profiler只能检测出占用CPU过多的堆栈，但检测不了这些IO的问题。
大多数的阻塞事件，都会伴随着一个系统调用，如：
1 read/write - 读写文件
2 send/recv - 收发网络数据
3 psynch_mutex_wait - 获得锁
4 mach_msg - IPC
System Trace这个Instrumentor，记录了所有的系统调用，以及每次调用的等待时间。如果你在System Trace里面发现了CPU Time很低，但Wait Time很高的调用，说明在主线程处理I/O已经严重损害了app的性能。
保证主线程的低CPU占用，将I/O移至其它线程，可以大大地提高主线程对交互事件的处理能力。我建议开发者朋友们写完iOS app代码，可以去试下iOS app加密，这对iOS性能优化是有一定好处的！
性能问题的处理流程
1 发现/重现问题
2 利用工具剖析
3 形成假设
4 改进代码和设计
在以上的四个步骤中循环反复，直到问题解决。
Profile!不要猜!
性能优化的主要策略：
1、不要做无用功：不要在启动时花几百ms来做logging，不要为同样的数据做多次查询
试图重用：对于创建过程昂贵的对象，要重用而不是重新创建
1 Table View的cell
2 Date/Number的formatter
3 正则表达式
4 SQLite语句
2、使用更快的方式设计、编程：选择正确的集合对象和算法来进行编程、选择适合的数据存储格式（plist、SQLite）、优化SQLite查询语句
3、事先做优化
1 对于昂贵的计算，要进行事先计算。iCal中的重复事件，是预先计算出来的，并保存到数据库中。
2 事先计算并缓存一些对象，可能会占用大量的内存。注意不要将这些对象声明为static并常驻内存。
4、事后做优化：异步加载、懒加载
5、为伸缩性而做优化：当数据有10条、100条、1000条甚至更多的时候，应用程序的性能不应该对应的呈数量级式的增长，否则无法使用。
6、给iOS app做加密保护优化：本地数据加密、URL编码加密、网络传输数据加密、方法体，方法名高级混淆、程序结构混排加密
二：iOS应用启动速度优化
很多app的开发者都不重视app的启动速度，这对于碎片化使用情景的用户来说，简直是灾难。
iOS应用的启动速度
应用启动时，会播放一个放大的动画。iPhone上是400ms，iPad上是500ms。最理想的启动速度是，在播放完动画后，用户就可以使用。
如果应用启动过慢，用户就会放弃使用，甚至永远都不再回来。抛开代码不谈，如果抱着PC端游和单机游戏的思维，在游戏启动时强加公司Logo，启动动画，并且用户不可跳过，也会使用户的成功使用率大大降低。
iOS系统的“看门狗”
为了防止一个应用占用过多的系统资源，开发iOS的苹果工程师门设计了一个“看门狗”的机制。在不同的场景下，“看门狗”会监测应用的性能。如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者们在crashlog里面，会看到诸如0x8badf00d这样的错误代码(“看门狗”吃了坏的食物，它很不高兴)。
场景 “看门狗”超时时间
启动 20秒
恢复运行 10秒
悬挂进程 10秒
退出应用 6秒
后台运行 10分钟
值得注意的是，Xcode在Debug的时候，会禁止“看门狗”。
如何测试启动时间
两种方法：一种使用NSLog，另外一种使用Time Profiler。
1 使用NSLog
[pre]
复制代码
|
2 使用Time Profiler
1）Instruments->Time Profiler
2）Profile你的app
3）切换到CPU strategy view，找到你的app启动的第一帧
4）搜索-[UIApplication _reportAppLaunchFinished]
5）找到包含-[UIApplication _reportAppLaunchFinished]的最后一帧，即可计算出启动时间
iOS App启动过程
1 链接并加载Framework和static lib
2 UIKit初始化
3 应用程序callback
4 第一个Core Animation transaction
链接并加载Framework及static lib时需要注意：
1 每个Framework都会增加启动时间和占用的内存
2 不必要的Framework，不要链接
3 必要的Framework，不要票房为Optional
4 只在使用在Deployment Target之后发布的Framework时，才使用Optional（比如你的Deployment Target是iOS 3.0，需要链接StoreKit的时候）
5 避免创建全局的C++对象
初始化UIKit时需要注意：
1 字体、状态栏、user defaults、main nib会被初始化
2 保持main nib尽可能的小
3 User defaults本质上是一个plist文件，保存的数据是同时被反序列化的，不要在user defaults里面保存图片等大数据
应用程序的回调：
1 application:willFinishLaunchingWithOptions:
2 恢复应用程序的状态
3 application:didFinishLaunchingWithOptions:
我一直认为设计的本质是折衷。当你为了100ms的启动速度优化欢欣不已，而无视那长达10秒的启动动画时，应该想想究竟什么是应该做的。做正确的事情比把事情做好更重要。
三：事件处理-拯救主线程
用户经常评论app的一个用词是“卡顿”，很大的因素是因为主线程被占用了。用户的事件是在主线程被处理的，包括点击、滚动、加速计、Proximity Sensor。
为了保证事件的平滑处理，需要进行如下优化：
1 最小化主线程的CPU占用
2 将工作“搬离”主线程
3 不要阻塞主线程
最小化主线程的CPU占用
使用Time Profiler可以剖析不同线程的CPU使用情况，并给出调用堆栈的CPU时间占用百分比。如果app“卡顿”，并且在Time Profiler的结果可以找到明确的高占用堆栈，你需要把它优化掉。
将工作“搬离”主线程 – 隐式并发
为了得到更流畅的交互体验，iOS已经帮我们做了很多事情，Android就没有这么好运了。iOS将以下这些事情搬离了主线程：
1 View和layer的动画（动画绘制前的计算，而不是drawing过程）
2 Layer的组合计算（drawing后的叠加）
3 PNG的解码（是的，你没看错；而且利用了CPU的多核心）
注意滚动（Scrolling）不是一个动画，而是在Main Run Loop中不断接收事件并且处理。
将工作“搬离”主线程 – 显式并发
这里是需要开发者们搞定的部分。磁盘、网络等I/O会阻塞线程，不要把它们放到主线程里。常用的技术有：
1 Grand Central Dispatch(GCD)
2 NSOperationQueue
3 NSThread
iOS 4.0后，易用的GCD技术被广泛使用。例如：
[pre]
复制代码
|
GCD的陷阱
GCD其实就是线程，只不过提供了一个更高层次的抽象。过多的线程一定会带来性能损失，因此GCD设计了一个最高允许的线程值（对开发者透明，不用管到底有多少）。那么如何解决这个问题呢？
1 将队列串行化
2 使用Dispatch sources
3 使用带有限制的NSOperationQueue
4 使用Cocoa Touch提供的异步方法
另外一个陷阱是线程安全：
1 UIKit必须要在主线程使用，除了UIGraphics，UIBezierPath，UIImage
2 大多数CG、CA、Foundation的类，不是线程安全的
3 如果你使用了ojbc runtime来进行introspection，由于它是thread safe的，可能会导致竞争
此外，iOS 4.3添加了DISPATCH_QUEUE_PRIORITY_BACKGROUND，它拥有非常低的优先级。这个优先级只用于不太关心完成时间的真正的后台任务，如果要表示较低的优先级，你通常需要的是DISPATCH_QUEUE_PRIORITY_LOW。
不要阻塞主线程
即使占用了很少的CPU时间（如果你在Time Profiler中看到这些的数据），也可能会阻塞主线程。磁盘、网络、Lock、dispatch_sync以及向其它进程/线程发送消息都会阻塞主线 程。Time Profiler只能检测出占用CPU过多的堆栈，但检测不了这些IO的问题。
大多数的阻塞事件，都会伴随着一个系统调用，如：
1 read/write - 读写文件
2 send/recv - 收发网络数据
3 psynch_mutex_wait - 获得锁
4 mach_msg - IPC
System Trace这个Instrumentor，记录了所有的系统调用，以及每次调用的等待时间。如果你在System Trace里面发现了CPU Time很低，但Wait Time很高的调用，说明在主线程处理I/O已经严重损害了app的性能。
保证主线程的低CPU占用，将I/O移至其它线程，可以大大地提高主线程对交互事件的处理能力。我建议开发者朋友们写完iOS app代码，可以去试下iOS app加密，这对iOS性能优化是有一定好处的！
