前言
后台进程是内存和电池敏感的。一个隐式的broadcast可能会启动很多监听它的后台进程，即使这些进程可能做得工作不多。这可能丢设备性能和用户体验都有比较大的影响。
为了缓解这种问题，7.0（API 24）做了以下限制：
-
Target为 Android 7.0 (API level 24)的App，将不会再收到在mainfest中注册的
CONNECTIVITY_ACTION广播。运行中的App仍然可以在Main Thread中通过Context.registerReceiver()注册CONNECTIVITY_CHANGE广播来监听
-
App 将不能够发送或者接收
ACTION_NEW_PICTUREorACTION_NEW_VIDEO。这种优化会影响到所有的app，不仅是target为Android7.0的设备。`
因此如果你使用了这些intennt，应该尽快的移除对它们的依赖，以便你的app可以在Target为Android 7.0的设备上正常运行。Android框架提供了几种解决方案去减小对这些隐式广播的依赖。比如， JobScheduler
and GcmNetworkManager
提供了强健的机制去调度特定情况下的网络操作。比如，你也可以使用 JobScheduler
去响应content provider的变化。 JobInfo
对象封装了 JobScheduler
用于调度job的参数。当满足指定的条件的时候，系统会通 JobService
过执行该job。
这篇文章将会告诉你如何使用替代的方法，比如JobScheduler去为你的app做这些限制的适配。
一 CONNECTIVITY_ACTION的限制
上面提到，Android 7.0 (API level 24) 将不再能够收到mainfest中注册的 CONNECTIVITY_ACTION
广播。Android框架中已经提供了几种替代方案，如何选择依赖于你的具体实现。
注意：一个通过 Context.registerReceiver()
注册的 BroadcastReceiver
在app运行期间是可以继续收到广播的。
在不可预测的网络的情况下调度Network Jobs
当使用 JobInfo.Builder
类构建 JobInfo
对象的时候, 通过 setRequiredNetworkType()
方法并传递 JobInfo.NETWORK_TYPE_UNMETERED
参数。下面的示例代码演示了当设备连接到一个未知的网络并且是在充电的时候，去调度一个service去执行的情景：
public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
JobScheduler js =
(JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
JobInfo job = new JobInfo.Builder(
MY_BACKGROUND_JOB,
new ComponentName(context, MyJobService.class))
.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
.setRequiresCharging(true)
.build();
js.schedule(job);
}
当以上条件满足的时候，app就会收到一个回调去执行指定的 JobService.class
中的 on
StartJob()
方法，更多 JobScheduler
实例可参考 JobScheduler sample app
.
使用GMSCore service的应用，并且target是5.0或者以下的，可以使用
GcmNetworkManager
并指定 Task.NETWORK_STATE_UNMETERED。
在APP运行期间监测网络连接
运行期间的App仍然可以监听 CONNECTIVITY_CHANGE
，但是， ConnectivityManager
提供了更多强大的方法在特定网络条件满足的时候去触发一个回调。
NetworkRequest
对象定义了
NetworkCapabilities
相关网络回调的参数，你可以通过 NetworkRequest.Builder
类构建 NetworkRequest对象，
registerNetworkCallback() ，然后将NetworkRequest
传递对象到系统中去。当网络条件满足的时候，app就会受到一个回调去执行定义在 ConnectivityManager.NetworkCallback
中的 onAvailable()
方法。
App会一直接收注册的回调，除非app退出或者调用 unregisterNetworkCallback()
方法。
二 NEW_PICTURE 和 NEW_VIDEO 的限制
Android 7.0 (API level 24),中，app将不能够发送和接收这两个广播。当几个不同的app必须唤醒设备去处理一个新的Image或者video的时候，这样的限制可以改善性能和用户体验的影响。Android 7.0 (API level 24) 扩展了 JobInfo
和 JobParameters
来提供一种替代方案。
新的JobInfo方法
为了让content URI的变化去触发job，Android 7.0 (API level 24)扩展了
JobInfo
的以下方法：
-
JobInfo.TriggerContentUri()
? 封装了contentn URL变化需要的参数
-
JobInfo.Builder.addTriggerContentUri()
传递一个
TriggerContentUri对象给JobInfo。一个ContentObserver监测器封装的content URI。如果这里有多个TriggerContentUri对象关联到某个job上，只要其中某个URI变化，系统都会触发回调事件。
TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS
标志在任何给定URI的子集有变化的时候，都会触发job。该标志对应于传递给 registerContentObserver()
的 notifyForDescendants
参数。
注意: TriggerContentUri()
cannot be used in combination with setPeriodic()
or setPersisted()
. To continually monitor for content changes, schedule a new JobInfo
before the app’s JobService
finishes handling the most recent callback.
注意： TriggerContentUri()
不能够和 setPeriodic()
或者 setPersisted()
一起使用。为了持续地监测content 的变化，可以在 JobService
处理完最近的回调之前去调度一个新的JobInfo。
下面的代码演示了当系统上报一个MEDIA_URI contentURI的时候，调度一个job的场景：
public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
JobScheduler js =
(JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
JobInfo.Builder builder = new JobInfo.Builder(
MY_BACKGROUND_JOB,
new ComponentName(context, MediaContentJob.class));
builder.addTriggerContentUri(
new JobInfo.TriggerContentUri(MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS));
js.schedule(builder.build());
}
当系统上报指定的conent URI(s)，你的app会收到一个回调和一个传递给 on
StartJob()
方法（ 在 MediaContentJob.class
中）的 JobParameters
对象。
新的JobParameter方法
Android 7.0 (API level 24)也扩展了 JobParameters
允许app接收有用的信息，该信息包含了具体是哪些content authorities 和 URIs 触发了job。
-
Uri[] getTriggeredContentUris()
返回一个触发了该Job的URIs数组。如果没有URIs触发job，或者URIs的数量大于50，那么该数组将为null（有可能job是由于其它原因触发，比如一个deadline）。
-
String[] getTriggeredContentAuthorities()
Returns a string array of content authorities that have triggered the job. If the returned array is not null
, use getTriggeredContentUris()
to retrieve the details of which URIs have changed.
The following sample code overrides the JobService.on
StartJob()
method and records the content authorities and URIs that have triggered the job:
返回一个触发了该Job的content authorities数组。如果返回的数组不为null，可以使用 getTriggeredContentUris()
方法获取URIs变化的具体信息。
下面的代码复写了 JobService.on
StartJob()
方法，并且记录了触发job的 content authorities 和URIs ：
@Override
publicboolean on StartJob(JobParametersparams){
StringBuilder sb =newStringBuilder();
sb.append("Media content has changed:\n");
if(params.getTriggeredContentAuthorities()!=null){
sb.append("Authorities: ");
boolean first =true;
for(String auth :
params.getTriggeredContentAuthorities()){
if(first){
first =false;
}else{
sb.append(", ");
}
sb.append(auth);
}
if(params.getTriggeredContentUris()!=null){
for(Uri uri :params.getTriggeredContentUris()){
sb.append("\n");
sb.append(uri);
}
}
}else{
sb.append("(No content)");
}
Log.i(TAG, sb.toString());
returntrue;
}
三 Further Optimizing Your App
为低内存设备或者在低内存条件做优化，可以提升系能和用户体验。移除对后台的service的依赖和静态方式注册的隐式广播，可以帮助你的app在这样的设备上运行的更好。尽管7.0上采取了一些措施减少了这些问题，但还是建议去优化app，即使在完全没有使用后台进程的情况也可以正常运行。
Android 7.0 (API level 24)引入了一些 Android Debug Bridge (ADB) 命令，可以帮助你测试app在禁止后台进程的情况下app的行为：
-
模拟隐式广播和后台service不可用的情况，可以使用下面的命令
$ adb shell cmd appops set RUN_IN_BACKGROUND ignore
-
重新开启隐式广播和后台service
$ adb shell cmd appops set RUN_IN_BACKGROUND allow
