為什麼要做效能優化

首先引用一下 High performance iOS Apps 這本書中的一段統計資料：

Consider the following statistics:

• 79% of users retry an app only once or twice if it failed to work the first time.
• 25% of users abandon an app if it does not load in 3 seconds.
• 31% of users will tell others about their bad experience

翻譯過來的意思就是：

• 應用首次出錯後，79%的使用者只會再重試一兩次
• 當應用啟動時間超過3秒時，25%的使用者會放棄使用該應用
• 31%的使用者會將糟糕的體驗告知他人

從上面的資料統計可以看出，App效能對於應用的重要性，App能否被使用者所認可不僅僅取決於其功能，還取決於當與使用者互動時，應用能否提供流暢的體驗。

從某一個角度來看，是因為你的APP是可替代的，我們可以從App Store找到大量的功能相似的替代品，為什麼使用者在功能相同的情況下會堅持使用你開發的這一款，兩個原因：你的APP在功能上無可替代，或者是極少故障且效能格外出眾

App效能會受很多因素影響，這些因素包括記憶體消耗，網路請求效率，使用者介面的流暢性，使用者操作的響應速度。所以我們對效能的描述有一個量化的過程，我們需要先概述不同型別的效能特徵，然後再對它們進行測量。

效能的衡量標準是什麼

從使用者使用的角度來說

一個好的移動應用應該要具備以下三個特點

• 可用性
• 高效能
• 穩定性

可用性衡量使用者如何與你的移動應用程式互動。如果他們無法操作你的應用程式，如很多功能無法使用，點選介面無響應，滑動頁面時卡頓乃至奔潰，這些情況，使用者很大可能會將你的APP從移動設別上刪除。

高效能，這個其實是使用者感知最深的一塊，這裡包括幾個小的方面，如使用者介面響應效率，網路請求效率，使用者互動體驗。

• 使用者介面響應效率：根據 Dimensional Research 的調查，49％的使用者希望應用程式在2秒或更短的時間內做出響應，因此檢查應用程式的啟動和UI效能對於應用程式的成功至關重要。模擬不同型別的環境，以確認應用程式快速，順利地響應使用者的命令。
• 網路請求效率：如果應用程式在理想的網路模擬中表現良好，那是非常棒的，但你的應用程式也需要在不太理想的環境中執行，在低頻寬，延遲高的不可靠網路環境下，也需要有一套機制來保證資料的快速展示，這裡可以使用快取，也可以併發請求提供提高響應效率。
• 使用者互動體驗：如果使用者在滑動列表時感覺到卡頓，點選按鈕時無響應，開啟某個頁面速度很慢，就會被使用者打上 Low performance的標籤，從而尋找同型別同功能體驗更佳的APP，這個其實是效能優化的核心。

穩定性意味著它具有流暢，不間斷的體驗，不會出現錯誤訊息或使用者崩潰。如果應用程式一直收到錯誤訊息的彈窗提示或者永無止境的載入螢幕，如果使用者開啟應用程式之前一直奔潰，如果使用者使用應用程式幾個小時之後發現電池是紅色的，絕大部分使用者會停止使用該應用程式。

從技術的角度來說

我們可以把效能量化成一個個可測量的效能指標，下面我將描述我對於效能量化的一些評判標準：

1. 記憶體

應用程式記憶體峰值取決與系統的硬體配置，佔用過高的記憶體會導致後臺應用被強制關閉，同時還要確保沒有記憶體洩漏，隨時間流逝持續增長的記憶體消耗意味著，應用程式可能會因為記憶體不足的異常而奔潰

2. 電量消耗

電量消耗過大一般情況下會伴隨著裝置發燙，電量消耗是一個涉及面很廣的場景，它不僅僅與計算CPU週期有關，還包括高效地使用硬體。除了要實現電量消耗最小化，還要確保不會影響使用者體驗。

3. 初始化時間

應用在啟動時應執行剛好夠用的任務以完成初始化，從而滿足使用者的使用需求。執行這些任務消耗的時間就是應用的初始化時間。啟動時間會直接影響使用者對應用程式的感官，秒開的APP一般意義上來說都是使用者喜歡的。

4. 執行速度

當觸發了某個操作，使用者總是希望它可以儘快地工作。一切必要的處理都應該在儘可能短的時間內完成。我們常用的方式是使用空間換時間，儘可能的快速響應使用者的操作。

5. 響應速度

每個應用都應該快速地響應使用者互動。在應用中所做的一切優化和權衡最終都應該體現在響應速度上。

6. 本地儲存

使用者都希望能夠在無網路或者裝置離線的情況下還可以瀏覽上次的內容，開發人員應該對本地儲存的使用有所規劃，以便應用具備離線瀏覽的能力。同時也需要提供一個清除物理儲存空間與記憶體快取空間的選項，物理儲存空間佔用過多，會使使用者頻繁的解除安裝這些應用來回收本地儲存。記憶體消耗過多，也會導致應用被系統殺死，所以提供一個清理快取的選項是很有必要的。

7. 網路請求

移動裝置會在不同的網路環境下使用，為了確保能夠提供最好的使用者體驗，你的應用應該適用於各種網路條件。而網路請求的響應速度會直接影響使用者體驗，如何做DNS優化，連線優化，弱網優化，是我們在優化過程中需要時刻關注的點。

8. 使用者介面流暢度

這個主要是我們的列表檢視，FPS過低會給使用者一種卡頓感，這是一種很糟糕的體驗，優化我們的TableView,提高渲染效能，給使用者絲滑的體驗感，是我們在接下來的優化中要做的。

9. 奔潰

高效能的應用不僅應儘可能地避免奔潰，還應該在奔潰發生時優雅地恢復，尤其是在進行某個操作的過程中發生奔潰時。奔潰後的自我修復方案與熱更新方案可以幫到你。

10. 安全

安全對移動應用來說是最重要的，因為敏感資訊會在應用程式間共享，因此對通訊資料與本地共享資料進行加密就非常重要了。但是加密過程需要更多的計算會儲存空間，但是這與最大化執行速度，最小化記憶體使用的目標相沖突。因此，我們需要在安全和其它因素之間進行權衡。

為什麼要寫效能優化系列文章

優化不要做的太早，效能是後來才會考慮的事情，從某種程度上來看，我認同這種觀點，畢竟最重要的是先完成功能需求。但是如果你在開發初期就已經有一套自己的優化方案與思想，你在開發過程中就可以使用最優化的程式碼與策略進行開發，優化與開發同時進行，開發即優化，我覺得這是一種很不錯的方式，同時也會大大減輕後期優化的工作量。

寫優化系列的文章是想讓自己走的更深一點，將自己理解的優化方案丟擲來供大家參考，這個過程中會出現各種不同優化思想之間的碰撞，這才是最有趣的，既提升了自己，又方便了大家，何樂而不為~

效能優化系列文章規劃

效能優化系列文章，會從我們平常開發的各個點出發給出優化方案與建議，每個點都會最終落地成程式碼，或者第三方工具，不做標題黨，每個優化方案都是本人經過測試，對比，量化之後的成果，在這個過程中也希望可以收穫大家的一些優化方案與思想，共同進步。

關於更博的規劃，我目前的效能優化篇博文目錄如下：

大概 12到 15篇文章，預計在7月中旬完成所有效能優化更博計劃，中間會穿插一些其它非效能優化篇的博文，希望各位看官能喜歡~