前言: 隨著專案的擴大和功能的增多,**沒有經過嚴格的除錯和優化,要麼任性地卡頓執行,要麼就低調地崩潰,最後導致使用者用著不開心,開發者也比較煩惱。
為了突破這個這個關卡其實並不難,首先開發者只要在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 ...