Android P 应用分组介绍

简介

在Android P 中针对电源管理,添加了应用分组功能.依据应用使用的频率和最近一次使用时间,对其资源请求进行优先级排序。 应用待机分组一共有五个分组,系统会根据每个应用的使用情况,将其划分至五个优先分组中的一个,而每个分组对设备资源 的调度各有不同的限制。

1 优先分组

系统动态的分配应用到不同的组,在不同的组会有不同的限制.应用活跃度越高,所处分组的优先级就越高,也就相应地更容易 获取设备资源。尤其是,应用所处的的群组决定了其所安排的任务 (job),触发标准闹铃以及接受高优先级Firebase Cloud Messagesing信息的频率。这些限制只有在非充电状态才有效(adb shell dumpsys battery unplug),在跑Monkey时,也不会影响 动态的分组,在充电状态下应用的行为不会受到限制.

至于如何分组,要看手机厂商制定什么规则,默认的规则是根据应用的近期使用情况进行等级划分。厂商也可以使用机器学习对 应用的使用情况进行预测,将应用放在不同优先级的组.

1.1 组的介绍

Power management restrictions中, 对不同的组有相关的介绍.

app_standby_bucket

主要将应用分成4各组:

  • 活跃 (Active): 应用正在被使用
  • 工作 (Working set): 应用使用频率很高
  • 常用 (Frequent): 应用经常但不是每天被使用
  • 极少 (Rare): 应用偶尔被使用

活跃 (Active)

活跃应用的定义:

  • 应用启动了一个Activity;
  • 应用正在运行前台服务;
  • 另一个前台应用已关联至该应用 (通过同步适配器与前台应用的内容提供器相关联);
  • 用户点击了应用的推送

在任务、标准闹铃以及FCM信息的资源调用上,活跃群组应用免受任何系统限制。

工作 (Working set)

工作组定义:

  • 若应用的运行频率很高,但目前并未处于“活跃”状态,它就会被划分至工作群组,例如用户常用的社交媒体应用。
  • 该群组还包括了那些被间接使用的应用。

工作分组内的应用会在任务 (job) 运行和闹铃触发方面受到部分系统限制.

豁免(Exempted)

豁免组的定义:

  • 应用在whitelist中,永远不会进入standby状态,所有的行为也不会被限制

常用 (Frequent)

常用组的定义:

  • 常用应用指用户经常使用但不是每天使用的应用,比如用户在健身房使用的打卡应用可能就属于这一群组。

系统对常用分组采用的限制更强,应用运行任务(job)和触发闹铃的能力都会受到影响,而且接受的高优先性FCM消息也有数量上限.

极少 (Rare)

极少组的定义:

  • 若应用的使用频率很低,它就会被划分至该分组,酒店应用就是一个很好的例子——用户只有在下榻这个酒店的时候才会打开此应用。

该群组下的应用在任务 (job)、闹铃和高优先性FCM消息的资源调用上都会受到严格的限制。此外,网络访问能力也会受到影响。

从不(Never)

  • 应用安装后从来没有打开过

1.2 查看与设置应用分组

1.2.1 应用代码里查看自身当前所在的分组

APP在代码里查看自身所在的分组,使用接口UsageStatsManager.getAppStandbyBucket(). 该接口调用的是源码里面的 AOSP/frameworks/base/core/java/android/app/usage/UsageStatsManager.java

  1. /**
  2. * Returns the current standby bucket of the calling app. The system determines the standby
  3. * state of the app based on app usage patterns. Standby buckets determine how much an app will
  4. * be restricted from running background tasks such as jobs and alarms.
  5. * <p>Restrictions increase progressively from {@link #STANDBY_BUCKET_ACTIVE} to
  6. * {@link #STANDBY_BUCKET_RARE}, with {@link #STANDBY_BUCKET_ACTIVE} being the least
  7. * restrictive. The battery level of the device might also affect the restrictions.
  8. * <p>Apps in buckets &le; {@link #STANDBY_BUCKET_ACTIVE} have no standby restrictions imposed.
  9. * Apps in buckets &gt; {@link #STANDBY_BUCKET_FREQUENT} may have network access restricted when
  10. * running in the background.
  11. * <p>The standby state of an app can change at any time either due to a user interaction or a
  12. * system interaction or some algorithm determining that the app can be restricted for a period
  13. * of time before the user has a need for it.
  14. * <p>You can also query the recent history of standby bucket changes by calling
  15. * {@link #queryEventsForSelf(long, long)} and searching for
  16. * {@link UsageEvents.Event#STANDBY_BUCKET_CHANGED}.
  17. *
  18. * @return the current standby bucket of the calling app. One of STANDBY_BUCKET_* constants.
  19. */
  20. public @StandbyBuckets int getAppStandbyBucket() {
  21. try {
  22. return mService.getAppStandbyBucket(mContext.getOpPackageName(),
  23. mContext.getOpPackageName(),
  24. mContext.getUserId());
  25. } catch (RemoteException e) {
  26. }
  27. return STANDBY_BUCKET_ACTIVE;
  28. }

从代码里显示,通过mService(对应的是UsageStatsService, 源码在AOSP/frameworks/base/services/usage/java/com/android/server/usage/UsageStatsService.java), 获取the calling app的所在分组,如果获取失败,就返回STANDBY_BUCKET_ACTIVE, 也就是认为应用是活跃的,不会对其进行限制.从源码角度,我们看到app侧只能查看自身所 处的分组,而不能查看其他分组.

1.2.2 使用 am 命令查看和设置app的分组

使用am命令可以设置和查看app的分组, 命令使用说明:

  1. set-standby-bucket [--user <USER_ID>] <PACKAGE> active|working_set|frequent|rare
  2. Puts an app in the standby bucket.
  3. get-standby-bucket [--user <USER_ID>] <PACKAGE>
  4. Returns the standby bucket of an app.

获取所有的应用的分组:

  1. am get-standby-bucket

结果:

  1. com.android.wallpaperbackup: 5
  2. com.android.providers.blockednumber: 40
  3. com.android.providers.userdictionary: 40
  4. com.google.vr.apps.ornament: 40
  5. com.android.emergency: 40
  6. com.google.android.inputmethod.japanese: 40
  7. com.android.location.fused: 5
  8. com.android.systemui: 30

active|working_set|frequent|rare 分别对应 10|20|30|40 , 至于里面不是这4个数字的,是属于系统内部的分组, 不涉及三方apk分组.

除了set-standby-bucket, 和get-standby-bucket,还有两个am命令,也会更改app的分组:

  1. set-inactive [--user <USER_ID>] <PACKAGE> true|false
  2. Sets the inactive state of an app.
  3. get-inactive [--user <USER_ID>] <PACKAGE>
  4. Returns the inactive state of an app.

设置set-inactive [--user <USER_ID>] <PACKAGE> true , 会将设置为40. 设置set-inactive [--user <USER_ID>] <PACKAGE> false , 会将设置为10.

由此,可以看出,android P中将原来一刀切形式的 app standby 合并到了应用分组中了.

2 系统层面的源码实现

