本節為大家講述app的專項測試——客戶端性能測試。這個我也做了蠻久的了。在這里修改了一下本篇隨筆。
首先我們了解一下什么是客戶端的性能測試。性能測試相比大家都已經耳熟能詳了，這個app的客戶端性能測試估計還是有部分同學不甚了解。
客戶端性能測試，主要就是針對app在設備上運行時的內存、CPU、GPU、流量、耗電等進行一系列的測試。主要目的就是為了提升產品的競爭力，同時也可以檢測出app的內存泄漏、優化點等問題。當然了，這只是我的個人理解了。
確定測試的介入時機，這個我一般是在上線驗收測試之前進行的。倒不是說我這個時機就是對的，實在是資源匱乏，人手不足，只有我一個人進行測試，我只能排在這個時間段進行測試。因為在很多公司，實際上這項測試都只是走走過場，並沒有發揮它實際的作用。
我覺得真正的介入時機應該實在開始執行測試的時候，與功能測試並行。因為優化是個漫長的過程，所以越早介入越好，首先能夠更加完善的針對這些目標進行測試，其次也能夠給予開發人員充足的時間進行優化。
然后就是我們的測試范圍，這個測試范圍呢，我個人覺得主要還是需要針對產品的核心功能進行。每個產品都有自己的核心功能，用戶使用的最頻繁的，與用戶交互最多的功能模塊。
那么我們要檢測哪些數據呢？又要如何去監測呢？
我們要檢測的數據如下：
Ø內存占用
Ø CPU占用
Ø電量消耗
Ø流量消耗
Ø幀數
使用工具
說到工具，現在工具有很多，大部分還是會使用， emmagee和 GT，還有 Itest等一些工具去監測產品在真機上運行時的各項數據。當然，還有一些是程序嵌入的可視化插件去監測。雖然這些監測的工具，所得到的數據並不是那么精確，但是我們還是能夠通過多次對比，使誤差最小化，從而得出結論。
不過目前筆者還是習慣使用開發工具去監測這些數據，感覺會比第三方的工具稍微精確一點。安卓的話就用 Android Studio，iOS就用 Xcode。通常監測時長為 2小時左右。
我們來看一下 Android Studio和 Xcode的監測的數據截圖
Android Studio
這里並不是 CPU、GPU、內存、網絡一起顯示的，而是分開顯示在不同的欄，需要自己去點擊進行選擇查看的。它所有的東西都是呈現為這種走勢圖的看起來很清晰。
Xcode
相比較而言，這里就是集中在一起顯示所有的數據了，不過如果看那種走勢圖的話，也是分開的哦。
結果分析
和服務端的性能測試一樣，客戶端的性能測試的重點同樣是結果的數據分析。
在測試的時候，根據每個操作，每個場景，對應的數據進行深入的分析。我這個操作引發的數據變化，為什么會這樣變化？這樣的數據變化會不會存在什么隱患？如果我是用戶，這個點這樣我會是什么感覺？這些數據，會對用戶造成什么影響，然后還要根據用戶在使用產品時的行為，進行分析，持續進行優化。
可能在大多數的公司都對這個屬於一個過場式的東西，筆者自己也很少深入分析過這一塊兒。希望有經驗的同學，能夠分享出來大家一起學習哈。
測試的過程中，可能會遇到一些數據的異常，那么我們就需要去分析出現這些異常的原因了。我曾經遇到過，CPU的占用，一下子飆升甚至超過了 100%。如下圖：
那么為什么會出現這種情況呢？我當時請教了大企鵝的測試朋友。他給出的結論是，出現這種情況只有兩種原因。其中一個我記不太清楚了，但是我當時的分析結果是因為FPS的卡頓造成的。由於 FPS的卡頓，導致進程短時間內出現卡死的現象，CPU占用會瞬間飆升。
好的，現在我們來說說優化的問題。我所接觸到，了解的優化的方法在這里分享給大家：
資源壓縮：圖片，配置文件等，進行壓縮，盡量刪除一些不必要的文件。減少安裝包包體大小。
分包：由於整包的包體太大，采用分包的方法，使用動態加載的方式，讓玩家在初次下載的時候，不會因為看到包體內存望而卻步。當然也有缺點，個人感覺缺點就是，動態加載的時候，會有點卡卡的。
當然了，上面的兩種方法都是對安裝包的優化方式。
還有包括網絡協議的選擇，連接方式的選擇（長連接/短連接），協議和連接方式的選擇會直接的影響到我們產品的流量的消耗以及響應時間。
筆者目前接觸到的也就是這么多了，歡迎大家留言討論。不過我感覺，通過客戶端的性能測試，應該也是可以去做代碼的優化的，當然這只是一個思路，以后有機會再向各位分享。