Android省电策略及测试

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/wb96a1007/article/details/80972330
1、电源测试
----------------------------------------------------
1)查看电源状态:
adb shell dumpsys battery
Current Battery Service state:
  (UPDATES STOPPED -- use 'reset' to restart)
  mBootCompleted: true
  AC powered: false
  USB powered: false
  Wireless powered: false
  Max charging current: 0
  Max charging voltage: 0
  Charge counter: 2767936
  status: 2
  health: 2
  present: true
  level: 81
  scale: 100
  voltage: 4071
  temperature: 359
  technology: Li-ion
  batterySWSelfDischarging: false
  batteryMiscEvent: 0
  batteryCurrentEvent: 0
  mSecPlugTypeSummary: 0
  LED Charging: true
  LED Low Battery: true
  current now: -2
  charge counter: 2767936
  Adaptive Fast Charging Settings: true
USE_FAKE_BATTERY: false
SEC_FEATURE_BATTERY_SIMULATION: false
FEATURE_WIRELESS_FAST_CHARGER_CONTROL: true
  mWasUsedWirelessFastChargerPreviously: false
  mWirelessFastChargingSettingsEnable: true
LLB CAL: 20180118
LLB MAN:
LLB CURRENT: YEAR2018M6D27
LLB DIFF: 22
BatteryInfoBackUp
  mSavedBatteryAsoc: 95
  mSavedBatteryMaxTemp: 473
  mSavedBatteryMaxCurrent: 3000
  mSavedBatteryUsage: 19972
  FEATURE_SAVE_BATTERY_CYCLE: true

2)模拟未充电模式:
adb shell dumpsys battery unplug
通过命令1看是否生效
重置电源充电状态:adb shell dumpsys battery reset

3)省电模式:
adb shell settings put global low_power 1

4)API:
PowerManager.isPowerSaveMode()
PowerManager.ACTION_POWER_SAVE_MODE_CHANGED


2、后台限制
----------------------------------------------------
To simulate conditions where implicit broadcasts and background services are unavailable, enter the following command:
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore
To re-enable implicit broadcasts and background services, enter the following command:
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow

1)加入应用后台限制
appops set <package-name> RUN_IN_BACKGROUND ignore

2)移除限制
appops set <package-name> RUN_IN_BACKGROUND allow

PS:
RUN_ANY_IN_BACKGROUND:P独有?O系列报错。
RUN_IN_BACKGROUND:O及以下系列。


3、获得JobScheduler状态
----------------------------------------------------
JobScheduler与Android 6.0的Doze,总结来说就是限制应用频繁唤醒硬件,从而达到省电的效果。

1)adb shell dumpsys jobscheduler
----------------
Tracking 29:
  #1000/106603 from u0a247: Delay=-1h12m12s354ms, Deadline=-12s354ms
  #u150a34/4096 from u150a34: Delay=+9m47s771ms, Deadline=+9m47s771ms

Current stats at 2018-07-09-13-43-53 (-53m14s780ms) over +51m32s807ms:
  5012 / com.samsung.android.sm.devicesecurity.tcm: 3x pending 3x active
  5017 / com.samsung.android.samsungpositioning: 5x pending 2x active

  Job history at 2018-07-09 14:37:08.016:
       -33m32s471ms START: u0a187 com.sec.android.app.shealth/com.samsung.android.service.health.server.manifest.ManifestSyncService

Pending queue:

Active jobs:
  Slot #0: inactive since -29s596ms, stopped because: app called jobFinished
  Slot #1: inactive since -7m2s221ms, stopped because: app called jobFinished
  Slot #2: inactive since -6m2s195ms, stopped because: last work dequeued
  Slot #3: inactive since -16m7s703ms, stopped because: last work dequeued
  Slot #4: inactive since -16m7s720ms, stopped because: app called jobFinished
  Slot #5: inactive since -16m7s735ms, stopped because: last work dequeued
  Slot #6: inactive
  Slot #7: inactive
  Slot #8: inactive
  Slot #9: inactive
  Slot #10: inactive
  Slot #11: inactive
  Slot #12: inactive
  Slot #13: inactive
  Slot #14: inactive
  Slot #15: inactive

mReadyToRock=true
mReportedActive=false
mMaxActiveJobs=6

当你需要在Android设备满足某种场合才需要去执行处理数据,例如 
* 应用具有您可以推迟的非面向用户的工作(定期数据库数据更新) 
* 应用具有当插入设备时您希望优先执行的工作(充电时才希望执行的工作备份数据) 
* 需要访问网络或 Wi-Fi 连接的任务(如向服务器拉取内置数据) 
* 希望作为一个批次定期运行的许多任务

而使用JobScheduler可以很优雅的完成这些情况。