前面,我们已经提到系统动态的调整app的组,接下来我们分析一下, 看系统层面是怎样实现的.

2.1 设置app的bucket

设置app的bucket,经过层层调用,最终都调用到AppStandbyController中的reportEvent函数. 在ActivityManagerService/NotificationManagerService 中都有调用到.

在NotificationManagerService中的调用;

  1. private UsageStatsManagerInternal mAppUsageStats;
  2. mAppUsageStats.reportEvent(r.sbn.getPackageName(),
  3. getRealUserId(r.sbn.getUserId()),
  4. UsageEvents.Event.USER_INTERACTION);

在AMS中有调用代码如下:

  1. UsageStatsManagerInternal mUsageStatsService;
  2. mUsageStatsService.reportEvent(component.realActivity, component.userId,
  3. UsageEvents.Event.MOVE_TO_FOREGROUND);

这里我们以ActivityManagerService的调用为分析线路.

来看frameworks/base/core/java/android/app/usage/UsageStatsManagerInternal.java :

  1. public abstract class UsageStatsManagerInternal {
  2. /**
  3. * Reports an event to the UsageStatsManager.
  4. *
  5. * @param component The component for which this event occurred.
  6. * @param userId The user id to which the component belongs to.
  7. * @param eventType The event that occurred. Valid values can be found at
  8. * {@link UsageEvents}
  9. */
  10. public abstract void reportEvent(ComponentName component, @UserIdInt int userId, int eventType);
  11. /**
  12. * Reports an event to the UsageStatsManager.
  13. *
  14. * @param packageName The package for which this event occurred.
  15. * @param userId The user id to which the component belongs to.
  16. * @param eventType The event that occurred. Valid values can be found at
  17. * {@link UsageEvents}
  18. */
  19. public abstract void reportEvent(String packageName, @UserIdInt int userId, int eventType);
  20. }

只是一个抽象的接口,具体实现在frameworks/base/services/usage/java/com/android/server/usage/UsageStatsService.java

  1. /**
  2. * This local service implementation is primarily used by ActivityManagerService.
  3. * ActivityManagerService will call these methods holding the 'am' lock, which means we
  4. * shouldn't be doing any IO work or other long running tasks in these methods.
  5. */
  6. private final class LocalService extends UsageStatsManagerInternal {
  7. @Override
  8. public void reportEvent(ComponentName component, int userId, int eventType) {
  9. if (component == null) {
  10. Slog.w(TAG, "Event reported without a component name");
  11. return;
  12. }
  13. UsageEvents.Event event = new UsageEvents.Event();
  14. event.mPackage = component.getPackageName();
  15. event.mClass = component.getClassName();
  16. // This will later be converted to system time.
  17. event.mTimeStamp = SystemClock.elapsedRealtime();
  18. event.mEventType = eventType;
  19. mHandler.obtainMessage(MSG_REPORT_EVENT, userId, 0, event).sendToTarget();// 重点
  20. }
  21. @Override
  22. public void reportEvent(String packageName, int userId, int eventType) {
  23. if (packageName == null) {
  24. Slog.w(TAG, "Event reported without a package name");
  25. return;
  26. }
  27. UsageEvents.Event event = new UsageEvents.Event();
  28. event.mPackage = packageName;
  29. // This will later be converted to system time.
  30. event.mTimeStamp = SystemClock.elapsedRealtime();
  31. event.mEventType = eventType;
  32. mHandler.obtainMessage(MSG_REPORT_EVENT, userId, 0, event).sendToTarget();
  33. }
  34. }

mHandler.obtainMessage(MSG_REPORT_EVENT, userId, 0, event).sendToTarget(), 调用到:

  1. /**
  2. * Called by the Binder stub.
  3. */
  4. void reportEvent(UsageEvents.Event event, int userId) {
  5. // SPRD: bug702053, cancel event record while monkey test.
  6. ActivityManagerService am = (ActivityManagerService)ActivityManager.getService();
  7. if (am.isUserAMonkeyNoCheck()) {
  8. if (DEBUG) {
  9. Slog.i(TAG, "->reportEvent event:" + event + ", userId:" + userId
  10. + ", monkey test return directly");
  11. }
  12. return;
  13. }
  14. synchronized (mLock) {
  15. final long timeNow = checkAndGetTimeLocked();
  16. final long elapsedRealtime = SystemClock.elapsedRealtime();
  17. convertToSystemTimeLocked(event);
  18. if (event.getPackageName() != null
  19. && mPackageManagerInternal.isPackageEphemeral(userId, event.getPackageName())) {
  20. event.mFlags |= Event.FLAG_IS_PACKAGE_INSTANT_APP;
  21. }
  22. final UserUsageStatsService service =
  23. getUserDataAndInitializeIfNeededLocked(userId, timeNow);
  24. service.reportEvent(event); // 检查app的bucket,详见2.3
  25. // NOTE: Bug #627645 low power Feature BEG-->
  26. if (mPowerControllerHelper != null) {
  27. mPowerControllerHelper.reportEvent(event, userId, elapsedRealtime);
  28. }
  29. // <-- NOTE: Bug #627645 low power Feature END
  30. mAppStandby.reportEvent(event, elapsedRealtime, userId); // 重点
  31. switch (event.mEventType) {
  32. case Event.MOVE_TO_FOREGROUND:
  33. mAppTimeLimit.moveToForeground(event.getPackageName(), event.getClassName(),
  34. userId);
  35. break;
  36. case Event.MOVE_TO_BACKGROUND:
  37. mAppTimeLimit.moveToBackground(event.getPackageName(), event.getClassName(),
  38. userId);
  39. break;
  40. }
  41. }
  42. }

