iOS性能优化过程浅析

• 使用NSLog

   CFAbsoluteTime StartTime;  
   int main(int argc, char **argv) {  
        StartTime = CFAbsoluteTimeGetCurrent(); 
        // ...  5 }  6   
   - (void)applicationDidFinishLaunching:(UIApplication *)app {  
        dispatch_async(dispatch_get_main_queue(), ^{  
  
  NSLog(@"Launched in %f sec", CFAbsoluteTimeGetCurrent() - StartTime); 
  
  }); 
        // ... 
    }

• 使用Time Profiler
  • Instruments->Time Profiler
  • Profile你的app
  • 切换到CPU strategy view，找到你的app启动的第一帧
  • 搜索 -[UIApplication _reportAppLaunchFinished]
  • 找到包含 -[UIApplication _reportAppLaunchFinished]的最后一帧，即可计算出启动时间

iOS App启动过程

• 链接并加载Framework和static lib
• UIKit初始化
• 应用程序callback
• 第一个Core Animation transaction

链接并加载Framework及static lib时需要注意：

• 每个Framework都会增加启动时间和占用的内存
• 不必要的Framework，不要链接
• 必要的Framework，不要票房为Optional
• 只在使用在Deployment Target之后发布的Framework时，才使用Optional（比如你的Deployment Target是iOS 3.0，需要链接StoreKit的时候）
• 避免创建全局的C++对象

初始化UIKit时需要注意：

• 字体、状态栏、user defaults、main nib会被初始化
• 保持main nib尽可能的小
• User defaults本质上是一个plist文件，保存的数据是同时被反序列化的，不要在user defaults里面保存图片等大数据

应用程序的回调：

• application:willFinishLaunchingWithOptions:
• 恢复应用程序的状态
• application:didFinishLaunchingWithOptions:

我一直认为设计的本质是折衷。当你为了100ms的启动速度优化欢欣不已，而无视那长达10秒的启动动画时，应该想想究竟什么是应该做的。 做正确的事情比把事情做好更重要。

三：事件处理-拯救主线程

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), 
^{    
 // do something in background     dispatch_async(dispatch_get_main_queue(), ^{        
 // do something on main thread    
 }); });

GCD的陷阱

GCD其实就是线程，只不过提供了一个更高层次的抽象。过多的线程一定会带来性能损失，因此GCD设计了一个最高允许的线程值（对开发者透明，不用管到底有多少）。那么如何解决这个问题呢？

• 将队列串行化
• 使用Dispatch sources
• 使用带有限制的NSOperationQueue
• 使用Cocoa Touch提供的异步方法

另外一个陷阱是线程安全：

• UIKit必须要在主线程使用，除了UIGraphics，UIBezierPath，UIImage
• 大多数CG、CA、Foundation的类，不是线程安全的
• 如果你使用了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的问题。

大多数的阻塞事件，都会伴随着一个系统调用，如：

• read/write - 读写文件
• send/recv - 收发网络数据
• psynch_mutex_wait - 获得锁
• mach_msg - IPC

System Trace这个Instrumentor，记录了所有的系统调用，以及每次调用的等待时间。如果你在System Trace里面发现了CPU Time很低，但Wait Time很高的调用，说明在主线程处理I/O已经严重损害了app的性能。

保证主线程的低CPU占用，将I/O移至其它线程，可以大大地提高主线程对交互事件的处理能力。我建议开发者朋友们写代码的时候，除非是以前遇到过的问题，都没有必要假设问题存在。 80%的优化都是不必要的。