前言： 隨著專案的擴大和功能的增多，**沒有經過嚴格的除錯和優化，要麼任性地卡頓執行，要麼就低調地崩潰，最後導致使用者用著不開心，開發者也比較煩惱。
為了突破這個這個關卡其實並不難，首先開發者只要在xcode自帶的監控除錯工具 instruments 上花點功夫就能夠讓**順暢執行。工欲善其事，必先利其器。instrument對於ios開發來說，是發現並且解決問題的一把利器。instruments 提供了很多檢測功能，重點介紹一下我常用的幾大類：
analyze—靜態分析
leaks—記憶體洩露（動態記憶體洩露檢測）
time profiler：檢測分析**的執行時間
關注作者二字可以找到大神組織，不管是小白還是大牛，都歡迎入駐，一起交流，一起進步！
介面顯示的原理
ios裝置通常是60fps(每秒60幀)，也就是說兩幀相隔的時間是1/60秒，大概16.7ms。在這16.7ms中，為了顯示一幀，需要如下工作
cpu計算好各個檢視的位置，大小，對進行解碼等，繪製成紋理交給gpu
gpu對收到的紋理進行混合，頂點變換，渲染到幀緩衝區
每16.7ms,乙個時鐘訊號到達，幀緩衝區取出一幀，顯示到螢幕。
也就是說，cpu或者gpu被大量占用的時候，都有可能在16.7ms中沒辦法完成一幀的繪製，導致時鐘訊號到來的時候，取得還是上一幀的內容，也就都有可能導致介面卡頓
離屏渲染
在ios中，渲染通常分為cpu和gpu渲染兩種，而gpu渲染又分為在gpu緩衝區和非gpu緩衝區兩種
cpu渲染（軟體渲染）,cpu繪製成bitmap，交給gpu
gpu渲染（硬體渲染）
gpu緩衝區渲染
非gpu緩衝區渲染（額外開闢緩衝區）
通常，cpu渲染，和gpu非幀緩衝區內渲染統稱為離屏渲染。因為，cpu和幀緩衝區是為圖形影象顯示做了高度優化的，速度較快。
什麼情況下會觸發離螢幕渲染？
用coregraphics的cgcontext繪製的
在drawrect中繪製的，即使drawrect是空的
layer具有mask（比如圓角）或者shadow
layer的隔柵化shouldrasterize為true
文字(uilabel,uitextfield,uitextview,coretext,uitextlayer等)
一，analyze—靜態分析
顧名思義，靜態分析不需要執行程式，就能檢查到存在記憶體洩露的地方。
1. 使用方法：開啟xcode，command + shift + b；或者xcode - product - analyze；
2. 常見的三種洩露情形：
（1）建立了乙個物件，但是並沒有使用。xcode提示資訊： value stored to 'number' is never read 。翻譯一下：儲存在'number'裡的值從未被讀取過。
（2）建立了乙個（指標可變的）物件，且初始化了，但是初始化的值一直沒讀取過。xcode提示資訊： value stored to 'str' during its initialization is never read
（3）呼叫了讓某個物件引用計數加1的函式，但沒有呼叫相應讓其引用計數減1的函式。xcode提示資訊： potential leak of an object stored into 'subimageref' 。 翻譯一下：subimageref物件的記憶體單元有潛在的洩露風險。
ios效能分析和優化
二，leaks—記憶體洩露
leaks是動態的記憶體洩露檢查工具，需要一邊執行程式，一邊檢測。
1.使用方法: 進入xcode，command + control + i ；或者xcode - xcode - open developer tool - instruments; 或者xcode - product - profile。選擇leaks。
一般用靜態分析檢查過的**，記憶體洩露都比較少。測試了有3個專案能點的按鈕都點了，能進的頁面都進的，leaks也沒檢測到洩露。
三，time profile
2.進入主介面，上下滾動list，讓time profile採集資料，
勾選右側的
separate by thread，按執行緒區分
invert call tree ，逆向call tree，方便我們檢視方法呼叫順序
hide system libraries，隱藏系統的庫，因為通常系統的**並不會影響效能
3.可以選擇一段時間，來分析這段時間cpu的使用情況
ios效能分析和優化
4.找到占用時間最多的**
ios效能分析和優化
然後，雙擊占用最多的這一行，進入實際的**，看看到底**占用比較多
這裡，我們看到是這一行**cell.testlabel?.attributedtext = mutableattr。
占用最多的cpu時間。
我們先來看下整個方法**，
tableviewcell其實很簡單，就乙個imageview（帶圓角，陰影），乙個uilabel
cellforrowatindexpath裡會隨機的生成100個字元，然後用attributetext來讓uilabel顯示
乍一看，問題應該是這個隨機生成100個字元的函式啊
ios效能分析和優化
因為，每一次cellforrow呼叫的時候，都會計算100次。然後，我們實際分析的時候，發現其實100次對顯示來說，真不算什麼，也不是卡頓的原因。
那麼，為什麼設定attributetext占用時間這麼多呢？
其實很簡單，attributetext是建立在textkit上的，由於每一次顯示都是隨機的attributetext,每一次都要重新計算文字的大小，位置等等。另外，uikit中，提供的文字渲染都是在cpu中進行的，渲染成bitmap，然後交給gpu，所以導致設定attributetext的時候，占用很多時間。
這裡不得不提到：一定不要過早優化，優化的時候盡量依賴於instrument的分析結果，而不是自己的主觀感受。尤其當你還是個新司機的時候。
iOS開發必學之iOS效能分析和優化
前言 隨著專案的擴大和功能的增多，沒有經過嚴格的除錯和優化，要麼任性地卡頓執行，要麼就低調地崩潰，最後導致使用者用著不開心，開發者也比較煩惱。為了突破這個這個關卡其實並不難，首先開發者只要在xcode自帶的監控除錯工具 instruments 上花點功夫就能夠讓 順暢執行。工欲善其事，必先利其器。i...
效能優化 iOS
如果需要更詳細的資訊，那就將dyld print statistics details設定為1 2.1關於dyld 用machoview 檢視載入過程如上圖 備註1 如果設定了 dyld print libraries，或者選中run diagnostics 下面的 dynamic library ...
iOS效能優化 TableView
下面介紹一些我們可以自己設定的新能優化 1 盡量不透明的檢視 不透明檢視可以極大提高渲染的速度.因此如果可以,將 cell 及其子檢視的 opaque 屬性設定為 yes 預設值 cell 的 backgroundcolor 的 apha 值應為1 不要使用 clearcolor 影象的 apha ...