mAppStandby.reportEvent, 就调用到 frameworks/base/services/usage/java/com/android/server/usage/AppStandbyController.java AppStandbyController是应用分组功能的核心部件,用于控制应用分组的, 系统默认的动态分组的规则就在该部件中.

  1. void reportEvent(UsageEvents.Event event, long elapsedRealtime, int userId) {
  2. if (!mAppIdleEnabled) return; // mAppIdleEnabled 是使能应用分组功能的开关
  3. synchronized (mAppIdleLock) {
  4. // TODO: Ideally this should call isAppIdleFiltered() to avoid calling back
  5. // about apps that are on some kind of whitelist anyway.
  6. final boolean previouslyIdle = mAppIdleHistory.isIdle(
  7. event.mPackage, userId, elapsedRealtime);
  8. // Inform listeners if necessary
  9. if ((event.mEventType == UsageEvents.Event.MOVE_TO_FOREGROUND // 表示一个组件移动到前台
  10. || event.mEventType == UsageEvents.Event.MOVE_TO_BACKGROUND // 标示一个组件移动到后台
  11. || event.mEventType == UsageEvents.Event.SYSTEM_INTERACTION // 该package以某种方式在和系统交互
  12. || event.mEventType == UsageEvents.Event.USER_INTERACTION // 该package以某种方式和用户交互
  13. || event.mEventType == UsageEvents.Event.NOTIFICATION_SEEN // 一个可见的通知
  14. || event.mEventType == UsageEvents.Event.SLICE_PINNED // slice 是android P的新特性, 被一个app 钉住的slice
  15. || event.mEventType == UsageEvents.Event.SLICE_PINNED_PRIV)) { // 一个slice被默认的launcher或者assistant钉住
  16. final AppUsageHistory appHistory = mAppIdleHistory.getAppUsageHistory( // AppUsageHistory 存储了该用户使用该包一些数据
  17. event.mPackage, userId, elapsedRealtime);
  18. final int prevBucket = appHistory.currentBucket;
  19. final int prevBucketReason = appHistory.bucketingReason;
  20. final long nextCheckTime;
  21. final int subReason = usageEventToSubReason(event.mEventType);
  22. final int reason = REASON_MAIN_USAGE | subReason;
  23. if (event.mEventType == UsageEvents.Event.NOTIFICATION_SEEN
  24. || event.mEventType == UsageEvents.Event.SLICE_PINNED) {
  25. // Mild usage elevates to WORKING_SET but doesn't change usage time. // 不改变usage time 什么意思???
  26. // mAppIdleHistory.reportUsage 作用是改变app的组, 如果要改变的新组别优先级比原来低, 就不会修改
  27. mAppIdleHistory.reportUsage(appHistory, event.mPackage,
  28. STANDBY_BUCKET_WORKING_SET, subReason,// 提升到STANDBY_BUCKET_WORKING_SET
  29. 0, elapsedRealtime + mNotificationSeenTimeoutMillis);
  30. nextCheckTime = mNotificationSeenTimeoutMillis; // 12 小时
  31. } else if (event.mEventType == UsageEvents.Event.SYSTEM_INTERACTION) {
  32. mAppIdleHistory.reportUsage(appHistory, event.mPackage,
  33. STANDBY_BUCKET_ACTIVE, subReason,// 提升到 STANDBY_BUCKET_ACTIVE
  34. 0, elapsedRealtime + mSystemInteractionTimeoutMillis);
  35. nextCheckTime = mSystemInteractionTimeoutMillis;// 10 分钟
  36. } else { // 除了以上 3 种情况, 其他情况在此设置nextCheckTime
  37. mAppIdleHistory.reportUsage(appHistory, event.mPackage,
  38. STANDBY_BUCKET_ACTIVE, subReason,
  39. elapsedRealtime, elapsedRealtime + mStrongUsageTimeoutMillis);
  40. nextCheckTime = mStrongUsageTimeoutMillis; // 1 小时
  41. }
  42. mHandler.sendMessageDelayed(mHandler.obtainMessage
  43. (MSG_CHECK_PACKAGE_IDLE_STATE, userId, -1, event.mPackage),
  44. nextCheckTime); // 延时进行idle状态的检测和更新
  45. final boolean userStartedInteracting =
  46. appHistory.currentBucket == STANDBY_BUCKET_ACTIVE &&
  47. prevBucket != appHistory.currentBucket &&
  48. (prevBucketReason & REASON_MAIN_MASK) != REASON_MAIN_USAGE;
  49. maybeInformListeners(event.mPackage, userId, elapsedRealtime,
  50. appHistory.currentBucket, reason, userStartedInteracting);
  51. if (previouslyIdle) {
  52. notifyBatteryStats(event.mPackage, userId, false);
  53. }
  54. }
  55. }
  56. }

这里先说一下mAppIdleEnabled, 找到设置该值的方法:

  1. void setAppIdleEnabled(boolean enabled) {
  2. mAppIdleEnabled = enabled;
  3. }

调用该方法的位置:

  1. // Check if app_idle_enabled has changed
  2. setAppIdleEnabled(mInjector.isAppIdleEnabled());

mInjector的类型是Injector, 这是一个AppStandbyController.java里的static class,isAppIdleEnabled实现在下面:

  1. boolean isAppIdleEnabled() {
  2. final boolean buildFlag = mContext.getResources().getBoolean(
  3. com.android.internal.R.bool.config_enableAutoPowerModes);
  4. final boolean runtimeFlag = Global.getInt(mContext.getContentResolver(),
  5. Global.APP_STANDBY_ENABLED, 1) == 1
  6. && Global.getInt(mContext.getContentResolver(),
  7. Global.ADAPTIVE_BATTERY_MANAGEMENT_ENABLED, 1) == 1;
  8. return buildFlag && runtimeFlag;
  9. }

mAppIdleEnabled是否为true(打开bucket功能), 要看config_enableAutoPowerModes 和 Global.ADAPTIVE_BATTERY_MANAGEMENT_ENABLED来决定. buildFlag获取的是资源文件里的配置config_enableAutoPowerModes, 该配置在frameworks/base/core/res/res/values/config.xml:

  1. <!-- Set this to true to enable the platform's auto-power-save modes like doze and
  2. app standby. These are not enabled by default because they require a standard
  3. cloud-to-device messaging service for apps to interact correctly with the modes
  4. (such as to be able to deliver an instant message to the device even when it is
  5. dozing). This should be enabled if you have such services and expect apps to
  6. correctly use them when installed on your device. Otherwise, keep this disabled
  7. so that applications can still use their own mechanisms. -->
  8. <bool name="config_enableAutoPowerModes">false</bool>

ADAPTIVE_BATTERY_MANAGEMENT_ENABLED和省电模式相关, 在android P中在省电模式下,所有的后台运行的app都将受到限制.

回到reportEvent的的异步消息处理,MSG_CHECK_PACKAGE_IDLE_STATE:

  1. case MSG_CHECK_PACKAGE_IDLE_STATE:
  2. checkAndUpdateStandbyState((String) msg.obj, msg.arg1, msg.arg2,
  3. mInjector.elapsedRealtime());

