android service 限制

1.本文重点分析 service 在Android系统版本的限制 和部分重点限制

1.1 android 8.0    行为变更

后台执行限制 

Android 8.0 为提高电池续航时间而引入的变更之一是，当您的应用进入已缓存状态时，如果没有活动的组件，系统将解除应用具有的所有唤醒锁。

此外，为提高设备性能，系统会限制未在前台运行的应用的某些行为。具体而言：

• 现在，在后台运行的应用对后台服务的访问受到限制。
• 应用无法使用其清单注册大部分隐式广播（即，并非专门针对此应用的广播）。

默认情况下，这些限制仅适用于针对 O 的应用。不过，用户可以从 Settings 屏幕为任意应用启用这些限制，即使应用并不是以 O 为目标平台。

Android 8.0 还对特定函数做出了以下变更：

• 如果针对 Android 8.0 的应用尝试在不允许其创建后台服务的情况下使用 startService() 函数，则该函数将引发一个 IllegalStateException。
• 新的 Context.startForegroundService() 函数将启动一个前台服务。现在，即使应用在后台运行，系统也允许其调用 Context.startForegroundService()。不过，应用必须在创建服务后的五秒内调用该服务的 startForeground() 函数。

在后台中运行的服务会消耗设备资源，这可能降低用户体验。 为了缓解这一问题，系统对这些服务施加了一些限制。

系统可以区分 前台 和 后台 应用。 （用于服务限制目的的后台定义与内存管理使用的定义不同；一个应用按照内存管理的定义可能处于后台，但按照能够启动服务的定义又处于前台。）如果满足以下任意条件，应用将被视为处于前台：

具有可见 Activity（不管该 Activity 已启动还是已暂停）。
具有前台服务。
另一个前台应用已关联到该应用（不管是通过绑定到其中一个服务，还是通过使用其中一个内容提供程序）。 例如，如果另一个应用绑定到该应用的服务，那么该应用处于前台：

IME
壁纸服务
通知侦听器
语音或文本服务
如果以上条件均不满足，应用将被视为处于后台。

绑定服务不受影响
这些规则不会对绑定服务产生任何影响。 如果您的应用定义了绑定服务，则不管应用是否处于前台，其他组件都可以绑定到该服务。

处于前台时，应用可以自由创建和运行前台服务与后台服务。 进入后台时，在一个持续数分钟的时间窗内，应用仍可以创建和使用服务。

在该时间窗结束后，应用将被视为处于 空闲 状态。 此时，系统将停止应用的后台服务，就像应用已经调用服务的“Service.stopSelf()”方法。

1.2 android 7.0    行为变更

后台优化 

Android 7.0 移除了三项隐式广播，以帮助优化内存使用和电量消耗。此项变更很有必要，因为隐式广播会在后台频繁启动已注册侦听这些广播的应用。删除这些广播可以显著提升设备性能和用户体验。

移动设备会经历频繁的连接变更，例如在 WLAN 和移动数据之间切换时。目前，可以通过在应用清单中注册一个接收器来侦听隐式 CONNECTIVITY_ACTION 广播，让应用能够监控这些变更。由于很多应用会注册接收此广播，因此单次网络切换即会导致所有应用被唤醒并同时处理此广播。

同理，在之前版本的 Android 中，应用可以注册接收来自其他应用（例如相机）的隐式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 广播。当用户使用相机应用拍摄照片时，这些应用即会被唤醒以处理广播。

为缓解这些问题，Android 7.0 应用了以下优化措施：

• 面向 Android 7.0 开发的应用不会收到 CONNECTIVITY_ACTION 广播，即使它们已有清单条目来请求接受这些事件的通知。在前台运行的应用如果使用 BroadcastReceiver 请求接收通知，则仍可以在主线程中侦听 CONNECTIVITY_CHANGE。
• 应用无法发送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 广播。此项优化会影响所有应用，而不仅仅是面向 Android 7.0 的应用。

