《A1--丁炳文--OpenHarmony應用動靜態性能檢查工具.pdf》由會員分享,可在線閱讀,更多相關《A1--丁炳文--OpenHarmony應用動靜態性能檢查工具.pdf(28頁珍藏版)》請在三個皮匠報告上搜索。
1、OpenHarmony應用動靜態性能檢查工具丁炳文華為 OpenHarmony性能測試工具專家 測試SIG成員丁炳文華為 終端BG OpenHarmony性能測試工具專家 測試SIG成員主要職責:負責基于OpenHarmony的原生應用生態和性能領域工作,涵蓋性能檢查工具設計交付、高性能檢查規則實現,致力于通過易用性工具幫助開發者提前識別并解決性能問題,助力應用OpenHarmony原生化、高性能化進程推進。目錄C O N T E N T S1.原生應用性能問題識別修復的痛點和挑戰2.動靜態性能檢查工具檢測能力介紹3.動靜態性能檢查工具實踐案例4.應用動靜態性能檢查工具未來演進方向原生應用性能
2、問題識別修復的痛點和挑戰01原生應用性能問題識別修復的痛點和挑戰海量原生應用快速開發上架當前處于OpenHarmony海量原生應用快速開發上架階段,整個應用軟件開發上架過程將面臨大量的性能和體驗問題需要優化適配。盡可能在早期識別性能問題應用開發要在早期快速識別并修復性能問題,避免問題流失到開發后期或者應用測試階段,從而導致定位和修復成本劇增。缺乏應用開發階段性能武器工具當前性能問題更多是從最佳實踐或者開發經驗中尋找解決方案,缺乏原生應用開發的端到端性能工具武器,難以發現和定位全量性能問題。性能分析優化效率低目前原生應用性能問題的發現和修復門檻較高,缺乏智能化的性能分析方法和自動化檢查工具,非常
3、需要提升端到端性能分析的效率。02動靜態性能檢查工具檢測能力介紹1 性能問題概覽2 性能工具集概覽3 高性能靜態代碼檢測工具能力介紹4 應用體檢工具能力介紹5 動靜態性能檢測工具能力覆蓋2.1 性能問題概覽 性能問題能否左移至開發態解決?性能問題能否左移至開發態解決?工具能覆蓋多少性能問題?工具能覆蓋多少性能問題?檢測出問題后能否幫助閉環?檢測出問題后能否幫助閉環?長列表未使用懶加載導致組件耗時長首頁組件復雜度過高UI主線程存在IO耗時操作冷啟動完成時延、應用內點擊完成時延、丟幀、卡頓頁面內存在白塊深層組件情況下,要精細化控制狀態變量刷新起播時延長swiper未使用cachecount導致滑動
4、丟幀拖動識別距離過大導致響應時延頁面組件創建耗時長加載web頁面初始化慢大分辨率圖片采用實時模糊耗時長未使用組件復用2.2 性能工具集概覽性能工具全景生命周期學習&賦能編碼&構建問題定位上架前自檢上架審核賦能套件開發套件上架治理承載實體性能發布性能最佳實踐指南CodeLabSampleCode代碼檢查實時編譯、編譯檢查CodeLinter場景化調優DevEco Profiler布局調試ArkUIInspector開發自檢AppAnalyzerDevEco TestingHiSmartPerf云端測試靜態檢查動態檢測分類工具工具能力下載地址性能檢測工具高性能靜態代碼檢查工具CodeLinter(
5、HpAuditor)靜態代碼檢查,掃描ArkUI等最佳實踐開發范式,51條靜態性能最佳實踐規則檢查https:/ Analyzer體驗治理規范及運行態最佳實踐檢查并多維度評分,32條動態性能檢測規則2.3 高性能靜態代碼檢測工具能力介紹問題分析抽象多維度抽象多粒度組合多場景組合多維度正向抽象技術棧維度開發調試過程維度垂類場景維度廣泛收集篩選問題12輸出范例、FAQ指導文檔源碼FAQ(時效性高)KOL文章(半官方)3輸出Gap報告系統能力差異分析低性能代碼檢測工具從問題中提取規則語言編程規范檢測API使用規范檢測提示和自動修復能力5多渠道賦能對外賦開發者對內賦能DTSE面對面交流/培訓官網、公眾
6、號、TSC4根據開發者反饋持續迭代知識賦能工具輔助開發者高性能應用應用開發階段檢測攔截低性能代碼低性能代碼檢測工具,是高性能應用構建解決方案中的關鍵一環。通過工具輔助開發者寫出符合規范和范例規則的高性能代碼。知識賦能和工具輔助兩種手段相互配合。自研應用三方應用VODIssue Report外部開發者聲音內部各改進專項自規劃內容子系統關鍵場景垂類場景最佳實踐文章2.3 高性能靜態代碼檢測工具能力介紹 在懶加載滑動場景中,框架會根據滾動容器可視區域按需創建組件,每次復用都需要重新創建組件關聯的數據對象,導致重復執行入參中的函數來獲取入參結果。如果函數中存在耗時操作,會嚴重影響性能。itemGene
7、rator中執行耗時操作的滑動效果itemGenerator中不執行耗時操作的滑動效果在滑動時框架會頻繁調用子組件生成函數itemGenerator,鍵值生成函數keyGenerator以及dataSource獲取索引數據函數的getData函數。如果在itemGenerator,keyGenerator,getData中執行了耗時操作(比如傳入耗時的函數作為入參),就會導致應用出現卡頓丟幀的問題。圖:懶加載接口的描述2.3 高性能靜態代碼檢測工具能力介紹在itemGenerator中執行itemGeneratorFunc()耗時函數itemGenerator中不執行耗時操作1000條數據完全
8、顯示所用時間平均幀率執行耗時2s 236ms108.0 fps不執行耗時1s 652ms119.9 fps對比-584 ms(26.12%)+11.9 fps(11.02%)2.3 高性能靜態代碼檢測工具能力介紹序號英文規則中文規則對應解決方案規則詳細解釋官網鏈接1hp-arkui-load-on-demand按需加載長列表加載性能優化建議按需加載模塊和組件。支持延遲數據加載的組件:List、Grid、Swiper和WaterFlow組件。最佳實踐2hp-arkui-remove-container-without-property減少視圖嵌套層次合理使用布局視圖的嵌套級別會影響應用程序的性能
9、。通過減少不合理的容器組件,可以減少布局深度,減少布局時間,優化布局性能,提升用戶體驗。最佳實踐3hp-arkui-combine-same-arg-animateto動畫參數相同時使用同一個animateTo合理使用動畫每次animateTo都需要進行動畫前后的對比,因此,減少animateTo的使用次數可以減少該組件更新的次數,從而獲得更好的性能。如果各個屬性要做動畫的參數相同,推薦將它們放到同一個動畫閉包中執行。最佳實踐4hp-arkui-use-reusable-component復雜組件的定義,盡量使用組件復用組件復用最佳實踐復雜組件的定義,盡量使用組件復用,減少組件創建銷毀代價,使
10、用Reusable并實現aboutToResue邏輯最佳實踐5hp-arkui-use-taskpool-for-web-request請求網絡資源的請求和返回處理使用taskpool線程池異步處理主線程耗時優化操作應用主線程應盡可能只執行UI任務(待顯示數據的準備、可見視圖組件的更新等),非UI的耗時任務(長時間加載的內容等)建議通過異步任務延遲處理或者分配到其他線程處理。最佳實踐6hp-arkui-suggest-use-effectkit-blur使用effectKit.createEffect實現模糊效果模糊場景性能優化使用blur和backdropBlur實現動態模糊,使用時系統將在
11、每幀對模糊效果進行刷新,對渲染負載較重,在涉及到頁面轉場動效時容易導致丟幀問題。建議使用effectkit的模糊方式,因為它的實現里只模糊一次,對渲染負載較輕。最佳實踐2.4 應用體檢工具能力介紹輸入和通用能力測試服務開發能力前端部署IDE集成工具-應用與服務體檢Tools-AppAnalyzer頁面遍歷能力DFX Trace打點性能標準文檔高性能編碼實踐啟動響應時延/丟幀/卡頓率前后臺內存峰值占用后臺CPU占用點擊響應/完成時延/丟幀/卡頓率滑動響應時延/丟幀/卡頓率文件IO未并行化Web組件初始化耗時檢測Web執行js耗時檢測Web主資源下載耗時檢測Web子資源下載耗時檢測避免過大的組件樹
12、節點數目UI線程耗時操作檢測頁面內白塊檢測短視頻起播時延播放器使用硬解碼相機分段操作ArkUI高性能實踐Web應用最佳實踐2.4 應用體檢工具能力介紹開發者旅程開始體檢參考體檢報告1.體檢出性能問題評分結果直觀丟分項概覽性能數據解析2.性能數據解讀問題自助修復4.修復性能問題武器庫指南性能數據詳解引導使用CodeLinter接續分析引導查看武器庫優化指南引導使用ProfilerCodeLinter(HpAuditor)Code Linter代碼靜態掃描根據性能問題跳轉武器庫指南引導修復3.動靜結合引導開發者2.5 動靜態性能檢測工具能力覆蓋開始體檢調測軟件包 應用top性能頁面存在:“復雜UI
13、:未使用組件復用”問題自助修復分析結果:組件創建耗時 CodeLinter檢查:手工點擊檢查,傳入頁面文件、檢查大項返回結果:呈現具體錯誤及修復建議檢查項未通過:滑動、點擊界面出現丟幀大未通過原因分析:基于trace分析 通過體檢工具觸發,發現問題后,修改可以具體到代碼層級,并提供對應的正反例,或者性能優秀實踐,比如:應用冷啟動性能提升指導、Web組件開發性能提升指導、運行時動態加載頁面提升性能、組件復用設計模式等。有具體檢查靜態規則覆蓋場景,可提供具體修改建議和范式,預計可覆蓋92%的問題:該類問題具備共性特征,可基于場景進行邏輯抽象,比如:組件嵌套、層級過深、屬性設置過多、未組件復用、網絡
14、請求未并行化、數據庫未并行化等,占比92%左右2.5 動靜態性能檢測工具能力覆蓋開始體檢調測軟件包應用top性能頁面存在:“其他類:接口冗余調用”問題自助修復分析結果:函數耗時,無對應靜態規則匹配 Profiler分析:基于trace+perfdata分析返回結果檢查項未通過:界面丟幀、啟動時延大未通過原因分析:基于trace分析 無具體靜態檢查規則覆蓋場景,提供調用棧和Trace分析,預計可覆蓋剩余7%的問題 該類問題主要是應用邏輯問題,或者代碼bug類問題,比如:接口重復調用、接口適配不正確、業務邏輯復雜,占比7.3%左右 體檢過程中,預先錄制trace和調用棧(對性能影響較?。?,減少問題
15、復現二次錄制的操作,縮小Trace、調用棧查看范圍,明確問題根因方向。2.5 動靜態性能檢測工具能力覆蓋覆蓋完成時延、響應時延、丟幀卡頓等五大類、40+小類性能問題常見性能問題覆蓋率80%以上覆蓋場景全問題識別準檢測速度快修復能力強動態體檢工具提供自動和手動兩種檢測能力,手動省力,自動省時,一個檢測項只需23 min靜態掃描工具100 W行代碼只需100 s針對問題頁面單獨檢測,檢測結果和已知問題完全一致檢測數據和真實數據誤差小于5%靜態掃描工具誤報率小于5%,漏報率小于10%提 供 全 場 景 解 決 方案,包含問題頁面、最佳實踐、問題定位關鍵信息,trace和棧調用提供規則正反例,屬性和組
16、件正確使用方式工具使用演示工具使用演示動靜態性能檢查工具實踐案例033.1 典型案例介紹 新聞類應用在上架測試中,在瀏覽詳情場景存在明顯的丟幀卡頓的性能問題。第一輪測試第二輪測試第三輪測試第四輪測試第五輪測試上滑-第一次丟幀卡頓(次數)13112最大連續丟幀數(幀)00100上滑-第二次丟幀卡頓(次數)10210最大連續丟幀數(幀)10110表:檢測原始結果圖:脫敏抽象后卡頓展示3.1 典型案例介紹開始體檢問題自助修復分析結果:組件創建耗時 CodeLinter檢查:手工點擊檢查,針對該組件所在模塊/文件檢測返回結果:呈現具體錯誤及修復建議檢查項未通過:頁面內滑動過程流暢性快速檢測未通過未通過
17、原因分析:基于trace分析,確定為XX組件未復用3.2 應用改進前后收益對比第一輪測試第二輪測試第三輪測試第四輪測試第五輪測試上滑-第一次丟幀卡頓(次數)00000最大連續丟幀數(幀)00000上滑-第二次丟幀卡頓(次數)00100最大連續丟幀數(幀)00100表:修改后檢測結果圖:優化后效果展示優化后動態體檢結果使用CodeLinter和AppAnalyzer檢測并按照修改意見修改后,最終檢測結果已無明顯卡頓應用動靜態性能檢查工具未來演進方向04應用動靜態性能檢查工具未來演進方向2024 Q3場景覆蓋率提升1、識別新增重點性能問題支持,原生問題場景覆蓋率達90%2、發布60+性能規則,準確
18、率超過90%2024 Q4高階能力開放1、支持跨文件掃描能力,全方位覆蓋問題可能出現的場景。2、新增C+語言性能問題識別能力,場景覆蓋率達50%,賦能更多開發用戶2025 Q1工具極致優化1、適配更多C+性能問題場景,場景覆蓋率達90%2、支持泛性能的檢測與開發實踐指導3、支持非原生框架性能問題識別應用動靜態性能檢查工具未來演進方向n 用戶訴求:目前部分規則只支持單文件掃描,而在實際開發中,有很多內容是跨文件形式調用的,實際上滿足高性能編程規范。n 價值:提升規則準確性,幫助開發者更加精準地發現問題,減少規則歧義,提升開發者解決問題效率??缥募脛屿o態性能檢查工具未來演進方向目前HpAuditor僅支持ArkTs、JavaScript、TypeScript掃描,但目前北向應用不僅使用此三類語言進行開發,使用C+的開發者不在少數,因此支持C+掃描能力可以使更多應用性能問題在開發態中發現和進行優化。C+感謝聆聽QECon公眾號OpenHarmony OpenAtom公眾號