调用了checkAndUpdateStandbyState方法:

  1. /** Check if we need to update the standby state of a specific app. */
  2. private void checkAndUpdateStandbyState(String packageName, @UserIdInt int userId,
  3. int uid, long elapsedRealtime) {
  4. // 包是由于一些原因在白名单,那么isAppSpecial会返回true, 包将不会进入standby状态
  5. final boolean isSpecial = isAppSpecial(packageName,
  6. UserHandle.getAppId(uid),
  7. userId);
  8. if (isSpecial) { // 对于豁免的app, 做特别的处理
  9. synchronized (mAppIdleLock) {
  10. // STANDBY_BUCKET_EXEMPTED 的值是5, 使用am get-standby-bucket 命令查看,
  11. // 一些package显示是5,就是说明是在whitelist
  12. mAppIdleHistory.setAppStandbyBucket(packageName, userId, elapsedRealtime,
  13. STANDBY_BUCKET_EXEMPTED, REASON_MAIN_DEFAULT);
  14. }
  15. // 通知监听者, 这是一个豁免的package
  16. maybeInformListeners(packageName, userId, elapsedRealtime,
  17. STANDBY_BUCKET_EXEMPTED, REASON_MAIN_DEFAULT, false);
  18. } else { // 没有在白名单里的app走的分支
  19. synchronized (mAppIdleLock) {
  20. final AppIdleHistory.AppUsageHistory app =
  21. mAppIdleHistory.getAppUsageHistory(packageName,
  22. userId, elapsedRealtime);
  23. int reason = app.bucketingReason;
  24. final int oldMainReason = reason & REASON_MAIN_MASK;
  25. // If the bucket was forced by the user/developer, leave it alone.
  26. // A usage event will be the only way to bring it out of this forced state
  27. // 如果的bucket的设置原因是被用户或者开发者,强制设置的,将不会改变它的组别
  28. if (oldMainReason == REASON_MAIN_FORCED) {
  29. return;
  30. }
  31. final int oldBucket = app.currentBucket;
  32. // 动态调整buncket, 最高等级只能设置到 10 , 也就是STANDBY_BUCKET_ACTIVE
  33. int newBucket = Math.max(oldBucket, STANDBY_BUCKET_ACTIVE); // Undo EXEMPTED
  34. boolean predictionLate = predictionTimedOut(app, elapsedRealtime);
  35. // Compute age-based bucket
  36. if (oldMainReason == REASON_MAIN_DEFAULT
  37. || oldMainReason == REASON_MAIN_USAGE
  38. || oldMainReason == REASON_MAIN_TIMEOUT
  39. || predictionLate) {
  40. if (!predictionLate && app.lastPredictedBucket >= STANDBY_BUCKET_ACTIVE
  41. && app.lastPredictedBucket <= STANDBY_BUCKET_RARE) {
  42. newBucket = app.lastPredictedBucket;
  43. reason = REASON_MAIN_PREDICTED | REASON_SUB_PREDICTED_RESTORED;
  44. if (DEBUG) {
  45. Slog.d(TAG, "Restored predicted newBucket = " + newBucket);
  46. }
  47. } else {
  48. // 获取package应该在的新组, 这里不是当前的组, 而是将来的应该在的组别
  49. // getBucketForLocked 是一个核心的方法
  50. newBucket = getBucketForLocked(packageName, userId,
  51. elapsedRealtime);
  52. if (DEBUG) {
  53. Slog.d(TAG, "Evaluated AOSP newBucket = " + newBucket);
  54. }
  55. reason = REASON_MAIN_TIMEOUT;
  56. }
  57. }
  58. // Check if the app is within one of the timeouts for forced bucket elevation
  59. final long elapsedTimeAdjusted = mAppIdleHistory.getElapsedTime(elapsedRealtime);
  60. if (newBucket >= STANDBY_BUCKET_ACTIVE
  61. && app.bucketActiveTimeoutTime > elapsedTimeAdjusted) {
  62. newBucket = STANDBY_BUCKET_ACTIVE;
  63. reason = app.bucketingReason;
  64. if (DEBUG) {
  65. Slog.d(TAG, " Keeping at ACTIVE due to min timeout");
  66. }
  67. } else if (newBucket >= STANDBY_BUCKET_WORKING_SET
  68. && app.bucketWorkingSetTimeoutTime > elapsedTimeAdjusted) {
  69. newBucket = STANDBY_BUCKET_WORKING_SET;
  70. // If it was already there, keep the reason, else assume timeout to WS
  71. reason = (newBucket == oldBucket)
  72. ? app.bucketingReason
  73. : REASON_MAIN_USAGE | REASON_SUB_USAGE_ACTIVE_TIMEOUT;
  74. if (DEBUG) {
  75. Slog.d(TAG, " Keeping at WORKING_SET due to min timeout");
  76. }
  77. }
  78. if (DEBUG) {
  79. Slog.d(TAG, " Old bucket=" + oldBucket
  80. + ", newBucket=" + newBucket);
  81. }
  82. if (oldBucket < newBucket || predictionLate) { // 注意 这里的oldBucket < newBucket, 说明新的组是降优先级的组别
  83. mAppIdleHistory.setAppStandbyBucket(packageName, userId, // 设置新的bucket
  84. elapsedRealtime, newBucket, reason);
  85. maybeInformListeners(packageName, userId, elapsedRealtime,
  86. newBucket, reason, false);
  87. }
  88. }
  89. }
  90. }

checkAndUpdateStandbyState 方法的作用就是,找出真正需要设置新的buncket的app,然后调用getBucketForLocked,获取新的bucket名称, 再调用mAppIdleHistory.setAppStandbyBucket 改变package的bucket, 并通知所有的监听者.

在这个方法里, 还要继续探究的就是getBucketForLocked 方法:

  1. /**
  2. * Evaluates next bucket based on time since last used and the bucketing thresholds.
  3. * @param packageName the app
  4. * @param userId the user
  5. * @param elapsedRealtime as the name suggests, current elapsed time
  6. * @return the bucket for the app, based on time since last used
  7. */
  8. @GuardedBy("mAppIdleLock")
  9. @StandbyBuckets int getBucketForLocked(String packageName, int userId,
  10. long elapsedRealtime) {
  11. int bucketIndex = mAppIdleHistory.getThresholdIndex(packageName, userId,
  12. elapsedRealtime, mAppStandbyScreenThresholds, mAppStandbyElapsedThresholds);
  13. return THRESHOLD_BUCKETS[bucketIndex];
  14. }

THRESHOLD_BUCKETS的定义如下:

  1. static final int[] THRESHOLD_BUCKETS = {
  2. STANDBY_BUCKET_ACTIVE,
  3. STANDBY_BUCKET_WORKING_SET,
  4. STANDBY_BUCKET_FREQUENT,
  5. STANDBY_BUCKET_RARE
  6. };

从mAppIdleHistory.getThresholdIndex获取一个index,让后在THRESHOLD_BUCKETS查找到对应的组别.在getThresholdIndex( packageName, userId, elapsedRealtime, mAppStandbyScreenThresholds, mAppStandbyElapsedThresholds);中,有两个Threshold: mAppStandbyScreenThresholdsmAppStandbyElapsedThresholds :

  1. long[] mAppStandbyScreenThresholds = SCREEN_TIME_THRESHOLDS;
  2. long[] mAppStandbyElapsedThresholds = ELAPSED_TIME_THRESHOLDS;
  3. static final boolean COMPRESS_TIME = false;
  4. private static final long ONE_MINUTE = 60 * 1000;
  5. private static final long ONE_HOUR = ONE_MINUTE * 60;
  6. private static final long ONE_DAY = ONE_HOUR * 24;
  7. static final long[] SCREEN_TIME_THRESHOLDS = {
  8. 0,
  9. 0,
  10. COMPRESS_TIME ? 120 * 1000 : 1 * ONE_HOUR,
  11. COMPRESS_TIME ? 240 * 1000 : 2 * ONE_HOUR
  12. };
  13. static final long[] ELAPSED_TIME_THRESHOLDS = {
  14. 0,
  15. COMPRESS_TIME ? 1 * ONE_MINUTE : 12 * ONE_HOUR,
  16. COMPRESS_TIME ? 4 * ONE_MINUTE : 24 * ONE_HOUR,
  17. COMPRESS_TIME ? 16 * ONE_MINUTE : 48 * ONE_HOUR
  18. };