所以相比于其他方式,JobScheduler的好处是显而易见的。 
* 避免频繁的唤醒硬件模块,造成不必要的电量消耗。 
* 避免在不合适的时间(例如低电量情况下、弱网络或者移动网络情况下的)执行过多的任务(唤醒硬件)消耗电量;

2)API:
ActivityManager.isBackgroundRestricted()


4、获取alarm状态
----------------------------------------------------
当应用设置ALARM的时候,系统不会将这些ALARM在设置的准确时间内触发,而将用一种批量触发(batches mode)的策略,这样可以最小化地使系统从休眠状态醒来,最低程度地减少电池的消耗,即将一批触发时间接近的闹钟,压缩到某一个时间段内一起触发,而不是一个个触发,这样系统会很难休眠。

1)dumpsys alarm
---------------
  u0a429:com.oupeng.max.sdk +12s417ms running, 6 wakeups:
    +12s417ms 6 wakes 6 alarms, last -2m34s742ms:
      *walarm*:com.oupeng.max.sdk/com.opera.max.core.web.DataUsageMaintenanceScheduler
  u95a218:com.tencent.mobileqq +5m23s21ms running, 62 wakeups:
    +3m48s334ms 12 wakes 12 alarms, last -27m27s573ms:
      *walarm*:com.tencent.mobileqq.msf.WatchdogForInfoLogin
    +1m27s807ms 25 wakes 25 alarms, last -2m34s742ms:
      *walarm*:com.tencent.mobileqq:MSF_169734965
    +6s2ms 19 wakes 19 alarms, last -57m13s106ms:
      *walarm*:com.tencent.mobileqq:MSF_75405855
    +878ms 6 wakes 6 alarms, last -26m19s973ms:
      *walarm*:com.tencent.mobileqq:MSF_249095114
  u150a196:com.tencent.mm +5m16s304ms running, 57 wakeups:
    +5m6s783ms 0 wakes 54 alarms, last -4m13s106ms:
      *walarm*:ALARM_ACTION(25568)
    +7ms 1 wakes 1 alarms, last -4h18m18s744ms:
      *walarm*:ALARM_ACTION(9884)
    +6ms 1 wakes 1 alarms, last -4h14m30s690ms:
      *walarm*:ALARM_ACTION(30238)
  <AppSync3 Whitelist>
   (AppSync) 10240
   (AppSync) 10499
   (AppSync) 10217
   (AppSync) 10218
   (AppSync) 10222
   (AppSync) 10225
   (AppSync) 10226
   (AppSync) 9510242
   (AppSync) 10228
   (AppSync) 10230
   (AppSync) 10234
   (AppSync) 10237
   (AppSync) 10239
   (AppSync) ---------
   (AppSync) ---------
Suspicious Threshold Time : 10000[millis]
  (AppSync) com.samsung.android.messaging : 300(540)
  (AppSync) com.sec.spp.push : 1200(1200)
  (AppSync) ### 2 added ###
  Fixed Wakeups: true/true/true
  <GmsAlarmManager>
isChinaMode:true
mGmsPkgUid:10030
mVendingUid:10053
mConfigupdaterUid:10014
mWaitCheckNetWork:false
mGoogleNetWork:false
isGmsNetWorkLimt:true
mScreenOn:false
mScreenOffChange:false
deviceIdle:com.android.server.DeviceIdleController$LocalService@b6d3b65
isCharging:false
Since last 24 hours
Total time and # of event Google access is available   : 0h 0m(0X)
Total time and # of event Google access is not possible : 4h 26m(8X)
Total time and # of event VPN is connected :0h 0m(0X)



5、App Standby Buckets
----------------------------------------------------
App Standby Buckets in Android P will help further improve battery life
Battery life has been important for the developers working on Android for the last few releases. This goes beyond the typical “optimized battery life” fluff that we generally see in changelogs. Android has fundamentally changed the way it lets applications run in the background thanks to the Job Scheduler API, the evolution we’ve seen with Doze, and more. This focus isn’t changing with Android P either as noted by Dave Burke at Google I/O this week. One of these new features is being called App Standby Buckets.


The goal of App Standby Buckets is to improve the overall power management of our devices by prioritizing applications into one of four different buckets. Over time, Android will watch and see how frequently you use certain applications and then organize them into one of these buckets based on usage. The operating system will then limit the resources a device allocates to a particular application based on which bucket the application has been placed in.


1)Unplug (or adb shell dumpsys battery unplug)
2)adb shell am get-standby-bucket <package-name>


3)adb shell set-standby-bucket <package-name> <bucket>
buckets:
      10 ACTIVE:App is currently being used
      20 WOEKING_SET:App is in regular use
      30 FREQUENT:App is often used, but not every day
      40 RARE:App is not frequently used


4)API:
UsaheStatsManager.getAppStandbyBucket()

猜你喜欢

转载自blog.csdn.net/wb96a1007/article/details/80972330