Battery Historian 工具可提供裝置在一段時間內的電池效能深入分析。在系統層級中,工具會以 HTML 表示法視覺化呈現系統記錄的電力相關事件。在特定應用程式層級,工具會提供多種不同的資料,協助您辨識比較耗電的應用程式行為。
本文說明幾種使用 Battery Historian 的方式,讓您可用以瞭解電池耗電的模式。一開始我們會先說明如何解讀 Battery Historian 報表中的系統通盤資料,然後會說明幾種使用 Battery Historian 的方式,協助您用以診斷及排解應用程式與電池耗電的相關行為問題。最後,文章中還會指出幾個特別適合使用 Battery Historian 的使用情境,並分享操作秘訣。
使用系統通盤檢視
Battery Historian 工具可針對多種不同的應用程式和系統行為,提供系統通盤視覺化內容檢視,並且說明這些行為在一段時間內與電池耗電量之間的關係。如圖 1 所示,此檢視畫面可協助您診斷和辨識應用程式的電力使用相關問題。
圖 1. Battery Historian 顯示,遍及全系統的事件影響電力消耗的情況。
此圖焦點是水平向下的黑色趨勢線條,其代表電池電量,以 Y 軸表示。舉例來說,在電池電量線的起始處,時間約是早上 6:50 的地方,畫面顯示電池電量出現相對陡降的情況。
圖 2 為圖片中該部分的放大檢視。
圖 2. 早上 6:50 到 7:20 之間的 Battery Historian 時間軸放大圖。
在電池電量線的起始處,電池電量開始急遽下降,畫面顯示當時發生了三件事:CPU 正在執行、應用程式取得了喚醒鎖定,而且螢幕也已經開啟。因此,您只要查看 Battery Historian 就可以瞭解電池耗電量很高的時候發生了哪些事件;並在應用程式中針對這些行為展開調查,瞭解是否能採行相關的最佳化作業。
系統通盤視覺化資料也可以提供其他線索。舉例來說,如果資料顯示行動無線電經常開關,也許您可以透過智慧型排程 API (例如:JobScheduler 或 Firebase Job Dispatcher),針對這種行為進行最佳化。
下一節我們將說明如何調查應用程式特定的行為和事件。
檢視應用程式特定資料
除了系統的通盤檢視畫面會提供宏觀資料,Battery Historian 還會另外針對在裝置中執行的各個應用程式,提供個別表格和某些視覺化資料。表格資料包括:
裝置上應用程式的預估耗電量。
網路資訊。
喚醒鎖定次數。
服務。
處理程序資訊。
表格會提供應用程式的兩種資料維度。首先,您可以查看您的應用程式與其他應用程式的電力使用比較。若要執行此操作,請按一下「Tables」下方的「Device Power Estimates」。此範例以虛構的應用程式「Pug Power」為例。
圖 3. 調查哪些應用程式消耗最多電力。
圖 3 中的表格顯示,Pug Power 是莊志忠耗電量排名第九的應用程式,也是非 OS 中排名第三的應用程式。根據此資料顯示,這個應用程式應進行更深入的調查。
[[["容易理解","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,["# Analyze power use with Battery Historian\n\n| **Warning:** Battery Historian is no longer actively maintained; if possible, consider using [system tracing](/topic/performance/tracing), the [Macrobenchmark power metric](/topic/performance/benchmarking/macrobenchmark-metrics#power), or the [Power Profiler](/studio/profile/power-profiler) to get insights into battery performance.\n\nThe Battery Historian tool provides insight into a device's battery consumption\nover time. At a system-wide level, the tool visualizes power-related events from\nthe system logs in an HTML representation. At an app-specific level, the tool\nprovides a variety of data that can help you identify battery-draining app\nbehavior.\n\nThis document describes some of the ways you can use Battery Historian to learn\nabout battery-consumption patterns. The document begins by explaining how to\nread the system-wide data that Battery Historian reports. Then, it presents ways\nin which you can use Battery Historian to diagnose and troubleshoot your own\napp's behavior related to battery consumption. Last, it offers several tips on\nscenarios in which Battery Historian may be particularly useful.\n\nUse the system-wide view\n------------------------\n\nThe Battery Historian tool provides a system-wide visualization of various app\nand system behaviors, along with their correlation against battery consumption\nover time. This view, shown in Figure 1, can help you diagnose and identify\npower use issues with your app.\n**Figure 1.** Battery Historian's display of system-wide events affecting power consumption.\n\nOf particular interest in this figure is the black, horizontal, downward trend\nline representing Battery Level, measured on the y-axis. For example, at the\nvery beginning of the Battery Level line, at approximately 6:50 AM, the\nvisualization shows a relatively steep drop in battery level.\n\nFigure 2 provides a close-up of that part of the display.\n**Figure 2.** A close-up of the Battery Historian timeline from roughly 6:50 AM to 7:20 AM.\n\nAt the very beginning of the Battery Level line, as battery decline steeply, the\ndisplay shows three things happening: The CPU is running, an app has acquired a\nwakelock, and the screen is on. In this way, Battery Historian helps you\nunderstand what events are happening when battery consumption is high. You can\nthen target these behaviors in your app and investigate whether there are\nrelated optimizations you can make.\n\nThe system-wide visualization can provide other clues, as well. For instance, if\nit shows that the mobile radio is frequently being turned off and on, there may\nbe an opportunity to optimize this behavior through\n[intelligent scheduling APIs](/topic/performance/scheduling) such as\nJobScheduler or Firebase Job Dispatcher.\n\nThe next section explains how to investigate behavior and events specific to\nyour own app.\n\nView app-specific data\n----------------------\n\nIn addition to the macro-level data provided by the system-wide view, Battery\nHistorian also provides tables and some visualization of data specific to each\napp running on your device. The tabular data includes:\n\n- The app's estimated power use on the device.\n- Network information.\n- Wakelocks.\n- Services.\n- Process info.\n\nThe tables provide two dimensions of data about your app. First, you can look up\nwhere your app's power usage ranks compared to other apps. To do so, click\n*Device Power Estimates* table under *Tables*. This example examines a fictional\napp called Pug Power.\n**Figure 3.** Investigating which apps consume the most power.\n\nThe table in Figure 3 reveals that Pug Power is the ninth biggest consumer of\nbattery power on this device, and the third biggest app that is not part of the\nOS. This data suggests that this app bears deeper investigation.\n\nTo look up the data for a specific app, enter its package name into the lower of\nthe two dropdown menus under *App Selection*, located under the left side of the\nvisualization.\n**Figure 4.** Entering a specific app whose data to view.\n\nWhen you select a specific app, the following data visualization categories\nchange to display app-specific data instead of system-wide data:\n\n- SyncManager.\n- Foreground process.\n- Userspace Wakelock.\n- Top app.\n- JobScheduler.\n- Activity Manager Proc.\n\nThe SyncManager and JobScheduler visualizations immediately make it obvious if\nyour app performs syncs and executes jobs more frequently than necessary. In\ndoing so, they can quickly reveal an opportunity to optimize your app's behavior\nfor improved battery performance.\n\nYou can also obtain one more piece of app-specific visualization data,\n*Userspace Wakelock*. To include this information in the bug report, enter the\nfollowing command in your terminal window: \n\n $ adb shell dumpsys batterystats --enable full-wake-history\n\n| **Note:** From Android 6.0 (API level 23), the platform includes Doze functionality, which imposes certain optimizations on apps. For example, Doze batches jobs to take place during brief maintenance windows, regardless of how JobScheduler has scheduled them.\n\nFigures 5 and 6 show data for Pug Power: Figure 5 shows the visualization of the\napp-specific data, and Figure 6 shows the corresponding tabular data.\n**Figure 5.** Visualization of data for fictional app Pug Power.\n\n\u003cbr /\u003e\n\n\n\u003cbr /\u003e\n\n**Figure 6.** Tabular data for the fictional Pug Power app.\n\nA look at the visualization does not show anything immediately obvious. The\nJobScheduler line shows that the app has no jobs scheduled. The SyncManager line\nshows that the app has not performed any syncs.\n\nHowever, examination of the *Wakelocks* segment of the tabular data reveals that\nPug Power acquires wakelocks totaling over an hour. This unusual and costly\nbehavior can account for the app's high level of power consumption. This piece\nof information helps the developer target an area where optimization is likely\nto greatly help. In this case, why does the app acquire so much wakelock time,\nand how can the developer ameliorate this behavior?\n\nOther cases where Battery Historian can help\n--------------------------------------------\n\nThere are many other cases in which Battery Historian can help you diagnose\nopportunities for improving battery behavior. For example, Battery Historian can\ntell you if your app is:\n\n- Firing wakeup alarms overly frequently (every 10 seconds or less).\n- Continuously holding a GPS lock.\n- Scheduling jobs every 30 seconds or less.\n- Scheduling syncs every 30 seconds or less.\n- Using the cellular radio more frequently than you expect."]]