對動畫卡頓進行偵錯
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
應用程式開發人員面臨的一大問題,就是確保動畫流暢、無故障和無資源浪費。當系統也會執行耗用大量資源的背景工作時,這就特別難以偵錯。要判斷某些卡頓是由您的應用程式還是系統造成,目前沒有任何簡單的方法。不過,您也可以使用分析器工具找出不良行為的可能來源。
在 ChromeOS 上轉譯
經過微調的應用程式 (例如遊戲) 通常會使用雙緩衝功能,盡可能降低使用者回應時間。不過,仍有許多因素可能會降低效能。舉例來說,如果轉譯影格時間過長,轉譯後的結果就無法進行下一個緩衝區替換,因此先前的影格會重複。
之後,轉譯器就無法開始轉譯下一個影格,因而造成其他問題。Android 行動開發人員熟悉這種情境,因此應用程式在 ChromeOS 上執行時,使用情境會更複雜。
在電腦上執行的應用程式不會直接算繪至螢幕的顯示框。而是將其資料算繪為紋理。通常有多個應用程式,每個應用程式都會將圖形算繪為紋理。系統會使用合成器在螢幕上建構檢視畫面,將所有紋理合併為單一桌面映像檔。
合成器在背景中公開運作。但是,它導入了單一影格時間延遲,以充分利用 GPU 管道。在理想情況下,這並非必要,但可以流暢地系統效能波動,並協助您平衡非對稱的負載。
作業系統運作非常困難時,GPU 可能會遭到擠壓。影格轉譯到螢幕顯示的時間可能會有延遲。視硬體而定,系統可能會使用四項緩衝處理來彌補不足之處。即使緩衝時間較為深度,繪圖管線仍會出現異常。
ARC 圖形追蹤器
ChromeOS 提供一項剖析工具,可顯示緩衝區在這個系統的對齊方式、記憶體替換時間、CPU/GPU 的忙碌程度,以及應用程式在特定時間執行的動作,如下圖所示:

設定分析器
如要使用分析器,必須執行 M75 以上版本。為獲得最佳效果,請使用 Intel 裝置。
使用分析器前,請先為應用程式加上追蹤記錄。在程式碼中將 Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, "Event", <number>);
新增至要加入追蹤記錄的位置。請使用開頭為 customTrace
前置字串的 Event
。追蹤記錄訊息中不會顯示前置字串。
如要設定分析器,請按照下列步驟操作:
- 開啟開發人員模式。
- 開啟 Chrome 設定並啟用 ARC 圖形緩衝區視覺化工具。
- 前往
chrome://arc-graphics-tracing
。
執行分析器
- 選取「卡頓上的停靠站」。
- 執行 Android 應用程式。
- 在 Android 應用程式啟用且聚焦於焦點後,按下 Control + Shift + G 鍵。
發生資源浪費時,系統會彈出瀏覽器視窗。使用 W 鍵和 S 鍵可縮放及縮小時間軸。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Debug animation jank\n\nOne of the most difficult problems for app developers is\nensuring smooth, glitchless, and jank-free animation. This is especially hard to\ndebug when the system is also performing resource-intensive background\ntasks. There is no easy way to determine whether some jank is caused by your app or\nthe system. However, there is a profiler tool that can help you identify the\npossible source of the bad behavior.\n\nRender on ChromeOS\n------------------\n\nA fine-tuned app, like a game, usually uses double buffering to keep the user\nresponse time as low as possible. Still, there are many things that can degrade\nperformance. For example, if rendering a frame takes too long, the rendered\nresult is not ready for the next buffer swap, and consequently the previous\nframe repeats.\n\nThen, the renderer can't start rendering the next frame,\ncausing even more problems. This scenario is familiar to Android mobile\ndevelopers; when an app runs on ChromeOS, the context is even more complicated.\n\nAn app running on the desktop doesn't render directly to the screen's display\nframe. It renders its data into a texture instead. There are usually multiple\napps, each rendering its graphics into a texture. The system constructs the view\non the screen using a compositor to combine all the textures into a single\ndesktop image.\n\nThe compositor works transparently in the background. However, it introduces a\none-frame time delay to maximize the use of the GPU pipeline. In an ideal\nworld this might not be necessary, but it smooths system performance\nfluctuations and helps balance an asymmetrical load.\n\nWhen the OS is working very hard, the GPU might get squeezed. There can be a\ndelay from the time a frame renders to when it appears on the\nscreen. Depending on the hardware, the system might use quadruple buffering to\ncompensate. Even with deeper buffering, the graphic pipeline can still glitch.\n\nThe ARC graphics tracer\n-----------------------\n\nChromeOS has a profiling tool that shows how the buffers are percolating\nthrough the system, when memory swaps occur, how busy the CPU/GPU is, and what\nyour application is doing at a given time, shown in the following image:\n\n### Set up the profiler\n\nTo use the profiler, you must run M75 or later.\nFor best results, use an Intel device.\n\nBefore using the profiler, seed your app with traces.\nAdd `Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, \"Event\", \u003cnumber\u003e);` to your code\nwherever you'd like to include a trace. Use an `Event` that begins with\nthe prefix `customTrace`. The prefix doesn't appear in the trace message.\n\nTo set up the profiler, follow these steps:\n\n1. Turn on developer mode.\n2. Turn on Chrome settings and enable the **ARC graphic buffers visualization tool**.\n3. Navigate to `chrome://arc-graphics-tracing`.\n\n### Run the profiler\n\n1. Select **stop on jank**.\n2. Run the Android app.\n3. When the Android app is active and has focus, press \u003ckbd\u003eControl\u003c/kbd\u003e+\u003ckbd\u003eShift\u003c/kbd\u003e+\u003ckbd\u003eG\u003c/kbd\u003e.\n\nWhen some jank happens, a browser window pops up.\nUse the \u003ckbd\u003eW\u003c/kbd\u003e and \u003ckbd\u003eS\u003c/kbd\u003e keys to zoom and shrink the timeline."]]