一、淺談手機性能的可觀測性

1.概述

手機上的性能指標是綜合的變化，由上圖可以看的出來手機更關注人跟機器的交互這，云系統則是比較關注機器跟機器的交互。

手機系統比較特別的地方在于資源都是比較受限，例如: 電量，性能…因此針對用戶體驗是需要特別庖丁解牛來建立指標。

指標(METRIC) -業界有特定的體驗度量模型，目標是發現產品和服務中的問題及理解使用者的行為和偏好。

性能體驗度量是多層次，多個維度的，只用一項指標去表征的所有性能特征是遠遠不夠的。

以上是幾個個常用指標，這些指標常常是互相搭配的例如Andrid近年常用的GSM+HEART。度量模型圍繞用戶使用的旅程，識別關鍵體驗路徑(KEP)，為不同接觸點分解出不同的性能指標。

2.性能追蹤

實際上如何構建手機可觀測性，我們都會采取分層次拆解，由上圖可以看的出來藉助于Android/Linux系統的生態系已經有不少工具可以用于追蹤系統的信息。

性能追蹤在手機裝置面臨的挑戰:

1、低開銷：不會降低用戶的體驗，因為手機資源是受限的所以如何有性的采集會是很大的考驗。

2、不可接觸：開發人員無法實時獲取使用者的故障第一現場信息，用戶很多操作行為都是不容易在現，因此識別關鍵體驗路徑會是開發的過程之一。

3、偶發性：低概率，不易復現(Heisen berg Bug)，對于第三方應用跟系統交互或是用戶行為常常有偶發性不易在現的問題需要準確的追蹤機制輔助找到原因。

4、不可預見：用已知模式分析未知問題。

講師介紹了一些Android上常見的工具

?Systrace : 用于將設備活動保存到跟蹤檔的Android 工具。

?cpu_profile : 在android平臺實現周期性采集調用棧。

?simpleperf : simpleperf是Anroid平臺的一套性能分析工具，功能大致與linux perf相似。

?nanotrace : 通過在虛擬機（包括解析器和編譯程序）中插樁，獲取從APK到framework層的執行路徑的調用鏈和函數執行時長。

?objtrace : 動態跟蹤函數參數值。

?blktrace : blktrace 結合btt可以統計一個IO是在調度隊列停留的時間長，還是在硬件上消耗的時間長。

?Hitrace : 對于跨設備/進程/線程的業務流程處理，通過相同的traceid在整個業務流程中傳遞，將調用層次、各種輸出信息關聯和展現。

3.可觀測性之Logging

上圖由上而下的拆解展示日志的重要性，首先我們需要了解用戶行為，關注用戶體驗并記錄對應的錯誤日志，當時系統狀態與硬件狀態用于改善用戶體驗。

手機系統的日志系統時常需要整合第三方應用，因為第三方應用不開源，管理日志上常常沒有足夠權限，還有手機儲存大小受限因此最終的日志系統方案都是朝可以匯整日志并更精準建立模型為目標。

總結以上幾點用戶體驗是感性的，不單單只是數字因此講者認科技應該是有溫度的。

Q&A

Q : 是否有AI優化思路？

A: 目前還在努力，有嘗試用AI分析用戶體驗不過效果不明顯。目前比較多還是在做基礎體驗度量。

Q : 跑分跟用戶體驗怎么看？

A: 跑分不能直接當用戶體驗偵率，累積布局偏移可參考。

Q: nanotrace可否第三方插莊？

A: yes

Q : 是否能找到喚醒源？

A:可打開irq，ipi中斷事件可以看到換醒源。

二、揭秘ARM架構對Linux調測特性的支持

講師簡介：張健, 現就職于北京大簡技術有限公司, 14年ARM架構和操作系統一線研發經驗. 在北京, 柏林, 拉斯維加斯, 多地發表技術演講。

首先，本次分享從調試視角、性能影響兩個角度出發，對調試特性進行了宏觀的分類。

1.調試類型

調試包含兩個維度的特性：調試視角維度與性能影響維度。

1.調試視角維度

從調試視角維度出發，調試分為external debug與self-hosted debug，前者包括openocd、kgdb、ftrace、perf等內核調試基礎設施，后者則是通過JTAG、FTOI等體系結構相關調試接口連接芯片，同時用調試軟件控制硬件調試器進行調試。

其中，紅色所示技術為硬件調試接口，藍色所示技術為相關軟件調試工具。軟硬件調試工具共享CPU和內核所提供的調試能力。

2.性能影響維度

從性能影響維度出發，調試分為影響（多為停止）當前CPU狀態的侵入式調試和不影響CPU運行的非侵入式調試。前者多會暫停當前CPU的執行流，同時通過相關機制（比如，AR cross trigger）告知其他核當前被調試的狀態，從而影響系統狀態。

這種調試類型雖然帶來了強大的調試能力，但是在芯片和內核的設計開發時需要考慮CPU調試過程中與其他外圍設備的關系，因為CPU的調試狀態不會影響到其他硬件，一致性等問題是該方法的經典挑戰；對于非侵入式的調試類型，它不會直接停止當前的CPU運行狀態，更多對系統起到監控跟蹤的作用。

接下來，分享從斷點、Trace、PMU三類調試手段出發講述ARM架構的系統調試特性。

2.侵入式調試手段之斷點

斷點調試是侵入式的，單純依賴用戶態基礎設施或頂層應用無法達到啟停系統的能力要求。因此，斷點調試的設計需要硬件和操作系統的支持，即斷點調試要有陷入高特權級別環境的能力。

用戶通過配置編譯選項獲得指定平臺下的gdb調試器，將被追蹤程序當作參數傳遞gdb調試器，gdb調試器fork出被調試程序子進程，兩者通過PTRACE_XXX請求建立連接。

對于軟件斷點，gdb將通過符號表等信息在開發者指定的位置填入調試指令（x86為INT3，ARM為BRK/BRKT）；對于硬件斷點，gdb會將指定位置的地址寫入到調試寄存器中。

當程序運行至軟件斷點或硬件斷點處，子進程會觸發相應異常，待異常信號被gdb捕獲后，通過比對記錄的斷點信息來判斷是否是調試原因所觸發的異常，如此來實現gdb調試進程的啟停能力。

3.非侵入調試類型之Trace

ARM Coresight架構是遵循可觀測性的架構設計，Cortex Processor后的ETM負責在處理器外部抓取指令序列，不影響CPU的運行狀態。并且，Trace信息的傳輸未經系統總線，減少了對系統帶寬的影響。Coresight架構中存在多個執行流抓取點，存在多個對應的ETM，多個ETM收集的信息會傳入下游的Funnel，Funnel將根據數據所存在的信息將執行流信息進行分流處理。

關于具體的互聯結構可以查看對應版本的設備樹文件。（所在源碼目錄為/arch/arm64/boot/dts）

4.非侵入調試類型之Performance Monitor Unit(PMU)

CPU中存在PMU部件，該部件會監控CPU的相關性能信息，用戶可以通過訪問相應的寄存器獲取相關信息。perf是一種可以訪問PMU的用戶態工具。

perf訪問PMU的相關流程如下：

1.使用perf_pmu_register注冊PMU事件。

2.perf_event_open系統調用打開對應事件的文件描述符，從中讀取記錄的值。

審核編輯 ：李倩