如何對APP性能進行監測並優化？有沒有工具推薦一下。

01-04

樓主想要進行的APP性能監測和優化指的是在APP伺服器面對高並發時暴露出的一些問題吧？

這裡羅列一些需要密切監測的核心指標：

1. PCU：最高同時在線人數。
2. TPS：美妙系統處理事務（通過、失敗以及停止）的數量，通過它可以確定系統在任何給定時刻的時間事務負載。

3. 響應時間：每一事務執行所用的平均時間，通過它可以分析測試場景運行期間應用系統的性能走向。
4. CPU：中央處理器。
5. 內存：內存儲器。
6. 磁碟IO：磁碟的讀寫包速率。
7. 網卡負載：網卡的進出帶寬，包量。

樓主還問到工具推薦，這裡推薦給一款雲端自動化性能測試工具，無需維護測試環境支持APP、遊戲、H5等主流測試場景。其功能包含並發測試、場景測試、負載測試、介面測試、容量測試、穩定性測試、壓力測試、性能調優。功能十分詳盡，相信能夠滿足樓主的監測及優化。

附上使用地址，伺服器性能測試工具：wetest.qq.com/gaps 目前工具免費開放中。

除了以上這些，APP本身的兼容性測試和客戶端性能也是至關重要，騰訊WeTest也有相對應的測試產品助力開發人員。其中標準兼容測試 - 騰訊WeTest 和客戶端性能測試 - 騰訊WeTest 樓主可以配合一起進行測試發掘潛在問題，同樣免費開放中。

之前看到了一篇文章，《25條拔高iOS App性能的技巧和訣竅》，覺得還比較實用，可以看一下。

入門級（這是些你一定會經常用在你app開發中的建議）

1. 用ARC管理內存
2. 在正確的地方使用reuseIdentifier
3. 儘可能使Views透明
4. 避免龐大的XIB
5. 不要block主線程
6. 在Image Views中調整圖片大小
7. 選擇正確的Collection
8. 打開gzip壓縮

中級（這些是你可能在一些相對複雜情況下可能用到的）

9. 重用和延遲載入Views
10. Cache, Cache, 還是Cache！
11. 權衡渲染方法
12. 處理內存警告
13. 重用大開銷的對象
14. 使用Sprite Sheets
15. 避免反覆處理數據
16. 選擇正確的數據格式
17. 正確地設定Background Images
18. 減少使用Web特性
19. 設定Shadow Path
20. 優化你的Table View
21. 選擇正確的數據存儲選項

進階級（這些建議只應該在你確信他們可以解決問題和得心應手的情況下採用）

22. 加速啟動時間
23. 使用Autorelease Pool
24. 選擇是否緩存圖片
25. 盡量避免日期格式轉換

App性能好，不是簡單指感覺運行速度快，而應該是指應用啟動快速、UI反饋響應及時、列表滾動操作流暢、內存使用合理，當然更不能隨隨便便Crash。

工程師開發應用時除了在設計上要避免性能「坑」的出現，在實際遇到「坑」時也要能很快定位原因所在。

定位性能問題原因當然不能靠猜，合理的方法是使用工具測量評估出投資回報最高的問題點，然後再加以優化。

如果要想分析和優化iOS app的性能，可以從啟動時間、用戶響應、內存、圖形動畫、文件和網路I/O等角度進行優化。

至於具體的工具，國內外都有免費版的工具，百度一下「移動應用+性能」等關鍵詞就知道了。

VS中對性能監控工具很強大，可以實機監視。

DDMS 內存分析和cpu使用分析 MAT 內存分析

分享幾個通用的優化移動應用性能的技巧：

1、減少客戶端到伺服器的HTTP請求數量，可以縮短頁面載入時間

2、將JavaScript和CSS打包成文件並在多個頁面之間共享，也是優化性能的好辦法

3、儘管瀏覽器緩存在移動應用上不那麼湊效，但可以用HTML5的網頁存儲技術替代

4、使用內嵌腳本資源，鏈接引用會極大地延長載入時間

5、壓縮或盡量減少界面資源，少佔帶寬，也能提高速度

6、根據屏幕尺寸裁剪圖像，不僅能減小圖片大小，還能提高處理速度

大晚上正好有點時間來回答一下這個問題，從三個方面來回答。

1、為什麼要關注性能問題？

現在APP處於一個「紅利期」，要想從中廝殺出來，簡直就是天方夜譚。那麼不能成功突圍，問題和瓶頸在哪裡？多數開發者會將原因歸結於產品設計、產品邏輯等有密切關係的環節，但反而會忽視一個盲區，就是性能問題。

