IOS性能優(yōu)化(多線程及GPU)(一)

IOS性能優(yōu)化(多線程及GPU)

  • 性能優(yōu)化相關知識鏈接

前言:

說到性能優(yōu)化,這個話題挺廣的,有的需要優(yōu)化tableview,有的需要優(yōu)化數(shù)據(jù)庫,有的是設計不合理導致重復計算等,這篇文章盡量從優(yōu)化思路的方向來講解,畢竟思路才是最靈活的應對方式,以不變應萬變,在特定的項目中,能通過這種優(yōu)化的思路去找到優(yōu)化的點,并針對這個點進行深入理解,做到有針對性的最優(yōu)的優(yōu)化效果,具體到某一個點的優(yōu)化,涉及到的面太廣,無法面面俱到。

  • 性能優(yōu)化時機:功能或模塊開發(fā)完成時

這點非常重要,那我們在開發(fā)過程中能做些什么對性能有好處的事情呢?
做功能時盡量做到單一職責原則,減少大函數(shù),大類出現(xiàn),這里舉個例子,有的人會喜歡把所有的布局全部寫道viewdidload函數(shù)中,導致viewdidload函數(shù)超級大,幾百行,或者把布局及邏輯都寫到一viewcontroller類里頭,導致這個類代碼上千行,這樣都是不可取的,不利于日后重構,維護,修改。
優(yōu)化則放到功能或模塊開發(fā)完以后再去做,往往能事半功倍。

  • 優(yōu)化哪一部分:二八原則,通過工具或測試用例分析性能,找出性能瓶頸所在的模塊,越精確越好。

二八原則在很多地方都應用廣泛,同樣也適用于我們性能優(yōu)化的時候,為什么會出現(xiàn)這樣的情況呢?
因為一個項目中大部分的代碼并不是常用的,不會經(jīng)常被執(zhí)行到,例如出錯處理,這些代碼有可能幾天都難得執(zhí)行一次,而有那么一小部分代碼,則每時每刻都在不停的運行,例如主界面刷新,聊天消息,直播消息,這些高頻代碼,每一分鐘執(zhí)行的次數(shù),能相當于低頻代碼(出錯處理)執(zhí)行次數(shù)的幾百上千倍。
那么如果是你,你會選擇把有限的人力用來優(yōu)化哪一部分呢?

  • 常用的性能優(yōu)化方法

  1. 更高效的算法,例如使用有針對性的優(yōu)化算法代替通用算法(autolayout布局).
    2.減少問題規(guī)模,減少計算量,對象生成數(shù),使用緩存。
    3.以時間換空間或者以空間換時間
    5.負載均衡
    6.司機應該去開車,而不是去炒菜。GPU精于浮點型計算,繪圖,渲染,CPU精于通用計算,如布局計算。

暫時想到的就這么多,也許還有更多的方式,期待補充。

GCD的使用

說到線程優(yōu)化,首先我們來了解一下ios中的一種常用多線程方式,也許我們很多人經(jīng)常用到,但是卻只緣身在此山中不識廬山真面目,下面讓我們來看看GCD能做什么?

串行隊列 Serial Dispatch Queue


并行隊列 Concurrent Dispatch Queue

阻斷

等待

整體思路

  • 橫向優(yōu)化:多線程優(yōu)化

主線程資源有限,不可在主線程中插入太多任務。

同理,單個線程的計算資源也是有限的,所以需要負載均衡。

  • 縱向優(yōu)化:時間片優(yōu)化

減少有限時間內(nèi)的工作,拆分成多個子任務在多個有限時間內(nèi)去完成。
一個runloop間隔內(nèi),不建議做超過一個runloop的操作。

多線程與任務

由上圖可以看出,主線程只有一個,其他線程則有多個,所以在橫向優(yōu)化的時候要盡量把非UI任務放到其他線程。
同時在縱向可以看出單位時間內(nèi)(t2-t1),線程能完成的任務是有限的,因此我們優(yōu)化的時候要盡量做到任務在時間上均勻的交個線程去執(zhí)行,防止某一時段內(nèi)主線程中任務過多,出現(xiàn)抖動(卡頓)。

  • 其他可能造成性能問題的點
  1. 圖片圓角觸發(fā)渲染
  2. 背景透明會造成渲染更加復雜,也更加耗性能。
  3. 復雜布局,需要考慮性能的,不建議使用autolayout

因為autolayout最終還是要轉換為絕對位置布局,轉換的過程有興趣的可以去找找資料(多項式求解),當關聯(lián)的view比較多的時候,這個求解的過程就會非常耗時,也許你要說自己寫也是求解的過程,難道蘋果做不到比我們自己更加有效率?

蘋果的autolayout真的沒有我們自己寫的有效率!因為autolayout做的是一套針對所有布局情況的算法,而我們要寫的只是針對當前情況的算法,量級不一樣,問題的復雜度也就不一樣,這也就是為什么說autolayout可能性能不好的原因。

  1. 緩存,減少重復創(chuàng)建

如多圖片展示時,UIImage的生成,事先緩存到內(nèi)存中

  1. 計算,計算結果緩存,減少計算任務

例如tableview的行高計算,尤其是在圖文混排的時候。

  1. 減少不必要的界面刷新,控制刷新頻率

  2. 線程負載均衡,減輕主線程任務

  3. 合理使用GPU,防止掉幀

  4. 開源FPS工具

通過CADisplayerLink來實現(xiàn),CADisplayerLink是一個跟屏幕刷新頻率一致的定時器。默認一秒60次。

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

  • Android 自定義View的各種姿勢1 Activity的顯示之ViewRootImpl詳解 Activity...
    passiontim閱讀 179,023評論 25 709
  • 發(fā)現(xiàn) 關注 消息 iOS 第三方庫、插件、知名博客總結 作者大灰狼的小綿羊哥哥關注 2017.06.26 09:4...
    肇東周閱讀 15,262評論 4 61
  • 這是轉載我個人博客大馬人文少爺系列:boonthemalaysian.wordpress.com的文章,這將是一個...
    矮小紅閱讀 567評論 0 1
  • 初到日本留學的第一年,一次,在田中老師的組織下,留學生們一起去神戶旅行。 當時有十多個中國留學生都參加了,可是由于...
    阿李ally閱讀 433評論 3 3
  • 不知道從何時開始,有些事我不再去深思,未來也不在去琢磨,有些事本來就是一團亂麻,未來也總是模糊不清。不如束之高閣。
    依然小樓閱讀 237評論 0 0

友情鏈接更多精彩內(nèi)容