前言： 隨著專案的擴大和功能的增多，**沒有經過嚴格的除錯和優化，要麼任性地卡頓執行，要麼就低調地崩潰，最後導致使用者用著不開心，開發者也比較煩惱。
為了突破這個這個關卡其實並不難，首先開發者只要在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物件的記憶體單元有潛在的洩露風險。
二，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的使用情況
4.找到占用時間最多的**
然後，雙擊占用最多的這一行，進入實際的**，看看到底**占用比較多
這裡，我們看到是這一行**cell.testlabel?.attributedtext = mutableattr。
占用最多的cpu時間。
我們先來看下整個方法**，
tableviewcell其實很簡單，就乙個imageview（帶圓角，陰影），乙個uilabel
cellforrowatindexpath裡會隨機的生成100個字元，然後用attributetext來讓uilabel顯示
乍一看，問題應該是這個隨機生成100個字元的函式啊
因為，每一次cellforrow呼叫的時候，都會計算100次。然後，我們實際分析的時候，發現其實100次對顯示來說，真不算什麼，也不是卡頓的原因。
那麼，為什麼設定attributetext占用時間這麼多呢？
其實很簡單，attributetext是建立在textkit上的，由於每一次顯示都是隨機的attributetext,每一次都要重新計算文字的大小，位置等等。另外，uikit中，提供的文字渲染都是在cpu中進行的，渲染成bitmap，然後交給gpu，所以導致設定attributetext的時候，占用很多時間。
這裡不得不提到：一定不要過早優化，優化的時候盡量依賴於instrument的分析結果，而不是自己的主觀感受。尤其當你還是個新司機的時候。
新手小白必學之IOS定位操作
對於初次學習ios開發的新手小白來說，ios定位操作是十分關鍵的，下面簡單介紹一下 在ios中通過corelocation定位，可以獲取到使用者當前位置，同時能得到裝置移動資訊。2 擇專案檔案，然後選擇目標，然後新增corelocation.framework,如下所示 3 在viewcontrol...
iOS效能分析和優化
前言 隨著專案的擴大和功能的增多，沒有經過嚴格的除錯和優化，要麼任性地卡頓執行，要麼就低調地崩潰，最後導致使用者用著不開心，開發者也比較煩惱。為了突破這個這個關卡其實並不難，首先開發者只要在xcode自帶的監控除錯工具 instruments 上花點功夫就能夠讓 順暢執行。工欲善其事，必先利其器。i...
iOS效能調優之Analyze靜態分析
目前關於ios效能優化的教程較少，決定寫乙個 ios效能調優系列 主要關注與記憶體洩漏 效能優化 流量和電量分析幾個方面。xcode已經提供了非常強大的效能調優工具，結合幾個第三方工具和一些技巧，進行效能優化非常簡單。第一篇先寫寫最簡單的，analyze靜態分析。analyze主要分析以下四種問題 ...