如果您的应用使用任何 intent，您仍需要尽快移除它们的依赖关系，以正确适配 Android 7.0 设备。Android 框架提供多个解决方案来缓解对这些隐式广播的需求。例如，JobScheduler API 提供了一个稳健可靠的机制来安排满足指定条件（例如连入无限流量网络）时所执行的网络操作。您甚至可以使用 JobScheduler 来适应内容提供程序变化。

如需了解有关 Android N 中后台优化以及如何改写应用的详细信息，请参阅后台优化。

1.3 android 6.0    行为变更

运行时权限

取消支持 Apache HTTP 客户端

Android 6.0 版移除了对 Apache HTTP 客户端的支持。如果您的应用使用该客户端，并以 Android 2.3（API 级别 9）或更高版本为目标平台，请改用 HttpURLConnection 类。此 API 效率更高，因为它可以通过透明压缩和响应缓存减少网络使用，并可最大限度降低耗电量。要继续使用 Apache HTTP API，您必须先在 build.gradle 文件中声明以下编译时依赖项：

android {
    useLibrary 'org.apache.http.legacy'
}

运行时

ART 运行时环境现在可正确实现 newInstance() 方法的访问规则。此变更修正了之前版本中 Dalvik 无法正确检查访问规则的问题。如果您的应用使用 newInstance() 方法，并且您想重写访问检查，请调用 setAccessible() 方法（将输入参数设置为 true）。如果您的应用使用 v7 appcompat 库或 v7 recyclerview 库，则您必须更新应用以使用这些库的最新版本。否则，请务必更新从 XML 引用的任何自定义类，以便能够访问它们的类构造函数。

1.4 android 5.0    行为变更

Android Runtime (ART)

---

在 Android 5.0 中，ART 运行时取代 Dalvik 成为平台默认设置。Android 4.4 中已引入处于实验阶段的 ART 运行时。

有关 ART 的新功能概述，请参阅 ART 简介。部分主要的新功能包括：

• 预先 (AOT) 编译
• 改进的垃圾回收 (GC)
• 改进的调试支持

大多数 Android 应用无需任何更改就可以在 ART 下工作。不过，部分适合 Dalvik 的技术并不适用于 ART。如需了解有关最重要问题的信息，请参阅在 Android Runtime (ART) 上验证应用行为。如存在以下情况，应特别注意：

• 您的应用使用 Java 原生接口 (JNI) 运行 C/C++ 代码。
• 您使用生成非标准代码的开发工具（例如，一些代码混淆工具）。
• 您使用与压缩垃圾回收不兼容的技术。
  

Material Design 样式

Android NDK 中的 64 位支持

---

Android 5.0 引入了对 64 位系统的支持。64 位增强功能可增加地址空间和提升性能，同时仍完全支持现有的 32 位应用。64 位支持也可改进用于加密的 OpenSSL 的性能。此外，该版本还引入了新的原生媒体 NDK API，以及原生 OpenGL ES (GLES) 3.1 支持。

要使用 Android 5.0 中提供的 64 位支持，请从 Android NDK 页面下载和安装 NDK Revision 10c。有关对 NDK 进行的重要变更和问题修复的更多信息，请参阅 Revision 10c 版本说明。

绑定到服务

---

Context.bindService() 方法现在需要显式 Intent，如果提供隐式 intent，将引发异常。为确保应用的安全性，请使用显式 intent 启动或绑定 Service，且不要为服务声明 intent 过滤器。

WebView

---

Android 5.0 更改了应用的默认行为。

• 如果您的应用是面向 API 级别 21 或更高级别：
  • 默认情况下，系统会阻止混合内容和第三方 Cookie。要允许混合内容和第三方 Cookie，请分别使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法。
  • 系统现在可以智能地选择要绘制的 HTML 文档部分。这个新的默认行为有助于减少内存占用和提升性能。如果您要一次渲染整个文档，可通过调用 enableSlowWholeDocumentDraw() 停用此优化。
• 如果您的应用是面向低于 21 的 API 级别：系统允许混合内容和第三方 Cookie，并始终一次渲染整个文档。

1.5 android 4.4    行为变更