之前看到過一組統計數據：

·
71%用戶希望在手機上打開網頁能同電腦上一樣快

·
5秒鐘被認為是用戶能忍受的最長響應時間

·
如果響應時間超過5秒，74%上網用戶和50%移動應用用戶會放棄

·
三分之一失望的用戶會轉向競爭對手的應用

因此可見性能的監測和優化對於用戶的留存是非常重要的。性能問題足以吞噬用戶，這相當於跟用戶說「再見」，而且可能是永久性流失。在移動互聯網注意力成本不斷提高的今天，試想，哪款應用能禁得起這樣的折騰？

性能優化技術，簡而言之，就是提高程序的性能，讓我們的應用更快，更少使用CPU資源，更少使用內存。驗證了那句話：「別人有的我們也有，而且比他們的要好要快。

2、如何才能提升APP性能？

1）首先，得了解APP性能有哪些問題。

應用性能表現是一個相當模糊的概念，出現的頻率與錯誤種類絕對超乎想像。如果面向5079個不同機型、1172種操作系統以及18家運營商分析，應用性能問題組合為5.79*1173*18=1億零700萬種。

那麼其中，最常見的性能問題有哪些？根據聽雲平台的監測數據統計發現，在這些應用性能問題組合中，有十種應用性能問題危害最大，是導致用戶流失的罪魁禍首，分別為：連接超時、閃退、卡頓、崩潰、黑白屏、網路劫持、交互性能差、CPU使用率問題、內存泄露、不良介面。

而每日由於十大應用性能問題所造成的用戶流失達活躍用戶的5%，其中Android系統每日用戶流失佔比61%，iOS佔比39%。

而在這些問題中，「連接超時」、「崩潰」和「CPU使用問題」是三大頭號殺手!

其中，網路錯誤是App關閉的首要問題，而在移動應用中網路錯誤數據比例報錯中最高的就是連接超時錯誤。想像一下當你花重金好不容易把你的App推廣到用戶手機上，而在用戶初次嘗試時發生連接超時無法正常使用，多數用戶會選擇再也不會打開你的應用第二次。

崩潰就不用再說了，APP崩潰就是用戶的崩潰。至於「CPU使用問題」，根據搜索數據，有275W條「手機過熱死機」的搜索結果。但是請不要把用戶的問題都歸結為手機電池。

事實上，CPU超載是殺死App的第三大殺手。CPU頻率設置過高時會導致過熱,過熱導致耗電更嚴重,CPU頻率設置過低導致手機滯後,應用處理緩慢同樣會導致耗電。更多時候，用戶解決CPU超載問題只能關閉甚至卸載App。

2）如何去解決這些性能問題？

我前面所說，如果面向5079個不同機型、1172種操作系統以及18家運營商分析，應用性能問題組合為5.79*1173*18=1億零700萬種。對於中小應用開發者來說，如果只是靠自己單薄的技術力量進行優化、而不依靠沒開放、公共的平台來支持的話，這幾乎無解。

針對移動開發者，行業里並不缺乏適配和測試平台,有很多，我就不一一列數了，但僅僅解決上線前的環節，並不能解決上線後應用性能的核心問題。這個環節缺位的話，就談不上應用性能的管理，用戶留存率低和流失現象就沒法根治。

那麼應用不能在上線後「裸奔」，應該首先從監測做起，可以用一些第三方平台提供的監測工具，實時監測出自己APP性能的問題，從而進行針對性優化。如果要推薦的話，國內比較火的第三方監測工具有基調網路公司的聽雲平台，他們監測的比較全面，而且又是永久免費的，只要部署兩行代碼即可查看數據，可以試試。

結尾的話：

可喜的是大家越來越重視性能問題，可期待的是由於目前關於性能優化的知識性文章還是很少，希望能在未來看到更多優秀的經驗分享。

最後用雷軍在7月22日小米發布會上說的話做結尾：「拋開性能問題談體驗都是耍流氓」，送給廣大開發者。

目前國內著名的應該是三家：博睿，聽雲，oneAPM。我們也用了其中一家，對於app性能監測和分析的確挺有幫助。

移動app的性能指標對用戶影響比較大的主要有以下幾個方面：

1，及時性：啟動時間/操作響應時間/內容載入時間

2，穩定性：啟動/操作/內容載入成功率

3，資源消耗：CPU/內存/流量

4，功耗：不同網路下運行時/待機耗電量

