微信讀書 iOS 性能優化總結

發表于?2016-05-03?? | ??hypo?? | ??2 Comments

微信讀書作為一款閱讀類的新產品，目前還處于快速迭代，不斷嘗試的過程中，性能問題也在業務的不斷累積中逐漸體現出來。最近的 1.3.0 版本發布后，關于性能問題的用戶反饋逐漸增多，為此，團隊開始做一些針對性的性能問題優化。本文將從發現問題、解決問題和預防問題三個方面進行總結。

如何發現性能問題

不同于一般的 bug，性能問題因為并沒有統一的標準，而且與用戶的機器環境相關性較大，所以往往是在產品上線后才被發現，也導致解決問題的周期很長。微信讀書 1.3.0 版本之前，性能問題基本都來自于用戶反饋（包括測試人員），受限于測試時間和用戶反饋的積極性，性能問題往往到了比較嚴重的程度，開發人員才真正發現問題。

但是，移動應用要保證良好的用戶體驗，產品在性能方面的表現極其重要。為了盡可能早、盡可能全面地收集產品的性能問題，就避免不了對產品做性能監控。我們主要從兩個維度進行了監控：

業務性能監控，是指在App本地，業務的開始和結束處打點上報，然后后臺統計達到監控目的；

卡頓監控。卡頓監控的實現一般有兩種方案：

（1）主線程卡頓監控。通過子線程監測主線程的 runLoop，判斷兩個狀態區域之間的耗時是否達到一定閾值。具體原理和實現，這篇文章介紹得比較詳細。

（2）FPS監控。要保持流暢的UI交互，App 刷新率應該當努力保持在 60fps。監控實現原理比較簡單，通過記錄兩次刷新時間間隔，就可以計算出當前的 FPS。

但是，在實際應用過程我們發現，無論是主線程監控，還是 FPS 監控，抖動都比較大。因此，微信團隊提出了一套綜合的判斷方法，結合了主線程監控、FPS監控，以及CPU使用率等指標，作為判斷卡頓的標準。

微信讀書接入了RDM(bugly)的卡頓監控(也是基于微信團隊的卡頓標準)，通過下發配置，對現網用戶進行抽樣檢測，并上報卡頓的堆棧信息。這對于我們掌握現網用戶的卡頓狀況起到了非常大的幫助。

性能問題的解決方法

產生性能問題的原因多種多樣，因此解決的辦法也不盡相同，比較常用的大概有以下幾種：

1.優化業務流程

性能優化看似高深，真正落到實處才會發現，最大的坑往往都隱藏在于業務不斷累積和頻繁變更之處。優化業務流程就是在滿足需求的同時，提出更加高效優雅的解決方案，從根本上解決問題。從實踐來看，這種方法解決問題是最徹底的，但通常也是難度最大的。微信讀書在優化閱讀中各種操作（如，書簽、劃想、想法等）性能時，就是從業務流程的角度來進行優化。如下圖：

2.合理的線程分配

由于 GCD 實在太方便了，如果不加控制，大部分需要拋到子線程操作都會被直接加到 global 隊列，這樣會導致兩個問題，1.開的子線程越來越多，線程的開銷逐漸明顯，因為開啟線程需要占用一定的內存空間（默認的情況下，主線程占1M,子線程占用512KB）。2.多線程情況下，網絡回調的時序問題，導致數據處理錯亂，而且不容易發現。為此，我們項目定了一些基本原則。

• UI 操作和 DataSource 的操作一定在主線程。
• DB 操作、日志記錄、網絡回調都在各自的固定線程。
• 不同業務，可以通過創建隊列保證數據一致性。例如，想法列表的數據加載、書籍章節下載、書架加載等。

合理的線程分配，最終目的就是保證主線程盡量少的處理非UI操作，同時控制整個App的子線程數量在合理的范圍內。

3.預處理和延時加載

預處理，是將初次顯示需要耗費大量線程時間的操作，提前放到后臺線程進行計算，再將結果數據拿來顯示。

延時加載，是指首先加載當前必須的可視內容，在稍后一段時間內或特定事件時，再觸發其他內容的加載。這種方式可以很有效的提升界面繪制速度，使體驗更加流暢。（UITableView 就是最典型的例子）

這兩種方法都是在資源比較緊張的情況下，優先處理馬上要用到的數據，同時盡可能提前加載即將要用到的數據。在微信讀書中閱讀的排版是優先級最高的，所在在閱讀過程中會預處理下一頁、下一章的排版，同時可能會延時加載閱讀相關的其它數據（如想法、劃線、書簽等）。

