說實在的我是不想現在說太多，這樣我覺得我這個書寫的意義就不大了。索性不出版了...
我上周幫助公司也做了一下app的
性能測試，整個過程歷時一天半，當然僅僅是針對測試，燃燒了我大半小宇宙。
首先現在移動應用的性能測試一般分成三種測試的方向，或許說是找基線的方向： 1. 先對于競品進行測試，從而進行對比
2. 經過測試，團隊討論得出一個大家認可的數據，從而變成基線
3. 在系統，應用等限制中找到一個基線，打比方說比如某些應用的畫面需要60fps的幀率進行平滑的渲染等
而無論是哪種得到數據并非非常容易，性能測試往往與應用邏輯，架構，業務牢牢的綁定。
Android和ios的內存泄漏也許是很多人關心的一個方面。在此之前當然我們應該先進行靜態的代碼掃描，find bugs，lint，code Analysis等。內存泄漏其實并非一定有什么基線，在我看來每個不同類型的應用其基線可能都是不同的，然后內存泄漏現在常用的方法如下：
1. 對應用進行”Cause GC”操作，查看object data的走勢，如該數值持續上漲說明有內存泄漏的可能。
2. Android獲取hprof文件。其一，在進行壓測之后獲取hprof使用MAT進行分析。其二，可以在某些重要業務場景前后分別去Dump HPROF，從而對比前后某些對象是否有重復引用等
3. ios的話要請教中國ios之父了...我目前還是只是用instruments自帶的一些工具在業務場景中進行查看。
4. dumpsys也不失為一個比較簡單的方法，但是就是比較難定位問題在哪里
當然我之前也一直推崇的systemtrace以及gnxinfo也是很不錯的性能測試工具。其運用在自己要測試的場景中就能夠得出很精準的數據，包括應用的啟動，包括繪制函數方法的耗時等，報告如下：
其他也有電量，流量等，這類其實現在現成的測試app也有。我們自己要去寫個也不是什么難事，比如寫一個很傻的activity，然后啟動幾個監控的service就可以了。通過系統api都是能夠獲取到我們想要的數據的，當然
百度等公司還是會用萬用表來進行電量測試，我表示我肯定做不到。部門代碼如下：
當然我上周在做的時候，順便讓我們測試的同學把關鍵業務做了下，然后生成的code coverage報告也讓開發協助測試增加了很多有用的
測試用例。這也是我覺得真心不錯的一個發展方向。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters