一、前言
之前一直是用騰訊的bugly
目前受邀推薦使用
友盟+U-APM，那就讓我們來嘗試體驗一下
二、快速內建
2.1 賬号注冊
友盟+注冊注冊很快，沒有繁瑣的步驟和多餘的資訊填寫，點贊
2.2 建立應用
應用性能監控平台U-APM
2.3 Demo下載下傳
為了快速體驗，我們跳過SDK內建這一步，直接用官方提供的Demo。
SDK內建也很友善，直接看官方文檔即可：
Android SDK內建流程Demo下載下傳：
MultiFunctionAndroidDemo：友盟多功能Android Demo 2.4 Demo導入
導入工程File->New->Import Porject
期間有遇到一個問題，如果大家也同樣遇到這個問題可以參考博文：
Android Studio Failed to open zip file的解決辦法 2.5 Demo試跑
修改preInit(Context context,String appkey,String channel)後，即可運作Demo
// SDK預初始化函數
// preInit預初始化函數耗時極少，不會影響App首次冷啟動使用者體驗
public static void preInit(Context context,String appkey,String channel)
preInit()在App.java裡面調用，傳入自己的appkey即可。
appkey在如下圖中複制。
Demo跑起來後，再去背景看看，就會發現應用的狀态變成：已內建
三、極緻體驗
3.1 第一個App崩潰
· 有點意外， 第一個崩潰資訊出來的有點快。
· 首頁->點選統計UApp->點選程式崩潰
3.2 檢視背景崩潰資訊（延時1分鐘+）
· 這時候就要趕緊看下背景，有沒有錯誤資訊上報
· 一直重新整理背景，同時對比實時時間，大概延時1分10秒左右，背景才顯示出錯誤資訊。與騰訊bugly對比略微好點，半斤八兩吧
· 不過，錯誤資訊倒是給的詳細，直接找到com.umeng.soexample.analytics.UappActivity的第94行
· 認真一看，很明顯的錯誤，"123"的字元串長度隻有3，無法索引到10
findViewById(R.id.analytics_g3_b1).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
Toast.makeText(mContext, "已完成程式崩潰", Toast.LENGTH_SHORT).show();
"123".substring(10);
}
});
3.3 錯誤處理
· 把未修複改成已修複
· 首先，故意不修複代碼，再制造一次程式崩潰
· 處理狀态不變，還是已修複
· 其次，修改App版本versionCode改成2，versionName改成1.0.1，其他不變，再制造一次程式崩潰
· 處理狀态依舊不變，還是已修複。
· 不過版本範圍變了1.0 ~ 1.0.1。這就有點參差了，對此我就有點意見了，詳情見後文第四章節。
3.4 告警設定
· 通過錯誤清單的告警入口進來
· 建立告警計劃
· 告警名稱
· 觸發條件：>3次
· 生效應用版本：全部
· 觸達方式：郵箱、企業微信
3.5 企業微信機器人
· 添加一個群聊
· 添加群機器人
· 得到該機器人的Webhook
3.6 告警觸發
· 告警設定成功後，就開始觸發告警
· 點了好幾次都沒反應，奇奇怪怪
· 沒關系，有點耐心，等~
終于被我等到了~
· 很明顯看出來，告警觸發是每小時一次的
· 基本都在每小時的07分左右推送
四、一點小建議
4.1 錯誤明細中缺乏App版本
· App版本号在錯誤清單中有展現，挺好的
· 但是在錯誤明細中沒有展現，相反還多出一個SDK版本号，容易混淆
4.2 錯誤處理的邏輯流程
錯誤處理的邏輯流程可以優化成如下：
· 在崩潰分析->錯誤清單->處理狀态在勾選已修複的時候，選擇在XX.XX.XX版本修複
· 後續如果版本大于 XX.XX.XX版本時，還有同樣的錯誤上報，則把處理狀态自動修改成修複失敗
· 增加一個處理流程記錄，詳細記錄這個bug在XX時間被XX人在XX版本修複，然後在XX版本又複發……
按照這個邏輯修改後，處理狀态是動态的，增加了更多的資訊。
比起目前，一旦手動修改了處理狀态後，其狀态一直不變，是不是強多了~
作者：康玮劍
1、多年嵌入式軟體開發經驗；
2、同樣擅長Android開發和微信小程式開發；
3、做過大廠的系統工程師，當過小廠的嵌入式主管，現在是個創業公司的軟體經理； 4、對IoT物聯網開發有自己的見解，業餘時間喜歡沉澱、整理與分享輸出自身的技術知識。