4.緩存

cache可能是所有性能優化中最常用的手段，但也是我們極不推薦的手段。cache建立的成本低，見效快，但是帶來維護的成本卻很高。如果一定要用，也請謹慎使用，并注意以下幾點：

• 并發訪問 cache 時，數據一致性問題。
• cache 線程安全問題，防止一邊修改一邊遍歷的 crash。
• cache 查找時性能問題。
• cache 的釋放與重建，避免占用空間無限擴大，同時釋放的粒度也要依實際需求而定。

5.使用正確的API

使用正確的 API，是指在滿足業務的同時，能夠選擇性能更優的API。

• 選擇合適的容器;
• 了解?imageNamed:?與?imageWithContentsOfFile:的差異(imageNamed:?適用于會重復加載的小圖片，因為系統會自動緩存加載的圖片，imageWithContentsOfFile:?僅加載圖片)
• 緩存?NSDateFormatter?的結果。
• 尋找?(NSDate *)dateFromString:(NSString )string?的替換品。

//#include <time.h> time_t t; struct tm tm; strptime([iso8601String cStringUsingEncoding:NSUTF8StringEncoding], "%Y-%m-%dT%H:%M:%S%z", &tm); tm.tm_isdst = -1; t = mktime(&tm); [NSDate dateWithTimeIntervalSince1970:t + [[NSTimeZone localTimeZone] secondsFromGMT]];

• 不要隨意使用?NSLog().

• 當試圖獲取磁盤中一個文件的屬性信息時，使用?[NSFileManager attributesOfItemAtPath:error:]?會浪費大量時間讀取可能根本不需要的附加屬性。這時可以使用?stat?代替?NSFileManager，直接獲取文件屬性：

#import <sys/stat.h> struct stat statbuf; const char *cpath = [filePath fileSystemRepresentation]; if (cpath && stat(cpath, &statbuf) == 0) {NSNumber *fileSize = [NSNumber numberWithUnsignedLongLong:statbuf.st_size];NSDate *modificationDate = [NSDate dateWithTimeIntervalSince1970:statbuf.st_mtime];NSDate *creationDate = [NSDate dateWithTimeIntervalSince1970:statbuf.st_ctime];// etc }

如何預防性能問題

大部分性能問題可以通過程序員經驗和能力的提升得以減少，但是因為團隊成員更新、業務累積，性能問題無法避免，如何在開發測試階段發現問題解決問題，是預防性能問題的關鍵。為此，我們開發了一些比較有意思的工具，用于發現各種性能問題。

1. 內存泄露檢測工具

MLeakFinder是團隊成員zepo在github開源的一款內存泄露檢測工具，具體原理和使用方法可以參見這篇文章。在此之前，內存泄露引起的性能問題是很難被察覺的，只有泄露到了相當嚴重的程度，然后通過Instrument工具，不斷嘗試才得以定位。MLeakFinder能在開發階段，把內存泄露問題暴露無遺，減少了很多潛在的性能問題。

2. FPS/SQL性能監測工具條

該工具條是在DEBUG模式下，以浮窗的形式，實時展示當前可能存在問題的FPS次數和執行時間較長的SQL語句個數，是團隊成員tower的杰作。FPS監測的原理并不復雜，前文也有介紹，雖然并不百分百準確，但非常實用，因為可以隨時查看FPS低于某個閾值時的堆棧信息，再結合當時的使用場景，開發人員使用起來非常便利，可以很快定位到引起卡頓的場景和原因。SQL語句的監測也非常實用，對于微信讀書，DB的讀寫速度是影響性能的瓶頸之一。因此在DEBUG階段，我們監測了每一條SQL語句的執行速度，一旦執行時間超出某個閾值，就會表現在工具條的數字上，點擊后可以進一步查詢到具體的SQL操作以及實際耗時。

這個工具幫助我們在開發階段發現了很多卡頓問題，尤其是一些不合理的SQL語句，例如：
在想法圏的優化過程中，利用這個工具，我們就發現想法圈第一次加載更多，執行的SQL語句耗時竟然達到了1000多毫秒。

_SELECT * FROM WRReview INNER JOIN WRUser ON WRReview.fromId = WRUser.vid WHERE WRReview.type & ? AND WRReview.createTime <= ? ORDER BY WRReview.createTime DESC , WRReview.itemId ASC LIMIT ?_

通過explain，可以發現這條SQL效率之低:

SEARCH TABLE WRReview SEARCH TABLE WRUser USING INTEGER PRIMARY KEY (rowid=?) USE TEMP B-TREE FOR ORDER BY

