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