卡頓優化
添加Observer到主線程RunLoop中,經過監聽RunLoop狀態切換的耗時,以達到監控卡頓的目的git
CPU:github
- 使用輕量級的對象好比用不到事件處理的地方,能夠考慮使用CALayer取代UIView
- 不要頻繁地調用UIView的相關屬性,好比frame、bounds、transform等屬性,儘可能減小沒必要要的修改
- 儘可能提早計算好佈局,在有須要時一次性調整對應的屬性,不要屢次修改屬性
- Autolayout會比直接設置frame消耗更多的CPU資源
- 圖片的size最好恰好跟UIImageView的size保持一致
- 控制一下線程的最大併發數量
- 儘可能把耗時的操做放到子線程,如文字尺寸計算、繪製,圖片解碼、繪製、壓縮
GPU:數據庫
- 儘可能避免短期內大量圖片的顯示,儘量將多張圖片合成一張進行顯示
- GPU能處理的最大紋理尺寸是4096x4096,一旦超過這個尺寸,就會佔用CPU資源進行處理,因此紋理儘可能不要超過這個尺寸
- 儘可能減小視圖數量和層次
- 減小透明的視圖(alpha<1),不透明的就設置opaque爲YES
- 儘可能避免出現離屏渲染(離屏渲染,在當前屏幕緩衝區之外新開闢一個緩衝區進行渲染操做)
- 光柵化,layer.shouldRasterize = YES
- 遮罩,layer.mask
- 圓角,同時設置layer.masksToBounds = YES、layer.cornerRadius大於0
- 陰影,layer.shadowXXX
耗電優化
- 少用定時器
- 儘可能不要頻繁寫入小數據,最好批量一次性寫入
- 讀寫大量重要數據時,考慮用dispatch_io,其提供了基於GCD的異步操做文件I/O的API。用dispatch_io系統會優化磁盤訪問
- 數據量比較大的,建議使用數據庫(好比SQLite、CoreData)
- 減小、壓縮網絡數據
- 若是屢次請求的結果是相同的,儘可能使用緩存
- 使用斷點續傳,不然網絡不穩定時可能屢次傳輸相同的內容
- 網絡不可用時,不要嘗試執行網絡請求
- 讓用戶能夠取消長時間運行或者速度很慢的網絡操做,設置合適的超時時間
- 批量傳輸,好比,下載視頻流時,不要傳輸很小的數據包,直接下載整個文件或者一大塊一大塊地下載。若是下載廣告,一次性多下載一些,而後再慢慢展現。若是下載電子郵件,一次下載多封,不要一封一封地下載
- 若是隻是須要快速肯定用戶位置,最好用CLLocationManager的requestLocation方法。定位完成後,會自動讓定位硬件斷電
- 若是不是導航應用,儘可能不要實時更新位置,定位完畢就關掉定位服務
- 儘可能下降定位精度,好比儘可能不要使用精度最高的kCLLocationAccuracyBest
- 須要後臺定位時,儘可能設置pausesLocationUpdatesAutomatically爲YES,若是用戶不太可能移動的時候系統會自動暫停位置更新
- 儘可能不要使用startMonitoringSignificantLocationChanges,優先考慮startMonitoringForRegion:
- 用戶移動、搖晃、傾斜設備時,會產生動做(motion)事件,這些事件由加速度計、陀螺儀、磁力計等硬件檢測。在不須要檢測的場合,應該及時關閉這些硬件
啓動速度優化
- 減小動態庫、合併一些動態庫(按期清理沒必要要的動態庫)
- 減小Objc類、分類的數量、減小Selector數量(按期清理沒必要要的類、分類)
- 減小C++虛函數數量
- Swift儘可能使用struct
- 用+initialize方法和dispatch_once取代全部的__attribute__((constructor))、C++靜態構造器、ObjC的+load
- 在不影響用戶體驗的前提下,儘量將一些操做延遲,不要所有都放在finishLaunching方法中
- 按需加載
包大小優化
- 資源(圖片、音頻、視頻等)採起無損壓縮
- 去除沒有用到的資源: github.com/tinymind/LS…
- 利用AppCode(www.jetbrains.com/objc/) 檢測未使用的代碼:菜單欄 -> Code -> Inspect Code
- 編寫LLVM插件檢測出重複代碼、未被調用的代碼