最近公司的項目提及性能優化,我在對公司的項目進行優化時,發現了一系列的問題,在此,我在這里做一些簡單的總結,希望能對讀到它的人能夠有一些啟發。后面如果時間充足的話,我會對項目里做的一些優化逐步講解,當然基于我的個人能力的不足,可能有些不足,希望能對讀者有部分啟示作用。

1.適度優化

• 明確優化方向,避免盲目優化

我說的這問題是我在開發中明顯感覺到的問題,網上很多優化示例,當我需要對項目進行優化的時候,我會去翻看網上的優化示例,然后去模仿優化,但實際上最好具體問題具體分析,當你項目中出現了明顯的性能問題的時候再去尋找解決方法進行優化,這是我認為比較好的優化方式。大體原因是,大部分的優化任務實際上沒有能度量性能的工具去幫助你核實性能提升,而頻繁的修改項目會導致項目質量下降,嚴重還會導致項目出現線上崩潰率激增的問題,所以在進行項目前需要深入了解到底你所開發的項目需要哪些優化項,然后再去了解對應的優化方式。

• 開發架構問題

網上經常有人會說Native架構比混合開發要強，性能好不少等等問題,我一直覺得在一些修改比較頻繁的場景上,使用web開發是必然的道路,原生開發的成本確實較高。跨平臺的架構主要是可以減少多端開發的成本，使用一套代碼完成iOS和Android兩個平臺的開發,類似的Weex,flutter 的開發框架的愿景都很美好,但在實際使用過程中,個人覺得現階段并不比使用Native架構節省人力，其中會遇到許多已知的未知的坑，當然作為新的技術我們應該持開發的心態，但在使用時候也需要全面的評估，尤其作為一個可能有很長生命周期的應用，在使用非官方推薦的開發架構也好、開源庫也好，如果后期無人維護的話，自己團隊是不是有實力去接盤，如果不能，使用蘋果官方推薦的技術棧則更穩妥些。

• 開發架構的選擇

架構永遠都沒有最好,只有最合適的。
目前iOS開發中常用的架構有MVC 、MVVM、VIPER、MVP等。這些應用架構的材料非常多,具體可以在網上自行查看,但是希望再說一遍沒有最好的架構,只有項目最適合的,即使是MVC,也沒有過時這種說法,在對應的業務場景下,每個開發架構都有其獨特的適用之處。

• 組件化方案

對于一般的小型項目,不太推薦組件化,組件化方案,我嘗試過推進組件化,但是基于實際場景,大部分情況下只會增加成本,增加開發人力。在產品功能相對單一,開發人員數量不多的情況下,不但會增加學習成本,還會導致項目質量下降等問題。只有對于類似淘寶,抖音等比較大的超級App的時候,組件化的開發能夠保證不同團隊能夠獨立進行并發開發。

2.使用合適的工具進行優化

我們對程序進行優化,是希望能夠看到一些比較直觀的性能評測數據,不能夠僅憑主觀猜測,就說使用某些方案比較合理。

• 熟練掌握instruments

instruments 是Xcode 最強大的工具,常用的有Core Animation、Time Profiler、Leaks和Allocations,這些功能只要熟練掌握,就能快速分析到問題所在,然后再進行針對性的優化,能起到事半功倍的功效。

3.深入了解底層機制

更好的了解底層運行機制,才能有更良好的優化效果

4.建立優化體系

我們對項目進行優化不是一日兩日,需要長期對性能進行監控,希望都能建立一套持續優化的體系,
建立針對不同指標的自動化測試，引入關鍵性能指標上線準入制度等等。一定要建立體系,形成規范才能更好的進行持續優化,不會因為人員流失導致優化終止。

以上是我這次優化完成后的部分體會,可能比較粗糙,部分內容也是想到什么寫什么,望互相探討。