接下来分析getThresholdIndex函数的具体实现, 该方法在frameworks/base/services/usage/java/com/android/server/usage/AppIdleHistory.java:

  1. /**
  2. * Returns the index in the arrays of screenTimeThresholds and elapsedTimeThresholds
  3. * that corresponds to how long since the app was used.
  4. * @param packageName
  5. * @param userId
  6. * @param elapsedRealtime current time
  7. * @param screenTimeThresholds Array of screen times, in ascending order, first one is 0
  8. * @param elapsedTimeThresholds Array of elapsed time, in ascending order, first one is 0
  9. * @return The index whose values the app's used time exceeds (in both arrays)
  10. */
  11. int getThresholdIndex(String packageName, int userId, long elapsedRealtime,
  12. long[] screenTimeThresholds, long[] elapsedTimeThresholds) {
  13. ArrayMap<String, AppUsageHistory> userHistory = getUserHistory(userId);
  14. AppUsageHistory appUsageHistory = getPackageHistory(userHistory, packageName,
  15. elapsedRealtime, false);
  16. // If we don't have any state for the app, assume never used
  17. // 对于从来没有使用过的app , 就设置成最低级别的bucket, STANDBY_BUCKET_RARE
  18. if (appUsageHistory == null) return screenTimeThresholds.length - 1;
  19. // getScreenOnTime(elapsedRealtime) 获取设备的总亮屏时间(有记录在案的时间)
  20. // appUsageHistory.lastUsedScreenTime app最后一次亮屏时间点,基于ScreenOn basetime
  21. // screenOnDelta 计算出来就是app最后一次亮屏使用,到现在,已经有多久的亮屏时间
  22. // getElapsedTime(elapsedRealtime) 获取是被从bron开始现在的时间
  23. // appUsageHistory.lastUsedElapsedTime 基于ElapsedTime该package最后一次使用的时间点
  24. // elapsedDelta 计算出来就是app最后一次使用到现在的时间点
  25. long screenOnDelta = getScreenOnTime(elapsedRealtime) - appUsageHistory.lastUsedScreenTime;
  26. long elapsedDelta = getElapsedTime(elapsedRealtime) - appUsageHistory.lastUsedElapsedTime;
  27. if (DEBUG) Slog.d(TAG, packageName
  28. + " lastUsedScreen=" + appUsageHistory.lastUsedScreenTime
  29. + " lastUsedElapsed=" + appUsageHistory.lastUsedElapsedTime);
  30. if (DEBUG) Slog.d(TAG, packageName + " screenOn=" + screenOnDelta
  31. + ", elapsed=" + elapsedDelta);
  32. for (int i = screenTimeThresholds.length - 1; i >= 0; i--) {
  33. if (screenOnDelta >= screenTimeThresholds[i]
  34. && elapsedDelta >= elapsedTimeThresholds[i]) {
  35. return i;
  36. }
  37. }
  38. return 0; // 对应STANDBY_BUCKET_ACTIVE
  39. }

计算出screenOnDelta 和 elapsedDelta ,从for循环的便利顺序来看:

  • screenOnDelta超过2小时, elapsedDelta超过48小时bucket为RARE
  • screenOnDelta超过1小时, elapsedDelta超过24小时bucket为FREQUENT
  • elapsedDelta超过12小时bucket为working_set

虽然从for循环的顺序是上面的判断顺序,但是从时间轴的角度来看,package满足了screenOnDelta超过2小时, elapsedDelta超过48小时, 一定在某个时间点也会满足screenOnDelta超过1小时, elapsedDelta超过24小时, 在满足了screenOnDelta超过1小时, elapsedDelta超过24小时 那么在某个时间点一定也就满足了elapsedDelta超过12小时. 这么来说,一个package如果是在active 的bucket, 则会先到working_set,再到FREQUENT, 再到RARE.

2.2 获取app的bucket

获取app的bucket流程比较简单:

获取app的bucket流程图

AppIdleHistory.java中的代码如下:

  1. public int getAppStandbyBucket(String packageName, int userId, long elapsedRealtime) {
  2. ArrayMap<String, AppUsageHistory> userHistory = getUserHistory(userId);
  3. AppUsageHistory appUsageHistory =
  4. getPackageHistory(userHistory, packageName, elapsedRealtime, true);
  5. return appUsageHistory.currentBucket; // 在AppUsageHistory 中获取currentBucket就是所在的组别
  6. }

2.3 检查app的bucket

在前面介绍reportEvent的过程中, 有一下一段调用:

  1. final UserUsageStatsService service =
  2. getUserDataAndInitializeIfNeededLocked(userId, timeNow);
  3. service.reportEvent(event); // 检查app的bucket,详见2.3

