iOS-APP性能優化的那些事

前言

本人在這家公司已經三年多了，這款三年多我一直在作的APP也爛熟於心，APP也0到1到目前的500萬的用戶量；對於APP的功能來講也是比較全面的，用到的技術知識點也比較多吧，APP的優化也是一直在作的事情，並且APP性能的優化也不是一朝一夕的事情，在此離別之際，我將詳細說明講解一下我在三年裏對APP性能優化方面作過的一些事，你們仁者見仁智者見智，也歡迎你們進羣提供寶貴的意見和建議！

這裏我主要講性能方面的優化，代碼方面的優化或者說API包方面的優化請看個人另外一篇博文：

👉 iOS-APP包的瘦身之旅（從116M到如今的36M的減肥之路）👈

基礎優化

使用ARC，如今的iOS開發你們用的都是ARC，幾乎沒有人再去使用MRC了，使用ARC的好處就是不用再時時刻刻注意要釋放建立的對象了；避免使用xib或者storyboard。

這裏說一下xib和sb的缺點吧，以下：

1.佔用API包比較大；

2.致使APP啓動時間比較耗時，由於在APP啓動main()之前須要加載他們；

3.加載速度比較慢；

4.後期的版本更新迭代維護時間成本比較高；

5.多人開發容易引發衝突.

列表圖片優化

列表不論在哪個APP中是使用最爲普遍的一款控件了，在個人APP中也不例外，咱們的APP只要功能列表相似於微信的朋友圈，圖片有0~9張的形式還能夠是視頻文件，以下圖：

先說一說圖片吧，若是一個列表都是9張圖片，列表在加載和滑動的時候會耗用過多的內存；我在這裏是把圖片這一塊單獨抽出來作一個圖片資源的封裝，而後根據建立的圖片容器（UIImageView）的大小加載縮略圖，咱們公司的APP存儲用的是七牛雲存儲，因此在獲取圖片資源的時候，只須要設置對應的字段就能夠拿到縮略圖了，點擊的查看大圖的時候才查看原圖；

再說說視頻，視頻的處理邏輯和圖片差很少，這裏在CELL上咱們使用一個UIImageView來替代視頻播放器，能夠去出視頻的第一幀做爲封面，點擊圖片的時候才調用咱們封裝好的視頻播放組件。

複用機制

說道複用，咱們可能經常使用的有CELL的複用，其實咱們也能夠本身寫咱們的服用，就好比上圖中的列表，咱們通常採用的思路就是在主控制器上添加一個UIScrollView,再根據有多少個小標題類型建立多少個子控制器，接着把子控制器添加到主控制器的childViewControllers中，最後把子控制器的視圖添加到UIScrollView上，有沒有更節省內存空間的作法呢？？？

固然有的，咱們能夠只建立5個控制器而後丟到咱們的可重用數組中，根據每次滑動去加載不一樣的緩存數據；

還好比我在直播間建立刷禮物的視圖動畫的時候，由於最多隻能顯示三條，那麼我只會建立三個視圖，當有大於三條的禮物信息過來的時候也只會建立三個視圖，而後丟進個人可重用數組裏面，每一個視圖動畫完成之後才從新複製Model，以下圖左下角的禮物動畫最多三個，最少沒有：

就如上面所說，在項目中咱們能夠在不少地方建立屬於咱們本身的重用機制！

離屏渲染

在開發中，咱們經常使用有圓角處理、陰影、遮罩等等；先說說圓角優化吧，咱們通常設置圓角的方式以下：

view.layer.cornerRadius = 10;
view.layer.masksToBounds = YES;
複製代碼

這樣處理的渲染機制是GPU在當前屏幕緩衝區外新開闢一個渲染緩衝區進行工做，也就是離屏渲染，這會給咱們帶來額外的性能損耗，若是這樣的圓角操做達到必定數量，會觸發緩衝區的頻繁合併和上下文的的頻繁切換，性能的代價會宏觀地表如今用戶體驗上——掉幀。

優化方案：

a.能夠作一個透明的png圖片蓋在上面；

b.使用貝塞爾曲線UIBezierPath和Core Graphics框架畫出一個圓角；

c.使用CAShapeLayer和UIBezierPath設置圓角；

