前言
對于iOS上一文簡單介紹內(nèi)存，可是還少了寫東西，我自己感覺對于內(nèi)存和線程的聯(lián)系不夠多。特別是app 在多線程處理任務和實際業(yè)務邏輯的聯(lián)系，是不夠的，隨著以后的項目的疊加，這方面我會更新。
這篇簡單介紹自己在app 時間消耗的檢測
工具
還是instrument 工具是
Time profile 具體使用
打開后
線程模式
對于all process 不能確定到底是哪個線程，可以點擊右上角的具體線程分析
在時間軸上進行區(qū)域選擇，這樣就能判斷出來，具體的時間耗時。
第三個就是，第一個是對于cpu 哪個內(nèi)核的消耗情況
線程區(qū)域選擇
說明是主線程是主要耗時的線程，然后耗時的時間大概是269ms，下一步就是找出具體的函數(shù)方法
集中顯示代碼的耗時問題
1）Separate by Thread：按線程分開進行分析。容易找出消耗資源的問題線程，特別是對于主線程，因為主線程要處理和渲染所有的接口數(shù)據(jù)及UI視圖，當主線程受到阻塞性操作，一定會造成程序的卡頓，或停止響應。
（2）Invert Call Tree：反向顯示調(diào)用樹。把調(diào)用層級最深的方法顯示在最上面，容易找到最耗時的操作。
（3）Hide System Libraries：隱藏缺失的符號。把干擾信息屏蔽掉，即把列表中因為系統(tǒng)架構，或DSYM文件缺失造成奇怪的十六進制的數(shù)值。
（4）Flatten Recursion：拼合遞歸。把同一遞歸函數(shù)產(chǎn)生的多條堆棧合并為一條。
（5）Top Functions：找到最耗時的函數(shù)或方法。
不過，我在選擇過程中，遇到個不大不小的問題，就是選擇投票functions 的時候 instrument 崩潰。
尋找代碼
對于自己代碼中weight的比例 和self weight的時長，過大的要審查，是不是有復制的邏輯，或者大量的內(nèi)存申請，大的圖片緩存
一般如果網(wǎng)絡請求，可以看看，是不是網(wǎng)絡架構和網(wǎng)絡請求的效率和json 解析的方式是不是最優(yōu)。
這里的每一個細化，可能是選擇第三方的依據(jù)，何必重復自己來造輪子呢。
例子
這里顯然比較耗時的是tabbar 的設置，而不是他上班的loc 的定位，也不是網(wǎng)絡請求。
問題確定來，下一步就是相關問題解決了。根據(jù)不同的項目，不同的責任人來進行代碼的優(yōu)化。
一看一個10% 不少，是不是可以剩下來，還要看業(yè)務邏輯是不是允許這樣優(yōu)化，一切的優(yōu)化建立在產(chǎn)品需求的要求基礎上。
具體方法尋找
圖片設置在button 上的問題，更加確定和tabbar 也是沒有關系。
利用imageWithContentsOfFile 設置圖片 就解決了這個加載耗時的問題，為啥tabbar 對于小圖片如此敏感呢？？？
這里的性能
時間消耗，直接影響是app 的流暢和使用的感受，作為客戶單研發(fā)，這個還是尤為重要,可是當在優(yōu)化app的時候，優(yōu)化多少，哪里優(yōu)化，哪里有優(yōu)化的必要，還有誰來優(yōu)化哪里，這些都需要圖形化數(shù)據(jù)來體現(xiàn)，這個工具太棒來。
以后的性能
對于第三方的性能我們還有很多引用，不過哪個更好，這個還是性能說的算，如 YYModel ，JsonModel,等，解析對象時候，哪個更快，說時候，如果項目不夠復雜，真是很難感覺到。
參考文獻
官方文檔
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Instrument-TimeProfiler.html
簡書推薦
http://www.itdecent.cn/p/68387876ebcc
