前言
分析
首先看下未優化前的效果圖：
測試裝置:iphone7 ，系統：12.1細心的同學應該能夠發現，在登入進入首頁，到首頁渲染結束，中間會有一段白屏，為什麼會白屏一會而沒有馬上渲染首頁呢，第一感覺肯定是這中間形成主線程阻塞了，讓ui沒有立即渲染出來，其實事實上確實是這樣，那接下來我們通過instruments分析一下**執行了耗時操作以至於首頁渲染被阻塞了。instruments裡面有個工具timeprofiler，可以用來幫我們檢視**有耗時操作。關於這個工具的使用和配置網上很多介紹本篇不做重點分析了，我直接粘除錯的了。
通過timeprofiler的結果一目了然，在customtabbaritem裡面做了什麼用了387ms。可以在工具裡面直接右鍵進入到到這段耗時**的位置。我總共測試了五個tabbar渲染item的耗時：
看打點日誌就很恐怖了，執行兩個imagename:就消耗了主線程差不多100ms的時間，五個tabbar那就是500ms的時間，顯然這就是上面效果圖出現白屏的原因了，實際上imagename:是會對進行解碼之後再渲染的。
既然原因找到了，那就嘗試解決一下。將這個耗時的操作放到子執行緒執行，這裡也是參考了sdwebimage的編譯碼的思路，sd在拿到data的時候並沒有將它直接轉為image物件，而是在子執行緒裡面做了乙個解碼的操作，這樣已經被解碼的就賦值給imageview的時候就不會再進行解碼，也就不會妨礙主線程了。
**實現很簡單，就是將的操作放入到乙個全域性佇列中，當然也可以自己建立乙個佇列去執行這個非同步操作。decodedimagewithimage:為sd的**，需要#import "sdwebimagedecoder.h"，具體實現網上對這一塊的原始碼解釋的比較多，很容易理解。- (void)decodedimagewithimagename:(nsstring *)imagename block:(void(^)(uiimage *image))block );}});
}
從總計500ms降到了6ms，基本可以忽略不及了，我們再在真機上面看一下優化後的效果：
測試：
總結
通過上面的分析，實際上imagename:這樣的ui函式我們天天都在用，但是從沒想過它在某些地方能產生這麼大的影響。問題的定位和解決其實都很簡單，但是這種簡單的問題往往會被我們開發者忽略掉，產生一些不好的結果，值得反思。
iOS效能優化中的離屏渲染
gpu螢幕渲染有以下兩種方式 特殊的離屏渲染 如果將不在gpu的當前螢幕緩衝區中進行的渲染都稱為離屏渲染，那麼就還有另一種特殊的 離屏渲染 方式 cpu渲染。完成，渲染得到的bitmap最後再交由gpu用於顯示。cpu渲染 gpu顯示 什麼時候會喚起離屏渲染 當使用圓角，陰影，遮罩的時候，圖層屬性的...
iOS離屏渲染之優化分析
在進行ios的應用開發過程中，有時候會出現卡頓的問題，雖然ios裝置的效能越來越高，但是卡頓的問題還是有可能會出現，而離屏渲染是造成卡頓的原因之一。因此，本文主要分析一下離屏渲染產生的原因及避免的方法，最後介紹一下xcode自帶的分析離屏渲染的工具instruments的使用。calayer繼承自n...
Unity 優化 渲染優化
渲染優化主要是減少gpu的壓力。1 透明效果 overdraw就是過度繪製，是指在一幀的時間內 16.67ms 畫素被繪製了多次，理論上乙個畫素每次只繪製一次是最優的，但是由於重疊的布局導致一些畫素會被多次繪製，而每次繪製都會對應到cpu的一組繪圖命令和gpu的一些操作，當這個操作耗時超過16.67...
