1.除了UI部分，所有的載入操作都在後臺完成。

1.1  文字計算

如果一個介面中包含大量文字，文字的寬高計算會佔用很大一部分資源，並且不可避免。如果你對文字顯示沒有特殊要求，可以參考下 UILabel 內部的實現方式：用 [NSAttributedStringboundingRectWithSize:options:context:] 來計算文字寬高，

用 -[NSAttributedStringdrawWithRect:options:context:] 來繪製文字。儘管這兩個方法效能不錯，但仍舊需要放到後臺執行緒進行以避免阻塞主執行緒。

如果你用 CoreText 繪製文字，那就可以先生成

1.2文字渲染

螢幕上能看到的所有文字內容控制元件，包括 UIWebView，在底層都是通過 CoreText 排版、繪製為 Bitmap 顯示的。常見的文字控制元件 （UILabel、UITextView 等），其排版和繪製都是在主執行緒進行的，當顯示大量文字時，CPU 的壓力會非常大。對此解決方案只有一個，那就是自定義文字控制元件，用 TextKit 或最底層的 CoreText 對文字非同步繪製。

儘管這實現起來非常麻煩，但其帶來的優勢也非常大，CoreText 物件建立好後，能直接獲取文字的寬高等資訊，避免了多次計算（調整

1.3圖片的解碼

用 UIImage 或CGImageSource 的那幾個方法建立圖片時，圖片資料並不會立刻解碼。圖片設定到 UIImageView 或者 CALayer.contents 中去，並且 CALayer 被提交到 GPU 前，CGImage 中的資料才會得到解碼。這一步是發生在主執行緒的，並且不可避免。如果想要繞開這個機制，常見的做法是在後臺執行緒先把圖片繪製到 CGBitmapContext 中，然後從 Bitmap 直接建立圖片。目前常見的網路圖片庫都自帶這個功能。

 1.4影象的繪製

影象的繪製通常是指用那些以 CG 開頭的方法把影象繪製到畫布中，然後從畫布建立圖片並顯示這樣一個過程。這個最常見的地方就是 [UIView drawRect:] 裡面了。由於CoreGraphic 方法通常都是執行緒安全的，所以影象的繪製可以很容易的放到後臺執行緒進行。一個簡單非同步繪製的過程大致如下（實際情況會比這個複雜得多，但原理基本一致）：

- (void)display {

dispatch_async(backgroundQueue,^{

CGContextRef ctx =CGBitmapContextCreate(...);

// draw in context...

CGImageRef img =CGBitmapContextCreateImage(ctx);

CFRelease(ctx);

dispatch_async(mainQueue, ^{

layer.contents = img;

});

});

}

可以通過dispatch或者performSelectorInBackground或者NSOperationQueue來實現。

 1.5   I/o操作

        檔案讀寫

        網路

2. 避免後臺載入完成多個資源之後集中到達佔用UI執行緒的處理時間太長。（短時間內UI集中重新整理）

通過NSOperationQueue來實現，將資源到UI的展現過程放在佇列中逐個執行，且在每個操作完成之後進行強制等待，可以用usleep(int microSeconds)來解決。

3.執行緒數太多

原因：

（1）大量的任務提交到後臺佇列時，某些任務會因為某些原因被鎖住導致執行緒休眠，或者被阻塞。

      concurrentqueue 隨後會建立新的執行緒來執行其他任務。

當這種情況變多時，或者 App 中使用了大量 concurrent queue 來執行較多工時，App 在同一時刻就會存在幾十個執行緒同時執行、建立、銷燬。

         CPU 是用時間片輪轉來實現執行緒併發的，儘管 concurrent queue 能控制執行緒的優先順序，但當大量執行緒同時建立執行銷燬時，這些操作仍然會擠佔掉主執行緒的 CPU 資源。

（2）執行緒數量達到 64個，導致也是導致卡頓的原因。

4 使用lock 時 ，不能Unlock 造成

解決方式： 使用自旋鎖，遞迴鎖。

-(void) dispatch_reentrant(void(^block)())

{

staticNSRecursiveLock *lock = nil;

staticdispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

lock =[[NSRecursiveLock alloc]init];

});

[locklock];

block();

[lockunlock];

}

dispatch_queue_t queueA = dispatch_queue_create("com.queueA", NULL);

dispatch_block_t block = ^{

//do something

};

dispatch_sync(queueA, ^{

dispatch_reentrant(block);

});

5 使用 GCDdispatch_sync 死鎖卡頓

queueA—>queueB—>queueA

- (void)deadLockFunc

{

dispatch_queue_t queueA =dispatch_queue_create("com.queueA", NULL);

dispatch_queue_t queueB =dispatch_queue_create("com.queueB", NULL);

dispatch_sync(queueA, ^{

dispatch_sync(queueB, ^{

dispatch_block_t block = ^{

//do something

};

func(queueA, block);

});

});

}

解決方式， FMDB，AFNetWork 中 採用dispatch_queue_set_specific ，dispatch_get_specific標記 佇列 ，然後 進行判斷處理，或給出log告警

dispatch_queue_t queueA =dispatch_queue_create("com.queueA", NULL);

dispatch_queue_t queueB =dispatch_queue_create("com.queueB", NULL);

dispatch_set_target_queue(queueB, queueA);

static int specificKey;

CFStringRef specificValue =CFSTR("queueA");

dispatch_queue_set_specific(queueA,

&specificKey,

(void*)specificValue,

(dispatch_function_t)CFRelease);

dispatch_sync(queueB, ^{

dispatch_block_t block = ^{

//do something

};

CFStringRef retrievedValue =dispatch_get_specific(&specificKey);

if (retrievedValue) {

block();

} else {

dispatch_sync(queueA, block);

}

});

6  檢視的混合 

當多個檢視（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果檢視結構過於複雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應用應當儘量減少檢視數量和層次，並在不透明的視圖裡標明 opaque 屬性以避免無用的 Alpha 通道合成。當然，這也可以用上面的方法，把多個檢視預先渲染為一張圖片來顯示。

7  主執行緒中UI物件建立

物件的建立會分配記憶體、調整屬性、甚至還有讀取檔案等操作，比較消耗 CPU 資源。儘量用輕量的物件代替重量的物件，可以對效能有所優化。

比如 CALayer 比 UIView 要輕量許多，那麼不需要響應觸控事件的控制元件，用 CALayer 顯示會更加合適。如果物件不涉及 UI 操作，則儘量放到後臺執行緒去建立，但可惜的是包含有 CALayer 的控制元件，都只能在主執行緒建立和操作。

·      

參考： http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/