現在還沒有發現可以比較全面來支持檢測這些項目的工具。有些開源工具可以完成對android應用資源消耗、功耗檢測，如網易的emmagee（NetEase/Emmagee · GitHub）,騰訊的GT（GT Home）。這些工具是通過監控系統進程的資源消耗來獲取對應cpu，內存，流量電量等數據，然後生成數據文件輸出，動手能力強的話也可以直接把手機root了之後通過獲取系統日誌來對應用進程的資源消耗數據進行分析。不過功耗數據我們是通過功耗儀來接著手機來獲取的，數據來說相對更準確些（需要吐槽的是，現在可拆電池的手機越來越少了）。由於iOS系統的封閉性，所以在資源消耗和功耗上沒有什麼第三方應用可以做到監控（騰訊的GT說是支持iOS應用，其實是需要嵌入代碼，打包在應用裡面獲取數據，比較繁瑣）。諸如cpu，內存，功耗等數據可以通過xcode的提供的監控獲取。不過電量消耗顯示的是百分比，精度比較低。

穩定性的測試一般用monkey或者monkey runner比較多，針對某個功能業務流的的穩定性會編寫對應自動化腳本（robotium，appium)，長時間的去跑，來發現應用本身可能存在的問題。及時性，穩定性這些時間獲取也可以通過自動化腳本獲取操作完成時間，多次取平均值做為參考。

內容載入時間，載入成功率往往和後台系統相關，這方面要再深入需要結合性能測試工具（LR，jmeter）去對特定場景進行壓力測試，分析瓶頸，定位問題進行優化。

有時候在測試過程中單純獲取一個數據並不是最終的目的，需要考慮競品分析，結合多種工具來進行測試，進一步去發現定位問題，並提出優化建議。如流量監測時候，可以對比同類型產品，結合使用抓包工具來分析數據包大小，間隔時間，來分析流量消耗是否存在可以優化的空間。

暫時寫那麼多，之後想到什麼再補充吧。

可以用APP數據監測工具來實現。如99click的SiteApp運營優化系統，是一款最有深度的移動APP數據分析優化系統，幫助開發者、運營、營銷人員實時掌握用戶行為，透析產品動態，智能決策。

關注cn99click，了解產品詳情，還可以免費試用產品！

一個網友的回答，寫的不錯，希望能幫到你

一、提倡前端開發工程師在書寫xhtml的時候做到結構語義化。

結構中主要包括了head和body兩個部分，但是我們經常說的是結構語義化主要是body中的標籤，但是我在這裡還是簡單的說一下head，head中其實包括了一些對於我們seo很有用的一些東西，比如title,Description,Keywords,這些東西在蜘蛛抓取的時候都是有幫助的，當然，還有其他的一些，我在此就不一一說明了，比如設置緩存等一些其他的信息。

那麼body中的話，包括的標籤就很多了，我覺得作為一個合格的前端開發人員你應該去熟悉他們，比如div,span,h,ul,ol,dl,p等等這類的標籤的使用。應該非常合理，還有就是注意h標籤的斷層，及h1標籤的使用，這些都是非常重要的。

同時在我們的結構中不要出現style和onclick這樣的內聯的樣式和事件。希望大家能夠注意結構與表現、行為的分離。

（PS：標籤語義化的好處：1.有利於搜索引擎；2.結構清晰的HTML在團隊合作中的作用，就不必說了吧；3.有利於盲人屏幕閱讀器。至於如何做到標籤語義化，就看個人的理解了，這方面我也覺得模糊，跟個人的習慣估計也有一定的關係，總之鄒惠斌老師是認為我的標籤不語義的。）

二、css，js文件數量及大小的優化

那麼關於css、js的優化的話，一般情況下建議css和js採用外聯式。但是如果你的頁面內容比較多，設計師把整個效果做得比較花的話，恐怕css就非常多了，那麼這種情況下，你一定要把你的css規劃好，盡量的採用縮寫，這樣可以減少css文件的大小，那麼對css做相應的規劃也可以減少css的個數，減少http請求數，js同理。

（PS：減少重複性代碼，代碼重複利用，在這裡顯得特別重要）

三、背景圖片數量及大小的優化

當我們將設計師的設計稿還原成靜態頁面後，除非頁面所有的修飾全是色塊，內容全是文字，沒有圖片，如果不是這樣的話，那麼我們需要對圖片做優化處理。當然內容圖片我們是沒有辦法了，因為他是屬於內容部分的，一般情況是由於編輯處理，當然，我在還是有一個小小的建議，如果我們的網站中需要有內容圖片，希望編輯能夠將他們最優化以後，在進行上傳，一會兒告訴我的方法，下面我在說說，作為前端開發應該如何處理我們的修飾（背景）圖片。

