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%的優化都是不必要的。