• 沒有建立合適的索引，導致WRReview全表掃描。
• 排序字段沒有索引，導致SQLite需要再一次B-TREE排序。
• 兩字段排序，性能更低。

優化：給WRReview的?fromId?createTime?兩個字段增加了索引，并去掉一個排序字段:

SELECT * FROM WRReview INNER JOIN WRUser ON WRReview.fromId = WRUser.vid WHERE WRReview.type & ? ORDER BY WRReview.createTime DESC LIMIT ?

Explain的結果：

SCAN TABLE WRReview USING INDEX WRReview_createTime SEARCH TABLE WRUser USING INTEGER PRIMARY KEY (rowid=?)

SQL執行時間直接降了一個數量級，到100毫秒左右。

3. UI / DataSource主線程檢測工具。

該工具是為了保證所有的UI的操作和 DataSource 操作一定是在主線程進行，同樣是由tower同學貢獻。實現原理是通過 hook UIView 的?-setNeedsLayout，-setNeedsDisplay，-setNeedsDisplayInRect?三個方法，確保它們都是在主線程執行。子線程操作UI可能會引起什么問題，蘋果說得并不清楚，實際開發中我們遇到幾種神奇的問題似乎都是跟這個有關。

• app 突然丟動畫，似乎 iOS 系統也有這個 bug。雖然沒有確切的證據，但使用這個工具，改完所有的問題后，bug 也好了(不止一次是這樣)。

• UI 操作偶爾響應特別慢，從代碼看沒有任何耗時操作，只是簡單的 push 某個 controller。

• 莫名的 crash，這當然是因為 UI 操作非線程安全引起的。

更多時候，子線程操作 UI 也并不一定會發生什么問題，也正因為不知道會發生什么，所以更需要我們警惕，這個工具替我們掃除了這些隱患。雖然，蘋果表示，現在部分的 UI 操作也已經是線程安全了，但畢竟大部分還不是。DataSource 的監測是因為我們業務定下的原則，保證列表 DataSource 的線程安全。

4. 排版引擎自動化檢測工具

排版引擎是微信讀書最核心的功能，排版引擎檢測工具原本是為了檢驗排版引擎改進過程中準確性，防止因為業務變更，而影響原來的排版特性。實現原理是結合自動化腳本和 App 本身的排版引擎，給書庫中的每一本書建立一個鏡像，鏡像的內容包括書籍的每一章每一頁的截圖，然后分析同一頁碼的兩個不同版本的圖片差異，就可以知道不同版本的排版引擎渲染效果。但是我發現，只要稍加改進，排版后記錄每個章節排版耗時，就可以知道每個版本變化后同一個章節的耗時變化，以此作為排版引擎的性能指標。這個工具保證了微信讀書，即使在快速迭代過程中也不會丟失閱讀的核心體驗。雖然這個工具無法在其它項目中復用，但是提醒了我們，可以通過自動化工具來保證產品最核心功能的體驗。

5. 書源檢測工具

微信讀書為了支持正版版權，目前書源完全依賴于后臺，不允許本地導入。書源的優劣的直接影響排版的效果和性能。為了解決了部分書籍無法打開或者亂碼的問題，我們借助了后臺同學的書源檢測工具。對線上所有 epub 書籍進行掃描，按照章節大小進行排序。對于章節內容特別大的書籍重點檢測，重新排版，解決了一批 epub 書籍無法打開的問題。同時針對章節內容亂碼的問題，對所有 txt 的書籍進行了一次全量掃描，發現了一些問題，但還無法準確找出所有亂碼的章節，這一點還在努力改善中。

優化成果

整體使用感受上，已經可以明顯區分兩個版本的性能差異，這一點也可以通過每天的用戶反饋數據中得到驗證。1.3.0 和 1.3.1分別發布一周后反饋的卡頓數從 10 個降到了 3 個，從總體反饋比例的 2.8% 降到 0.8%。

某些關鍵業務，耗時也有明顯改善。

極端案例的修復。超大的epub書籍已通過后臺進行拆分，解決了無法打開書籍的情況。

針對低端機型，去掉了某些動畫，交互更加流暢。

總結

通過上述介紹，我們可以看出，性能問題普遍存在，無可避免，與其花費大量時間，查找線上版本的性能問題，不如提高整體團隊成員性能優化意識，借助性能查找工具，將性能問題盡早暴露在開發階段，達到預防為主的效果。

轉自:?微信讀書 iOS 性能優化總結

總結

以上是生活随笔為你收集整理的微信读书 iOS 性能优化总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。