由於我們的背景圖片數量比較多，這樣的話，會給伺服器帶來影響，增加了http請求數，我們是否有一種好的解決辦法呢？這個答案是肯定的，如果你是一個合格的前端開發，你應該清楚，在我們的css定義背景的時候，可以通過坐標來實現對背景進行定位的，既然如此，那麼我們可以將這些背景合併起來，這樣即可減少http請求數，同時，我們在背景整合的時候，也需要考慮圖片質量，同時也需要考慮圖片的大小，我在以前有寫過相應的博文。

（PS：這裡建議使用PNG8格式的圖片結合css sprite，同樣的圖片，PNG8格式會相對來比GIF小）

查看性能的工具有，比如查看內存的DDMS和MAT，查看CPU信息的TraceView等

但是提升就不是工具的事情了，那是你修改代碼的事情了，工具幫你分析數據，自己修改。

如果想要監測和發現性能問題，可以用基調的聽雲啊。

http://crab.baidu.com

感覺大多回答說的不是題主想要的，題主是希望聽雲、OneAPM這樣的性能監測工具吧

現在普遍的做法是使用APM（應用性能管理）工具，比如New Relic透視寶

1、行為性能分析：通過追蹤用戶行為動作維度，深入分析不良體驗問題根源。

2、崩潰分析：對移動應用崩潰整體的統計，追蹤崩潰堆棧、進程等信息。

3、組合分析：從運營商、設備等運營維度，綜合分析APP的性能狀況

4、卡頓分析：詳細追蹤崩潰的堆棧/進程信息，發現引起ANR/卡頓的真實原因

5、慢交互問題：多維度對請求的響應時間、錯誤，和網路失敗情況進行統計分析

6、H5頁面性能：從響應時間/JS錯誤/AJAX性能維度，對H5頁面的載入進行性能分析

作者：活動盒子

鏈接：55個APP運營推廣工具，值得收藏 - 活動盒子（運營幹貨） - 知乎專欄

來源：知乎

著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

　APP應用統計工具

　　大數據時代，APP運營往精細化之路走;精細化運營，需要對APP的各項數據進行仔細研究，因此需要藉助第三方的數據統計工具;

　　下面是大多數運營人員或站長人員經常用到的幾款統計工具，小編整理推薦給大家;

　　國內：

　　TalkingData：TalkingData-移動.數據.價值

　　魔方：魔方-移動應用服務平台

　　友盟：【友盟+】全球領先的第三方全域大數據服務提供商

　　百度統計：百度統計——最大的中文網站分析平台

　　騰訊云：騰訊開放平台|眾創空間

　　國外：

　　Appstore Optimization：http://appstoreoptimization.tumblr.com/

　　appannie.：https://www.appannie.com/cn/

　　tune：Home - TUNE

一般的測試報告應該都會有性能這塊的數據。我之前用過TestBird的APP功能測試在報告裡面除了有各個測試用例的詳細數據和截圖，也有性能的數據。

你都要監測哪些性能指標啊，我知道有app數據分析工具，主要是針對用戶行為分析的，可以據此優化分析app，我們在用的是99click旗下的siteapp數據分析系統。

APP應用上線前通過專業測試軟體對APP應用性能測試，但是但是都是基於軟體下的測試！！！APP應用真正發布以後，用戶從app Store/應用商店下載，安裝使用，由於用戶使用的手機型號（米，果，為等），操作系統（IOS，Android），接入網路（Wifi，4G，3G，2G）等多種可能組合，難免會遇到各種應用崩潰，頁面卡頓，網路錯誤等問題，這些問題導致用戶體驗〒_〒，用戶沒有那麼多的時間和口水去巴拉巴拉的告訴客服人員，我的應用崩潰，卡頓，神慢神慢滴。。。還有其它產品應用，果斷卸載換其他應用。聽雲 APP，專註於幫助開發者解決APP 應用上線後的性能監測，同步真實用戶體驗，及時發現用戶使用APP過程中的崩潰，卡頓，錯誤問題，第一時間終結用戶流失！哇哦，有了聽雲APP，再也不用擔心APP應用的性能問題啦～～～

APP性能檢測主要就是下面這些因素：APP的功能性，兼容性，崩潰率，佔用CPU，耗電量，流量佔用情況，聯接速度，連接超時或失敗，響應速度，APP的打開速度等等。

一般主流的服務商都能提供前面諸如兼容性崩潰率CPU之類的監測，最後一項APP的打開速度這一項比較困難，需要較高的技術背景和資源，目前性能極客是唯一可以檢測APP的打開速度的工具。你可以去試試看。