调用了UserUsageStatsService 的report方法:

  1. void reportEvent(UsageEvents.Event event) {
  2. if (DEBUG) {
  3. Slog.d(TAG, mLogPrefix + "Got usage event for " + event.mPackage
  4. + "[" + event.mTimeStamp + "]: "
  5. + eventToString(event.mEventType));
  6. }
  7. // event.mTimeStamp 指该event发生的时间点,到机器开机的时间
  8. // mDailyExpiryDate.getTimeInMillis() 获取的是mTime值, 该值在mDailyExpiryDate.addDays(1) 中设置为一天
  9. // 此处代码逻辑是event的发生时间点在一天以上,则触发rolloverStats
  10. if (event.mTimeStamp >= mDailyExpiryDate.getTimeInMillis()) {
  11. // Need to rollover
  12. rolloverStats(event.mTimeStamp);
  13. }
  14. ......

rolloverStats函数中会调用loadActiveStats函数,loadActiveStats函数会调用mListener.onStatsReloaded函数,而这个mLisener正是UsageStatsService。 而UsageStatsService的onStatsReloaded函数,是调用了AppStandbyController的postOneTimeCheckIdleStates,这个函数如下,因为这个时候已经开机, 因此发送了一个MSG_ONE_TIME_CHECK_IDLE_STATES消息. 通过该异步消息会调用到checkIdleStates, 该方法最后会调用到checkAndUpdateStandbyState, 调用的方式如下:

  1. for (int i = 0; i < runningUserIds.length; i++) {
  2. final int userId = runningUserIds[i];
  3. if (checkUserId != UserHandle.USER_ALL && checkUserId != userId) {
  4. continue;
  5. }
  6. if (DEBUG) {
  7. Slog.d(TAG, "Checking idle state for user " + userId);
  8. }
  9. List<PackageInfo> packages = mPackageManager.getInstalledPackagesAsUser(
  10. PackageManager.MATCH_DISABLED_COMPONENTS,
  11. userId);
  12. final int packageCount = packages.size();
  13. for (int p = 0; p < packageCount; p++) {
  14. final PackageInfo pi = packages.get(p);
  15. final String packageName = pi.packageName;
  16. checkAndUpdateStandbyState(packageName, userId, pi.applicationInfo.uid,
  17. elapsedRealtime);
  18. }
  19. }

这是对每个用户,每个包进行checkAndUpdateStandbyState,来更新状态.

在AppStandbyController里的 onBootPhase 阶段也会调用postOneTimeCheckIdleStates, 这意味着,开机会检测更新一次,之后每隔一天会检测更新一次.

从代码可以看出,应用待机分组和app 是否使用android P 的 SDK 开发没有关系, 所有app, 只要是安装到android P的设备上都会受到系统的限制.

3 应用待机模式

在android M 版本上添加了Doze 和 app standby模式, 长时间没有在前台使用, app 的行为也会受到限制, 详情可见Optimize for Doze and App Standby. 该功能就是将app设置为是否idle状态来进行限制, 处于idle状态的app 的网络,JobScheduler等都会限制住. 在android P中,由于添加了应用待机分组功能, app的行为被限制的更加精细化.

在P上的AppIdleHistory.java中的setIdle方法设置为

  1. /* Returns the new standby bucket the app is assigned to */
  2. public int setIdle(String packageName, int userId, boolean idle, long elapsedRealtime) {
  3. ArrayMap<String, AppUsageHistory> userHistory = getUserHistory(userId);
  4. AppUsageHistory appUsageHistory = getPackageHistory(userHistory, packageName,
  5. elapsedRealtime, true);
  6. if (idle) {
  7. appUsageHistory.currentBucket = STANDBY_BUCKET_RARE;
  8. appUsageHistory.bucketingReason = REASON_MAIN_FORCED;
  9. } else {
  10. appUsageHistory.currentBucket = STANDBY_BUCKET_ACTIVE;
  11. // This is to pretend that the app was just used, don't freeze the state anymore.
  12. appUsageHistory.bucketingReason = REASON_MAIN_USAGE | REASON_SUB_USAGE_USER_INTERACTION;
  13. }
  14. return appUsageHistory.currentBucket;
  15. }

对比之前的android 版本的代码:

  1. public void setIdle(String packageName, int userId, long elapsedRealtime) {
  2. ArrayMap<String, PackageHistory> userHistory = getUserHistory(userId);
  3. PackageHistory packageHistory = getPackageHistory(userHistory, packageName,
  4. elapsedRealtime);
  5. shiftHistoryToNow(userHistory, elapsedRealtime);
  6. packageHistory.recent[HISTORY_SIZE - 1] &= ~FLAG_LAST_STATE;
  7. }

android P 已经把原来的standby 功能合并到了新添加的应用待机分组功能.如果是idle状态就是对应STANDBY_BUCKET_RARE组,不是idle就是STANDBY_BUCKET_ACTIVE组.

4 限制相关源码分析

4.1 监听的类型

前面分析了大段的代码, 这些代码将不同的app分到了不同的组别, 每次更新组别, 都会去通知监听者,在 checkAndUpdateStandbyState 中,最后会调用 maybeInformListeners 来通知监听者:

  1. /** Inform listeners if the bucket has changed since it was last reported to listeners */
  2. private void maybeInformListeners(String packageName, int userId,
  3. long elapsedRealtime, int bucket, int reason, boolean userStartedInteracting) {
  4. synchronized (mAppIdleLock) {
  5. if (mAppIdleHistory.shouldInformListeners(packageName, userId,
  6. elapsedRealtime, bucket)) {
  7. final StandbyUpdateRecord r = StandbyUpdateRecord.obtain(packageName, userId,
  8. bucket, reason, userStartedInteracting);
  9. if (DEBUG) Slog.d(TAG, "Standby bucket for " + packageName + "=" + bucket);
  10. mHandler.sendMessage(mHandler.obtainMessage(MSG_INFORM_LISTENERS, r));
  11. }
  12. }
  13. }

MSG_INFORM_LISTENERS 异步消息进过调用,informListeners

  1. case MSG_INFORM_LISTENERS:
  2. StandbyUpdateRecord r = (StandbyUpdateRecord) msg.obj;
  3. informListeners(r.packageName, r.userId, r.bucket, r.reason,
  4. r.isUserInteraction);
  5. r.recycle();
  6. break;

进入informListeners:

  1. void informListeners(String packageName, int userId, int bucket, int reason,
  2. boolean userInteraction) {
  3. // app所处的buncket的优先级在RARE以及RARE之下,标记为idle
  4. final boolean idle = bucket >= STANDBY_BUCKET_RARE;
  5. synchronized (mPackageAccessListeners) {
  6. for (AppIdleStateChangeListener listener : mPackageAccessListeners) {
  7. // onAppIdleStateChanged 用于通知监听者
  8. listener.onAppIdleStateChanged(packageName, userId, idle, bucket, reason);
  9. // 用户与package交互才导致的更改bucket, 则userInteraction为true,
  10. if (userInteraction) {
  11. listener.onUserInteractionStarted(packageName, userId);
  12. }
  13. }
  14. }
  15. }

从mPackageAccessListeners取出listener, 调用其方法onUserInteractionStarted. 重点就在分析清楚mPackageAccessListeners的结构:

  1. import android.app.usage.UsageStatsManagerInternal.AppIdleStateChangeListener;
  2. @GuardedBy("mPackageAccessListeners")
  3. private ArrayList<AppIdleStateChangeListener>
  4. mPackageAccessListeners = new ArrayList<>();
  5. void addListener(AppIdleStateChangeListener listener) {
  6. synchronized (mPackageAccessListeners) {
  7. if (!mPackageAccessListeners.contains(listener)) {
  8. mPackageAccessListeners.add(listener);
  9. }
  10. }
  11. }
  12. void removeListener(AppIdleStateChangeListener listener) {
  13. synchronized (mPackageAccessListeners) {
  14. mPackageAccessListeners.remove(listener);
  15. }
  16. }

上面的listener, 就是AppIdleStateChangeListener 类型, 而AppIdleStateChangeListener又定义在UsageStatsManagerInternal.java中:

  1. public static abstract class AppIdleStateChangeListener {
  2. /** Callback to inform listeners that the idle state has changed to a new bucket. */
  3. public abstract void onAppIdleStateChanged(String packageName, @UserIdInt int userId,
  4. boolean idle, int bucket, int reason);
  5. /**
  6. * Callback to inform listeners that the parole state has changed. This means apps are
  7. * allowed to do work even if they're idle or in a low bucket.
  8. */
  9. public abstract void onParoleStateChanged(boolean isParoleOn);
  10. /**
  11. * Optional callback to inform the listener that the app has transitioned into
  12. * an active state due to user interaction.
  13. */
  14. public void onUserInteractionStarted(String packageName, @UserIdInt int userId) {
  15. // No-op by default
  16. }
  17. }

这就是个AppIdleStateChangeListener的接口, listener对应的就是其真正的实现类:

  • NetworkPolicyManagerService.java里的私有类AppIdleStateChangeListener
  • AlarmManagerService.java里的final类AppStandbyTracker
  • JobSchedulerService.java里的final类StandbyTracker

感觉这几个Listener不是同一个人写的, 命名不一致

从接口的实现看, package在不同的组别, 将在 Network, Alarm, JobScheduler 三个方面受到限制.接下来就从三个方面分析其源码实现. 在informListeners 源码中, 调用到了onAppIdleStateChangedonUserInteractionStarted 两个接口. 对于onUserInteractionStarted 只有在JobScheduler中才真正的实现.onAppIdleStateChanged 在三个AppIdleStateChangeListener接口的实现类里都有实现.

4.2 Network的限制

frameworks/base/services/core/java/com/android/server/net/NetworkPolicyManagerService.java 的内部类AppIdleStateChangeListener定义如下: 这个类名和抽象类的名称一样,别搞混了.

  1. private class AppIdleStateChangeListener
  2. extends UsageStatsManagerInternal.AppIdleStateChangeListener {
  3. @Override
  4. public void onAppIdleStateChanged(String packageName, int userId, boolean idle, int bucket,
  5. int reason) {
  6. try {
  7. final int uid = mContext.getPackageManager().getPackageUidAsUser(packageName,
  8. PackageManager.MATCH_UNINSTALLED_PACKAGES, userId);
  9. synchronized (mUidRulesFirstLock) {
  10. mLogger.appIdleStateChanged(uid, idle);
  11. updateRuleForAppIdleUL(uid);
  12. updateRulesForPowerRestrictionsUL(uid);
  13. }
  14. } catch (NameNotFoundException nnfe) {
  15. }
  16. }
  17. @Override
  18. public void onParoleStateChanged(boolean isParoleOn) {
  19. synchronized (mUidRulesFirstLock) {
  20. mLogger.paroleStateChanged(isParoleOn);
  21. updateRulesForAppIdleParoleUL();
  22. }
  23. }
  24. }

4.3 Alarm的限制

AlarmManagerService.java里的final类AppStandbyTracker:

  1. /**
  2. * Tracking of app assignments to standby buckets
  3. */
  4. final class AppStandbyTracker extends UsageStatsManagerInternal.AppIdleStateChangeListener {
  5. public void onAppIdleStateChanged(final String packageName, final @UserIdInt int userId,
  6. boolean idle, int bucket, int reason) {
  7. mHandler.removeMessages(AlarmHandler.APP_STANDBY_BUCKET_CHANGED);
  8. mHandler.obtainMessage(AlarmHandler.APP_STANDBY_BUCKET_CHANGED, userId, -1, packageName)
  9. .sendToTarget();
  10. }
  11. public void onParoleStateChanged(boolean isParoleOn) {
  12. mHandler.removeMessages(AlarmHandler.APP_STANDBY_BUCKET_CHANGED);
  13. mHandler.removeMessages(AlarmHandler.APP_STANDBY_PAROLE_CHANGED);
  14. mHandler.obtainMessage(AlarmHandler.APP_STANDBY_PAROLE_CHANGED,
  15. Boolean.valueOf(isParoleOn)).sendToTarget();
  16. }
  17. };

关于alarm的延时定义:

  1. // Keys for specifying throttling delay based on app standby bucketing
  2. private final String[] KEYS_APP_STANDBY_DELAY = {
  3. "standby_active_delay",
  4. "standby_working_delay",
  5. "standby_frequent_delay",
  6. "standby_rare_delay",
  7. "standby_never_delay",
  8. };
  9. private static final long DEFAULT_MIN_FUTURITY = 5 * 1000;
  10. private static final long DEFAULT_MIN_INTERVAL = 60 * 1000;
  11. private static final long DEFAULT_MAX_INTERVAL = 365 * DateUtils.DAY_IN_MILLIS;
  12. private static final long DEFAULT_ALLOW_WHILE_IDLE_SHORT_TIME = DEFAULT_MIN_FUTURITY;
  13. private static final long DEFAULT_ALLOW_WHILE_IDLE_LONG_TIME = 9*60*1000;
  14. private static final long DEFAULT_ALLOW_WHILE_IDLE_WHITELIST_DURATION = 10*1000;
  15. private static final long DEFAULT_LISTENER_TIMEOUT = 5 * 1000;
  16. private final long[] DEFAULT_APP_STANDBY_DELAYS = {
  17. 0, // Active
  18. 6 * 60_000, // Working
  19. 30 * 60_000, // Frequent
  20. 2 * 60 * 60_000, // Rare
  21. 10 * 24 * 60 * 60_000 // Never
  22. };
  • AlarmManagerService->setImplLocked
  • AlarmManagerSerivice->adjustDeliveryTimeBasedOnStandbyBucketLocked
  • AlarmManagerService->getMinDelayForBucketLocked 由于对alarm不熟悉,就先到这.

4.4 JobScheduler的限制

JobScheduler 监听实现:

  1. /**
  2. * Tracking of app assignments to standby buckets
  3. */
  4. final class StandbyTracker extends AppIdleStateChangeListener {
  5. // AppIdleStateChangeListener interface for live updates
  6. @Override
  7. public void onAppIdleStateChanged(final String packageName, final @UserIdInt int userId,
  8. boolean idle, int bucket, int reason) {
  9. final int uid = mLocalPM.getPackageUid(packageName,
  10. PackageManager.MATCH_UNINSTALLED_PACKAGES, userId);
  11. if (uid < 0) {
  12. if (DEBUG_STANDBY) {
  13. Slog.i(TAG, "App idle state change for unknown app "
  14. + packageName + "/" + userId);
  15. }
  16. return;
  17. }
  18. final int bucketIndex = standbyBucketToBucketIndex(bucket);
  19. // update job bookkeeping out of band
  20. BackgroundThread.getHandler().post(() -> {
  21. if (DEBUG_STANDBY) {
  22. Slog.i(TAG, "Moving uid " + uid + " to bucketIndex " + bucketIndex);
  23. }
  24. synchronized (mLock) {
  25. mJobs.forEachJobForSourceUid(uid, job -> {
  26. // double-check uid vs package name to disambiguate shared uids
  27. if (packageName.equals(job.getSourcePackageName())) {
  28. job.setStandbyBucket(bucketIndex); // 在JobStatus.java中修改job的app所在的bucket
  29. }
  30. });
  31. onControllerStateChanged(); //重点分析
  32. }
  33. });
  34. }
  35. @Override
  36. public void onParoleStateChanged(boolean isParoleOn) {
  37. if (DEBUG_STANDBY) {
  38. Slog.i(TAG, "Global parole state now " + (isParoleOn ? "ON" : "OFF"));
  39. }
  40. mInParole = isParoleOn;
  41. }
  42. @Override
  43. public void onUserInteractionStarted(String packageName, int userId) {
  44. final int uid = mLocalPM.getPackageUid(packageName,
  45. PackageManager.MATCH_UNINSTALLED_PACKAGES, userId);
  46. if (uid < 0) {
  47. // Quietly ignore; the case is already logged elsewhere
  48. return;
  49. }
  50. long sinceLast = mUsageStats.getTimeSinceLastJobRun(packageName, userId);
  51. if (sinceLast > 2 * DateUtils.DAY_IN_MILLIS) {
  52. // Too long ago, not worth logging
  53. sinceLast = 0L;
  54. }
  55. final DeferredJobCounter counter = new DeferredJobCounter();
  56. synchronized (mLock) {
  57. mJobs.forEachJobForSourceUid(uid, counter);
  58. }
  59. if (counter.numDeferred() > 0 || sinceLast > 0) {
  60. BatteryStatsInternal mBatteryStatsInternal = LocalServices.getService
  61. (BatteryStatsInternal.class);
  62. mBatteryStatsInternal.noteJobsDeferred(uid, counter.numDeferred(), sinceLast);
  63. }
  64. }
  65. }

在JobSchedulerService 创建的时候就添加Listener:

  1. // Set up the app standby bucketing tracker
  2. mStandbyTracker = new StandbyTracker();
  3. mUsageStats = LocalServices.getService(UsageStatsManagerInternal.class);
  4. mUsageStats.addAppIdleStateChangeListener(mStandbyTracker);

onControllerStateChanged()发送了异步消息MSG_CHECK_JOB :

  1. case MSG_CHECK_JOB:
  2. if (mReportedActive) {
  3. // if jobs are currently being run, queue all ready jobs for execution.
  4. // job 正在执行执行,让其2执行完
  5. queueReadyJobsForExecutionLocked();
  6. } else {
  7. // Check the list of jobs and run some of them if we feel inclined.
  8. maybeQueueReadyJobsForExecutionLocked();
  9. }
  10. break;

maybeQueueReadyJobsForExecutionLocked() 的实现:

  1. private void maybeQueueReadyJobsForExecutionLocked() {
  2. if (DEBUG) Slog.d(TAG, "Maybe queuing ready jobs...");
  3. noteJobsNonpending(mPendingJobs);
  4. mPendingJobs.clear();
  5. stopNonReadyActiveJobsLocked();
  6. mJobs.forEachJob(mMaybeQueueFunctor); // 会调用到MaybeReadyJobQueueFunctor的accept()方法
  7. mMaybeQueueFunctor.postProcess(); // mPendingJobs.addAll(runnableJobs)
  8. }

MaybeReadyJobQueueFunctor 的 accept() 会调用到isReadyToBeExecutedLocked(job):

  1. /**
  2. * Criteria for moving a job into the pending queue:
  3. * - It's ready.
  4. * - It's not pending.
  5. * - It's not already running on a JSC.
  6. * - The user that requested the job is running.
  7. * - The job's standby bucket has come due to be runnable.
  8. * - The component is enabled and runnable.
  9. */
  10. private boolean isReadyToBeExecutedLocked(JobStatus job) {
  11. .....
  12. // If the app is in a non-active standby bucket, make sure we've waited
  13. // an appropriate amount of time since the last invocation. During device-
  14. // wide parole, standby bucketing is ignored.
  15. //
  16. // Jobs in 'active' apps are not subject to standby, nor are jobs that are
  17. // specifically marked as exempt.
  18. if (DEBUG_STANDBY) {
  19. Slog.v(TAG, "isReadyToBeExecutedLocked: " + job.toShortString()
  20. + " parole=" + mInParole + " active=" + job.uidActive
  21. + " exempt=" + job.getJob().isExemptedFromAppStandby());
  22. }
  23. if (!mInParole
  24. && !job.uidActive
  25. && !job.getJob().isExemptedFromAppStandby()) {
  26. final int bucket = job.getStandbyBucket();
  27. if (DEBUG_STANDBY) {
  28. Slog.v(TAG, " bucket=" + bucket + " heartbeat=" + mHeartbeat
  29. + " next=" + mNextBucketHeartbeat[bucket]);
  30. }
  31. if (mHeartbeat < mNextBucketHeartbeat[bucket]) {
  32. // Only skip this job if the app is still waiting for the end of its nominal
  33. // bucket interval. Once it's waited that long, we let it go ahead and clear.
  34. // The final (NEVER) bucket is special; we never age those apps' jobs into
  35. // runnability.
  36. final long appLastRan = heartbeatWhenJobsLastRun(job);
  37. if (bucket >= mConstants.STANDBY_BEATS.length
  38. || (mHeartbeat > appLastRan
  39. && mHeartbeat < appLastRan + mConstants.STANDBY_BEATS[bucket])) {
  40. // TODO: log/trace that we're deferring the job due to bucketing if we hit this
  41. if (job.getWhenStandbyDeferred() == 0) {
  42. if (DEBUG_STANDBY) {
  43. Slog.v(TAG, "Bucket deferral: " + mHeartbeat + " < "
  44. + (appLastRan + mConstants.STANDBY_BEATS[bucket])
  45. + " for " + job);
  46. }
  47. job.setWhenStandbyDeferred(sElapsedRealtimeClock.millis());
  48. }
  49. return false;
  50. } else {
  51. if (DEBUG_STANDBY) {
  52. Slog.v(TAG, "Bucket deferred job aged into runnability at "
  53. + mHeartbeat + " : " + job);
  54. }
  55. }
  56. }
  57. ......
  58. }

STANDBY_BEATS 的定义JobSchedulerService.java 中:

  1. private static final int DEFAULT_STANDBY_WORKING_BEATS = 11; // ~ 2 hours, with 11min beats
  2. private static final int DEFAULT_STANDBY_FREQUENT_BEATS = 43; // ~ 8 hours
  3. private static final int DEFAULT_STANDBY_RARE_BEATS = 130; // ~ 24 hours
  4. /**
  5. * Mapping: standby bucket -> number of heartbeats between each sweep of that
  6. * bucket's jobs.
  7. *
  8. * Bucket assignments as recorded in the JobStatus objects are normalized to be
  9. * indices into this array, rather than the raw constants used
  10. * by AppIdleHistory.
  11. */
  12. final int[] STANDBY_BEATS = {
  13. 0,
  14. DEFAULT_STANDBY_WORKING_BEATS,
  15. DEFAULT_STANDBY_FREQUENT_BEATS,
  16. DEFAULT_STANDBY_RARE_BEATS
  17. };

经过一系列的计算,不同bucket的心跳是不一样的,这样就实现了延时实现不同bucket的JS.心跳的计算是在:

  1. /**
  2. * Heartbeat tracking. The heartbeat alarm is intentionally non-wakeup.
  3. */
  4. class HeartbeatAlarmListener implements AlarmManager.OnAlarmListener {
  5. @Override
  6. public void onAlarm() {
  7. synchronized (mLock) {
  8. final long sinceLast = sElapsedRealtimeClock.millis() - mLastHeartbeatTime;
  9. final long beatsElapsed = sinceLast / mConstants.STANDBY_HEARTBEAT_TIME;
  10. if (beatsElapsed > 0) {
  11. mLastHeartbeatTime += beatsElapsed * mConstants.STANDBY_HEARTBEAT_TIME;
  12. advanceHeartbeatLocked(beatsElapsed); // 不让触发alarm, 就是延时
  13. }
  14. }
  15. setNextHeartbeatAlarm(); // 设置下一次alarm 时间
  16. }
  17. }

这块代码,具体没有研究透彻,先告一段落.

参考blog: