背景
性能問題
通常情況下，App的性能問題并不會直接導緻其不能使用，卻會潛在的影響使用者體驗。在衆多App"内卷"的當下，一個不好的體驗甚至能導緻使用者的流失。比如：
• 啟動速度過慢
• CPU占用率高導緻的手機發熱、耗電快
• 不明原因的閃退
• …等等
預防和檢查
當然，作為一名開發者，在編寫代碼時就要做到避免一些性能問題的出現。比如：
• 優化計算的複雜度進而減少CPU占用率
• 編寫單元測試
• ...等等
當然，善用工具可以高效地去監控App的性能問題，幫助開發者及時修複産品體驗上的缺陷。市面上APM工具很多，因為筆者曾在項目中使用過U-App進行過應用資訊的統計，在此就友盟
U-APM來說一些使用體驗。
U-APM使用體檢
內建
參照官方平台的
內建說明，以iOS為例，這裡做一個簡述
1.
在U-APM建立應用，生成一個Appkey
2. 推薦使用CocoaPods來接入SDK
pod 'UMCommon'
3. pod 'UMDevice'
4. pod‘UMAPM’
在 AppDelegate.m 檔案中，添加如下
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[UMConfigure initWithAppkey:@"61276660870a7a610a4f67f5" channel:@""];
// Appkey在步驟1中生成
// channel字段為自定義管道區分，不填寫則被預設為是"App store" return YES;
}
分析結果
1.崩潰分析
我僅僅是在項目中的首頁手寫了一個可主動觸發的閃退Bug。分析結果圖解如下：
崩潰的曲線圖對于開發者來說，算是一個統籌的展示。重要的是，在頁面下方的錯誤清單中，可以檢視某個錯誤發生的次數，類型，影響的使用者數。這很友善作為開發者在修改Bug時能快速準确的判斷優先級。另外，錯誤都有單獨的錯誤明細頁，大部分的Bug都可以被精準定位。
後來由于
啟動崩潰分析的啟發，我在項目内的啟動方法-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 中，即配置Appkey的前後，都分别寫了閃退Bug，并暫時用管道名做了區分。
結果顯示，在配置AppKey前發生的閃退，并不能被捕獲。
有人會問：那這不是必然的麼？你都還沒配置呢...
這也正是我想說的問題。因為在許多時候，我們去配置一些第三方庫時，由于內建方法過于簡單，總是會很随意的根據官方教程去添加一行代碼，并不去考究它在項目代碼中應當所處的最佳位置。因為這并不影響項目運作，這種細節也很容易被忽略。我希望在任何時候，開發者們都應該養成每一行代碼在敲下去之前都嘗試去思考的習慣。
2.分析卡頓
卡頓的清單與明細也是和崩潰一樣，可以查詢和定位。并且能夠标記（未處理、修複中、已忽略、已修複）4種狀态。
我還另外添加了卡頓告警計劃，隻要卡頓使用者數占比超過5%，就會發郵件通知我。它成功的在一小時内觸發告警資訊并在郵件中提醒了我。
3.啟動分析
我在啟動時采用了随機數去随機放慢該項目的啟動速度。預設首次啟動/冷啟動超過3秒為慢啟動，熱啟動超過1秒為。這裡以冷啟動為例：
在分析柱狀圖裡也很好的展示了正常啟動與慢啟動的占比
4.記憶體分析
在OOM的分析上，貌似對Android的支援更甚iOS。由于iOS的Jetsam機制，這裡隻分析當程式記憶體超出限制時造成的一種特殊的Crash。包括異常的捕獲也不是全都能檢測。
5.分布分析
平台均能在以上四個子產品（崩潰、卡頓、慢啟動、OOM異常）分析中提供分布狀況，包括裝置分布、系統分布、營運商分布、版本分布、頁面分布、管道分布、地域分布。
5. 自定義配置子產品
還提供了采集開關，需要在初始化前就在代碼中配置好。
以上就是我體驗的
的全部功能。
還有一些我來不及體驗的功能等待更多開發者去使用，比如“雲真機”，"API上傳符号表頁面整體加載速度渲染"等等。
一些建議分享
**在卡頓分析與崩潰分析的營運商子產品中，出現了一個分析錯誤❌。**我使用的是電信寬帶與電信卡，分析結果卻展示出我使用的是中國移動的營運商。當然對于這種問題，平台有另外的客服工單可以去提出，這裡也不再贅述。（從過去使用其他友盟的産品來看，客服工單的回報效率還是挺不錯的）
另外值得一提的是，因為筆者在項目中已經将開發語言完全過渡到Swift，但在內建時，官方提示Swift目前僅支援U-App統計，其他業務暫不支援Swift。我也是連夜建立一個OC項目去體驗，并沒有嘗試在Swift項目中接入。而現如今，Swift已成iOS開發主流語言，希望U-APM能在未來能全面支援Swift更加便利開發者。
當然，這不妨礙它目前可以滿足開發者們在OC項目中對性能監控的基本需求：
•內建方法簡單、迅速
•追蹤崩潰、卡頓的詳細資訊，輕松定位根源問題
•分析圖解清晰明了，多狀态友善管理
•識别裝置類型（iPhone/iPad/iPod、作業系統版本、營運商類型），分類裝置性能
最後，我還是希望，适當使用工具可以提升開發效率，但也請不要過分依賴而忘了思考。
作者：蔡丹霞