iOS開發過程中 效能監控及優化

我在開發iOS的過程中，逐漸形成了一些對iOS效能優化的認識，準備總結出來。懇請各位斧正。

在我的眼中，app的效能就像是app執行開發中的貨幣。我們開發者就像一個組織者，手機本身的效能就是可以提供給我們的演出費用，手機版本就像舞臺。
出現了新的可以增加效能的技術的時候，我們就要想辦法多弄點錢；有些演員價錢過高，我們要考慮是否換個人；有的裝置過於陳久了，我們要考慮是否優化或者更換；為了得知哪些地方花的過多了，我們則需要想辦法去監控花錢的過程。效能優化到最後的結果，就彷彿在有限的資金支援下，給觀眾表演出一場精彩的、沒有失誤的戲劇。

優化有幾個關鍵點要記住

• 不要過早的優化
  一方面，現在iOS平臺的效能都普遍較好，如果花費過多的精力過早的優化，可能會影響當前的開發任務.

• 不要過度的優化
  我這裡舉一個我曾經犯過的錯誤。我曾經遇到過一個實現高精度倒數計時的任務，我在考察的過程中，發現了相對高精度的GCD倒數計時是使用select函式來實現的。我就比較“喪心病狂”的用select函式實現了一個倒數計時的單例，但是最後應用的時候發生了許多危險的多執行緒錯誤。事情到了最後還是乖乖的選擇了GCD作為我的高精度倒數計時實現方案。

• 重視多角度效能監控
  不言而喻，只有真正的面對到了真實發生的效能問題，我們才能針對性的做出優化，而不是浪費時間在並不重要的地方。

• 儘量減少效能監控影響
  我們在使用效能監控工具的時候，往往效能監控工具本身就會影響到效能。這就彷彿是一種“觀察者效應”。我們要減少這種可能危險。

• 平衡各種效能優化
  app的效能有很多種類。我們要明白，我們的目標是給觀眾表演出一場精彩的、沒有失誤的戲劇。但是在真正的場景中，由於很多客觀原因，比如說手機版本過老（舞臺太陳舊），手機效能不足（錢也少了），總是要做出各種各樣的權衡，捨棄到某些地方的金錢支援（優化），以達到整體演出的完整。

• 理解優化過程的內部底層實現機制
  假如你不知道app的啟動過程是分為main()之前和之後兩個過程，可能你一直優化mian()之後的部分，確收效甚微；假如你不知道一個view建立展示出來的過程，CPU，GPU，runloop在其中的作用，你很難做到如絲般順滑。假如比不知道在NSSet/NSDictionary中，底層實現了hash，你可能就無法選擇正確的集合去收集資料。

我們要優化那些方面

假設我們開發了一個app，我們需要優化方面？為了得知需要優化的方面，需要我們做那些監控？下面我們就簡單的說幾個，歡迎補充。 IOS,馬甲包,低要求,內容開發沒有限制,報酬豐厚,實力誠信 Q:782675105

1.啟動時間優化和監控
app的第一次開啟，冷啟動，熱啟動，app升級後啟動等等。都是可以優化的點。這裡我們一般著重優化第一種情況，一般而言，優化了首次啟動後，對後者都有優化效果，不過我們有時還是要針對業務場景進行相應的優化。
2.app包大小的優化
App size是一項很關鍵的指標，現在很多巨型應用超過100M的比比皆是，就舉阿里巴巴為例，它旗下的各種應用超過100M的應用超過了10款，其中淘寶更是達到了205M。在包大到一定程度之後只能通過WIFI下載，即使可以使用蜂窩網路下載，也會讓人十分心疼流量。我們這時候就要分析ipa包的大小。去除無用圖片，無用程式碼，更換圖片格式，檢查引用第三方庫，合併類似方法等等方法。
3.網路優化
合併介面，選擇合適的協議，優化 SSL 握手之前過程，優化 SSL 握手過程，優化 SSL 握手之後過程等等。
4.頁面開啟過程優化
我們從上一個頁面進入下一個頁面的時候，會經過轉場動畫、下載資料、繪製圖片等過程。為了讓使用者使用起來方便，我們需要對其中的每一步都進行優化。
5.資料讀寫優化
這裡針對的面很多，資料庫的讀寫，集合類的選擇和讀寫，都是屬於這一類的，
6.UI卡頓優化
這個實際上是種種卡頓的集合，也是相對而言內容最多的一部分，我們需要結合實際狀況來優化。
7.記憶體優化
避免記憶體爆炸，避免因記憶體過大被殺死，避免迴圈引用等等。
8.執行緒優化
這個算不算是優化我還有些疑慮，但是出於很多優化方案都要多執行緒的方式去解決。我就把它放到了這裡。這裡與其說是優化，更不如說是我們實際操作中需要注意的一些情況。比如說，UI的建立和重新整理一定要在主執行緒，DB 操作、日誌記錄、網路回撥都在各自的固定執行緒，合理的建立執行緒，並及時回收等等。
9.耗電優化
耗電的優化我們可以放到最後來說。想對而言，再解決了以上的優化之後，耗電往往也能得到優化。並且，這一項也是使用者不怎麼在乎的，我們可以放到最後來優化。

監控

對app的相關指標的監控和記錄至關重要，我把這分為三種：

1.開發中實時監控
我們在開發中往往寫入很多bug，在開發過程中直接報告我們的bug顯得至關重要。我之前為了解決這個這個方案，實現了一個懸浮在app最上層的一個可以滑動的小按鈕，實時展示FPS，並將記憶體洩露監控，卡頓監控，記憶體爆炸監控等等工具放入其中，在打包過程中再將其從工程中扔出即可。這樣當時我們在開發的過程中就可以隨時的進行修改，當然，這個本身也會帶來一些副作用，但是利遠遠大於弊。我接下來的工作就是準備將它開源出來。
2.日誌系統
有些線上發生的錯誤，比如說應用被殺死，應用卡頓，應用崩潰等等。我們需要一些工具來將其記錄下來併傳送給我們。我們可以選擇一些第三方應用，但是在可以的情況下，還是採用自己開發的工具為好。這裡我有一個慘痛的教訓：最好是採用mmap的方式儲存資料。這個我會在未來的文章中解釋為什麼如此讓我記憶深刻。
3.埋點
埋點相對而言更適合統計使用者操作等等。但是可能起到監控的作用。這裡我推薦採用AOP的方式來進行無痕埋點，減少對業務程式碼的侵入。

總結

隨著時間的推移，問題總是會被我們遇到的，也總是會遇到效能的平靜，我們需要想出辦法，開發出一些輔助工具來幫助我們定位、解決問題。

提個問題

現在有一個新活動頁面，頁面裡有個tableview，每個cell都有活動倒數計時。我們改從那些方面來優化，以達到點選進入頁面後的順滑。轉自：伯陽