Tips：若是未發布應用，可以利用Xcode自帶的instruments工具，對我們的應用進行cpu占用、內存占用、FPS、循環引用、離屏渲染、卡頓、頁面耗時、網絡、啟動時長等各個維度進行分析。若為線上應用，我們只能通過自行打點采集各個維度的信息，來進行性能分析。
一、性能統計維度
1.設備屬性維度
- OS類型
- 廣告標示符idfa （iOS14.5開始強制權限，iOS14.0-iOS14.5可強行讀取idfa，14以下老方法）
- 廠商標識符idfv （也可認為是應用維度）
- 設備名稱
- 系統版本
- 設備Machine
- 運營商
- 硬盤總容量
- 物理內存總容量
- 當前硬盤容量
- 當前內存容量
- 分辨率
- 設備Model
- 時區
- 國家
- 設備語言
- 系統上次啟動時間
- 系統上次更新時間
- 當前可用空間
- 當前網絡類型
- 當前ip
- 當前cpu使用率
- 是否越獄標識
- 當前電池電量
- 當前屏幕亮度
- 當前充電狀態
- gps開關狀態
- UserAgent
- 最近一次定位坐標（需要定位權限）
- ssid 當前wifi名稱 （iOS13開始需要定位權限）
- bssid 當前wifi的bssid（iOS13開始需要定位權限）
- bundleSeedID
2.應用基本屬性維度
- 應用名稱
- 應用bundle id
- 應用版本
- BundleShortVersion
- BundleVersion
- 應用熱更版本（若有）
- 應用RN包版本（若有）
- 業務灰度包版本（若有）
- 小程序版本（若有）
- 性能統計SDK版本
- user id
- session id
- 自定義uuid（存儲在keychain里）
- 是否在后台
- 應用運行時長
- 當前應用商店地區
- 當前應用商店商品貨幣類型
3.應用性能維度
- 持續電量統計
- 持續cpu使用率統計
- 持續內存使用率統計
- 各個模塊、插件、大文件內存使用
- 循環引用監測
- 網絡持續監測
- 網絡類型持續監測
- 網絡流量持續監測
- 網絡錯誤類型
- FPS
- 主線程卡頓監測
- 頁面渲染時長
- 大文件存儲監測
- 閃退日志記錄
- 啟動時間監測
- 冷啟動時間監測
- 熱啟動時間監測
- 全打點，每個函數耗時監測（線上不推薦）
- Flutter、RN、web、小程序等問題日志（若有）
4.應用業務維度
- 應用生命周期打點
- 各個業務頁面打點、停留時長打點
- 用戶行為打點（通過AOP，自動獲取view的鏈路樹打點）
- 根據實際產品定制維度。。。
注意：由於蘋果對標識設備、用戶的行為監管越來越嚴，采集過多的設備信息會被蘋果認為違規，會收到蘋果的整改郵件通知。另外，中廣協的CAID暫時不要對接，蘋果審核時候會被勸退。
二、數據落地
0.設計理念
- 性能統計SDK接入足夠輕量、簡單、無侵入
- 策略配置靈活、易控制
- 性能損耗低、絕不能影響主業務本身
- 盡量不使用私有API，避免被蘋果審核誤判
- 本地數據做好持久化，避免閃退時候寫本地失敗，使用mmap
- 數據大小盡量小，可使用protobuf；另外部分數據可壓縮上傳
- 數據需要加密傳輸
- 上傳數量策略靈活：部分點位實時上傳、部分點位可以合並壓縮后上傳、斷網重試等
- 針對不同機型，有不同配置
- 打點點位可以灰度、服務器下發
- 配套監控、報警體系，實時跟進線上突發以及新功能問題
- 全球化業務需要做到滿足各國法規，國內三級等保、歐盟GDPR 等 ，隱私策略或是用戶協議里需說明
1.數據采集
采集維度分為六大類：
- 啟動后打點記錄一次性基本設備信息維度: 機型、系統版本、idfa等
- 每次打點都需要包含的base維度：uuid、userid、會話id、sdk版本等
- 持續性的性能監測維度：電量、cpu使用率、內存使用率、卡頓、網絡相關等
- 偶發性的統計維度：冷啟動耗時、熱啟動耗時、閃退等
- 業務維度：模塊、頁面打點、停留時間打點等
- 自定義日志：自定義log等
{
//base信息
"timestamp":"事件產生時間(13位 毫秒)",
"appId":"應用ID",
"device":"設備型號",
"sessionId":"會話id",
"idfv":"應用開發商標識符",
"advertisingId":"idfa",
"deviceId":"自定義存keychain uuid",
"sdkVer":"SDK版本號",
"appVer":"應用版本號",
"userID":"用戶ID",
...
"deviceInfo":{
...
},
"crashInfo":{
...
},
"performanceInfo":{
...
},
"moduleInfo":{
...
},
"eventInfo":{
...
}
}
采集時機：
- 實時上傳維度
- 部分數據合並后擇機上傳
- 突破某個閥值上傳
- 斷網重試或是下次啟動上傳
2.數據合成、壓縮、存儲
- 數據存儲，若為實時上傳類型，則不用存儲端側，若實時上傳失敗且重試機制情況下依然失敗，則需要存儲端側；若為非實時數據，則需要存儲端側；擇機上傳；
- 考慮到app意外退出，會有日志或是閃退信息無法存儲端側的情況，可以采用mmap方式存儲日志；
- 考慮到頻繁的IO會造成性能上的消耗，我們需要對數據進行合並，且讀寫時候，需要參照當前機型的虛擬內存頁的大小，老的機型是4KB。即每次讀寫都是按開辟4KB存儲；
- 考慮到上傳數據的大小問題，可以考慮使用protobuf對數據進行壓縮；另外，protobuf數據本地持久化的過程可以參照微信的MMKV設計；
- 另外數據是否加密，可以酌情考慮
- 端側日志數據存儲上限應針對不同硬盤大小設定
3.上傳服務器
- 上傳失敗重試機制
- app閑時或是剛進入后台等時機，擇機上傳
- https
4.數據分析處理
- 數據上傳到數據服務器，進行解壓、處理、按業務維度進行處理
- 根據具體業務進行多維度處理
- 入庫需要的數據，定時清理老日志文件
5.web儀表盤展示
- 按應用維度、版本維度、系統維度、業務維度、動作維度、機型維度 等等進行展示；
- 業務點擊率、轉化率等；
- 按PV、UV、DAU、MAU、PCU、APA、ARPU等維度；
- 異常、閃退維度；
- 更多。。。
6.監控、報警體系搭建
- 根據已有的維度以及數據，對線上業務或是新版本進行監控，比如初始化成功率、登錄成功率、支付成功率、某個業務的點擊或是完成率、在線用戶數，針對不同時段給到一個上、下限，若是觸發了邊界值，則通過郵件、企業微信、短信或是報警電話等方式通知相關干系人；
- 具體的監控以及報警體系以實際業務為基准定制；
- 我們部門有買了小米75寸電視作為監控屏幕，掛在部門牆上；
- 按照經驗，我們部門在凌晨會經常收到誤報，常見的是蘋果支付的問題（一般是蘋果服務器抽風）， 另外是業務部門在做停服更新，登錄、支付、用戶等指標驟降，會觸發報警，還是需要跟各個業務部門定好更新機制；
三、復盤、優化、整改
- 有了以上的日志分析，需要對各個業務線進行復盤、優化、整改，再監測，再優化整改，不斷循環；
- 監控與報警體系搭建也不是一朝一夕，也需要不斷優化，使其更加精准，尤其是節假日的時候，發揮其作用；
- 這么多的數據如何有效的利用以及如何用來改善產品，需要運營、產品一起去有效的開發，而不是純粹的只是記錄、監控；
- 這些數據可以有效的幫助市場同學分析，在各個移動平台廣告投放的效果 以及轉化；
- 作為技術人員，除了關注技術側的應用本身質量、穩定性、性能等，視野也要拓展，協同運營、產品、市場給應用帶來更多的用戶，更好的體驗；
四、總結
APM開發力度如何，應視業務規模而定，若達到一定的量，必須認真對待。本文更多的提了一些iOS側，對於android也一樣適用，除了部分設備指紋維度有所區別。