這個月Boss須要咱們整理一份各個性能採集後的參考值,對於崩潰的數據採集,咱們接入有Bugly,友盟。對於性能採集咱們接入的是Firebase Performacehtml
日報使用:崩潰率(友盟最新版)、啓動時間(Performance)
統計使用:崩潰率(友盟最新版)、用戶崩潰率(友盟最新版)、ANR率/卡頓率(bugly最新版)、啓動時間(Performance)、網路呼叫成功率(Performance)
崩潰率的定義:友盟比較符合大多數人的理解
參考值的定義:崩潰率和啓動時間,雖然有找到一些參考值,不過對比以後顯示咱們的數據很是好(緣由是平臺統計數據爲業內平均值),因此咱們依據591近期的數據和自我要求,定義了一個參考值(如上日報)
其它:用戶崩潰率、ANR率/卡頓率、網路呼叫成功率,對於App的性能評估也有必定的做用,不過日報裏面建議先不添加,避免太多內容app
平臺 | 名稱 | 計算方式 | 描述 |
友盟 | 崩潰率/錯誤率 | 崩潰次數/啓動次數 | 1.崩潰次數/錯誤次數: 該類錯誤在必定時間範圍內產生的次數,也就是SDK上報的日誌數量 2.啓動次數: 1).Android:啓動是經過在全部activity中調用MobclickAgent.onResume() 和MobclickAgent.onPause()方法來監測的 2).iOS:進入後臺即算是當前統計會話結束。當再次進入前臺時,算做一次新的啓動行爲, 並開始新的統計會話 |
用戶崩潰率 | 影響用戶/活躍用戶 | 1.影響用戶數:在必定時間範圍內對該類錯誤的全部錯誤日誌按照設備維度進行排重計數 2.活躍用戶:所選時間段內,啓動過應用的用戶(去重),啓動過一次的用戶即被視爲活躍用戶,包括新用戶和老用戶。 |
|
Bugly | 次數崩潰率 | 發生次數/聯網次數 | 1.發生次數:一個異常發生且被記錄上報,計爲一次異常發生。 2.聯網次數:即 啓動次數+跨天聯網次數。 3.跨天聯網:用戶沒有啓動應用,只有應用進程在後臺運行,且超過零點,計爲一次跨天聯網。 4.啓動次數:如下場景均計爲一次啓動 1).應用徹底退出後從新啓動,計爲一次啓動; 2).應用被切換至後臺後,30秒後被切換至前臺,計爲一次啓動,若未超過30秒切換至前臺,不算一次啓動。 |
用戶崩潰率 | 影響用戶/活躍用戶 | 1.影響用戶數:在必定時間範圍內對該類錯誤的全部錯誤日誌按照設備維度進行排重計數 2.活躍用戶:所選時間段內,啓動過應用的用戶(去重),啓動過一次的用戶即被視爲活躍用戶,包括新用戶和老用戶。 |
|
次數ANR率/卡頓率 | 發生次數/聯網次數 | 同上次數崩潰率描述 | |
用戶ANR率/卡頓率 | 影響用戶/聯網用戶 | 同上用戶崩潰率描述 | |
Performace | 啓動時間 | 從程式碼初始化 - 使用者介面有所回應為止 | 定義 1.iOS:在應用將第一個 Object 加載到內存時開始,第一個 run loop 成功(應用收到 UIApplicationDidBecomeActiveNotification 通知後)時中止。 2.Android:在應用的 FirebasePerfProvider ContentProvider 完成其 onCreate 方法時開始,第一個 Activity 的 onResume() 方法被調用時中止。 |
網路呼叫成功率 | 成功響應次數/總響應次數 | 由傳回 2xx 或 3xx 回應代碼的應用程式提出的 HTTP/S 要求百分比。如需查看詳細資訊,請前往「網路要求」分頁 | |
GooglePlay | 當機率 | 無 | 使用者遇到至少1次當機情形的每日工做階段百分比。每日工做階段是指使用者一天內使用應用程式的時間 |
ANR 發生率 | 無 | 使用者遇到至少 1 次 ANR 情形的每日工做階段百分比。每日工做階段是指使用者一天內使用應用程式的時間。 | |
App Store Connect | 崩潰率 | 崩潰次數/使用次數 | 目前appstore 統計是限參與統計用戶 計算方式是 = 崩潰次數/使用次數 (使用次數:使用時間超過2s的次數)附:僅限參與統計用戶 |
名稱 | 業內參考值 | ||
iOS | Android | 數據來源 | |
崩潰率 | 1.01% | 0.2% | 聽雲16年報告 - 年平均崩潰率 |
0.93% | 0.13% | 聽雲15年報告 - 年平均崩潰率 | |
0.78% | 1.89% | 聽雲17年報告 - 房產中介 - 年平均崩潰率 | |
0.79% | 0.17% | 聽雲17年報告 - 工具 - 年平均崩潰率 | |
0.38% | 0.09% | 聽雲16年報告 - 軟件工具 - 年平均崩潰率 | |
優秀值0.3% 標準值0.8% |
優秀值0.2% 標準值0.4% |
來自14年的聽雲報告 根據統計數據顯示,當iOS的崩潰率超過0.8%,Android的崩潰率超過0.4%的時候,活躍用戶有明顯降低態勢。 |
|
2.96% | 2.86% | bugly2016 移動應用質量大數據報告-平均崩潰率 | |
優秀:0.03% | 一些開發羣中開發者的回覆(滴滴,美團) | ||
ANR率/卡頓率 | - | 1.09% | GooglePlay的不良行爲門檻 |
用戶ANR率 | - | 0.47% | GooglePlay的不良行爲門檻 |
啓動時間 | 5s | Performance標準值 | |
網路呼叫成功率 | 97.45% | 95.48% | 聽雲17年報告 - 年平均 HTTP 請求成功率 |
響應時間 | 417.99ms | 439.65ms | 聽雲17年報告 - 房產中介 - 年平均響應時間 |
652.69ms | 617.19ms | 聽雲17年報告 - 工具 - 年平均響應時間 |