d.也能夠將圖片的處理放在服務端（好比：七牛雲儲存就能夠設置圖片的圓角）;

e.儘可能把view設置成不透明的。

說明：離屏渲染還能夠作不少東西，具體的能夠自行查找！

懶加載

這裏的懶加載主要說的是懶加載思想，能夠懶加載的類型有不少，固然好處有不少，最主要的是能夠節省內存資源；

重大開銷對象

咱們在APP使用過程當中會用到不少重大開銷對象（好比NSDateFormatter和 NSCalendar），如咱們在列表須要計算用戶年齡的時候會常常用到NSDateFormatter，還有一些時間的格式化輸出，或者在網絡請求的時候須要傳一些時間戳，因此咱們能夠把NSDateFormatter放在單利裏面，這樣就不用常常建立了，其餘的也是一樣的道理。

還有就是，像年齡生日什麼的最好不要由前端APP來計算，最好放在服務器上，由服務端計算好而後再傳給咱們。

內存警告

若是程序在運行過程當中發生了內存警告（didReceiveMemoryWarning），咱們須要快速應急處理一下，不要用不了多久APP就會被殺死掉，所在在收到內存警告主要思路就是想着去清理棧上的東西，之後咱們能夠作如下幾點：

a.清理不須要的已經建立的對象，不管是試圖仍是工具類；

b.釋放單利裏面不須要的對象，好比上文提升過得重大開銷對象；

c.若是有正在下載的任務，取消或者暫停所有任務；

d.若是使用了SDWebImage，能夠清理一下緩存clearMemory；

主線程流暢

不要阻塞主線程，要保證主線程的流程性；咱們不要把一些重大開銷對象放到主線程裏面，咱們能夠建立子線程去處理這些事情；好比多個網絡請求結束一塊兒刷新UI、多個動畫效果、數據的讀寫操做等等；

數據緩存

作緩存這個事情，一方面減少內存的小號，還有很重要的一方面就是優化用戶體驗；能夠作緩存的東西不少，咱們能夠對數據接口進行緩存，還能夠對WebView進行緩存，還有圖片緩存、高度緩存等等；

在這裏不得不說一下，數據存儲了；咱們在作緩存的時候選擇正確合適的存儲方式也很難重要，固然你們也能夠根據項目的實際需求來選擇存儲，咱們公司的APP本地存儲我選擇的是SQLite，管理類是我基於FMDB的又一次封裝，相信請參考：

👉《iOS-基於FMDB的操做封裝，模型對象的增刪改查》👈

網絡API優化

這個優化不僅僅需是前端小夥伴的事，還須要後端開發人員的配合，避免一些沒必要要數據的返回，更要避免在APP端處理或者計算太多東西，好比年齡、星座的計算；即便後端的小夥伴把一些沒必要要的數據返回了，咱們在建立數據模型Model的時候能夠選擇不去接收！

PS：這裏我須要吐槽一下，之前公司有個java後端，返回的數據所有是一個表的實體類，管你有用沒用，直接一股腦的全給你，本身去計算和本身去查找，那真叫一個心累啊，因此一個優秀的API開發工程師也是一個很是重要的緣由！

自動釋放池

自動釋放池（autoreleasepool）在MRC的時代真是用的很是多，可是如今的項目都是ARC，自動釋放池用的也就比較少了，由於有系統幫咱們監管，可是若是咱們一個頁面建立了太多的類或者對象，若是等頁面銷燬的時候由系通通一釋放不免會出現一個峯值影響總體性能，這時候咱們就能夠考慮使用autoreleasepool了，避免峯值的出現！👏

APP啓動優化

在AppDelegate裏面咱們會寫一些不少東西，你寫的東西越多越影響APP的冷啓動時間就會越長，所以咱們須要對AppDelegate進行減負，具體如何減負你們能夠根據各自項目的實際狀況，第一能夠刪除一些不是必須的東西；第二能夠把一些東西寫在別的地方（如RootViewController），我在APP的RootViewController寫的東西好比IM聊天的配置初始化登陸，一些未處理的任務，還有一些版本的堅持和緩存的清理等等！

結束語

原文地址：zfj1128.blog.csdn.net/article/det… 歡迎各位大神補充和糾正！

歡迎你們進羣交流：365152048