service

最新推荐文章于 2024-08-11 21:09:18 发布

锟钢

最新推荐文章于 2024-08-11 21:09:18 发布

阅读量134

点赞数

分类专栏：开发小日记

本文链接：https://blog.csdn.net/m0_38058826/article/details/82385272

版权

开发小日记专栏收录该内容

34 篇文章 0 订阅

订阅专栏

http://www.cnblogs.com/lwbqqyumidi/p/4181185.html

onStartCommand(Intent intent, int flags, int startId)方法。

START_NOT_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，即使系统内存足够可用，系统也不会尝试重新创建此Service。除非程序中Client明确再次调用startService(...)启动此Service。

START_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，当系统内存足够可用的情况下，系统将会尝试重新创建此Service，一旦创建成功后将回调onStartCommand(...)方法，但其中的Intent将是null，pendingintent除外。

START_REDELIVER_INTENT：与START_STICKY唯一不同的是，回调onStartCommand(...)方法时，其中的Intent将是非空，将是最后一次调用startService(...)中的intent。

小米手机针对此处做了变更：在“自启动管理”中有一个自启动应用列表，默认情况下，只有少应用（如微信、QQ、YY、360等）默认是可以自启动的，其他应用默认都是禁止的。

注：在四大基本组件中，需要注意的的是BroadcastReceiver不能作为Bound Service的Client，因为BroadcastReceiver的生命周期很短，当执行完onReceive(..)回调时，BroadcastReceiver生命周期完结。而Bound Service又与Client本身的生命周期相关，因此，Android中不允许BroadcastReceiver去bindService(..)，当有此类需求时，可以考虑通过startService(..)替代。

Started Service生命周期及进程相关

注：

1，onStartCommand(..)可以多次被调用，onDestroy()与onCreate()想匹配，当用户强制kill掉进程时，onDestroy()是不会执行的。

2，对于同一类型的Service，Service实例一次永远只存在一个，而不管Client是否是相同的组件，也不管Client是否处于相同的进程中。

3，当Service需要运行在单独的进程中，AndroidManifest.xml声明时需要通过android:process指明此进程名称，当此Service需要对其他App开放时，android:exported属性值需要设置为true(当然，在有intent-filter时默认值就是true)。

4，Client调用stopService(..)时，如果当前Service没有启动，也不会出现任何报错或问题，也就是说，stopService(..)无需做当前Service是否有效的判断。

Client - Service之间的双向通信流程

1.MyMessengerService自定中，通过new Messenger(new ServerHandler())创建Messenger对象，在onBind(..)回调中，通过调用Messenger对象的getBinder()方法，将Binder返回；

2.Client在ServiceConnection的onServiceConnected(..)的回调中，通过new Messenger(binder)获取到Service传递过来的mServerMessenger；

3.接下来，就可以通过mServerMessenger.send(msg)方法向Service发送message，Service中的Messenger构造器中的Handler即可接收到此信息，在handleMessage(..)回调中处理；

4.至此只是完成了从Client发送消息到Service，同样的道理，想实现Service发送消息到Client，可以在客户端定义一个Handler，并得到相应的Messenger，在Clinet发送消息给Service时，通过msg.replyTo = mClientMessenger方式将Client信使传递给Service；

5.Service接收到Client信使后，获取此信使，并通过mClientMessenger.send(toClientMsg)方式将Service消息发送给Client。

至此，完成了Client - Service之间的双向通信流程。

AIDL（Android Interface Definition Language）

一般情况下，Messenger这种方式都是可以满足需求的，当然，通过自定义AIDL方式相对更加灵活。

这种方式需要自己在项目中自定义xxx.aidl文件，然后系统会自动在gen目录下生成相应的接口类文件，接下来整个的流程与Messenger方式差别不大，网上也有不少实例，在此不再具体给出。

注：无论哪种方式的Bound Service，在进行unbind(..)操作时，都需要注意当前Service是否处于已经绑定状态，否则可能会因为当前Service已经解绑后继续执行unbind(..)会导致崩溃。这点与Started Service区别很大（如前文所述：stopService(..)无需做当前Service是否有效的判断）。

Service特性

1.Service本身都是运行在其所在进程的主线程（如果Service与Clinet同属于一个进程，则是运行于UI线程），但Service一般都是需要进行”长期“操作，所以经常写法是在自定义Service中处理”长期“操作时需要新建线程，以免阻塞UI线程或导致ANR；

2.Service一旦创建，需要停止时都需要显示调用相应的方法（Started Service需要调用stopService(..)或Service本身调用stopSelf(..)， Bound Service需要调用unbindService(..)），否则对于Started Service将处于一直运行状态，对于Bound Service，当Client生命周期结束时也将因此问题。也就是说，Service执行完毕后，必须人为的去停止它。

IntentService

IntentService特殊性是相对于Service本身的特性而言的：

1.默认直接实现了onBind(..)方法，直接返回null，并定义了抽象方法onHandlerIntent(..)，用户自定义子类时，需要实现此方法；

2.onHandlerIntent(..)主要就是用来处于相应的”长期“任务的，并且已经自动在新的线程中，用户无语自定义新线程；

3.当”长期“任务执行完毕后（也就是onHandlerIntent(..)执行完毕后），此IntentService将自动结束，无需人为调用方法使其结束；

4.IntentService处于任务时，也是按照队列的方式一个个去处理，而非真正意义上的多线程并发方式。

另：

Local Service：不少人又称之为”本地服务“，是指Client - Service同处于一个进程；

Remote Service：又称之为”远程服务“，一般是指Service处于单独的一个进程中。

通过Service.startForeground (int id, Notification notification)方法可以将此Service设置为前台Service。

谷歌专项整顿

6.0 (API 级 23) 引入了 Doze 机制和应用程序待机。当屏幕关闭且设备静止时, 打盹模式会限制应用程序的行为。应用程序待机将未使用的应用程序置于限制其网络访问、作业和同步的特殊状态。
Android 7.0 (API 级 24) 有限的隐性广播和 Doze-on-the-go.
Android 8.0 (API 级 26) 进一步限制了后台行为, 例如在后台获取位置并释放缓存的 wakelocks。

尤其在Android O（8.0）中，谷歌对于后台的限制几乎可以称之为变态：

Android 8.0 有一项复杂功能；系统不允许后台应用创建后台服务。因此，Android 8.0 引入了一种全新的方法，即 Context.startForegroundService()，以在前台启动新服务。在系统创建服务后，应用有五秒的时间来调用该服务的 startForeground() 方法以显示新服务的用户可见通知。如果应用在此时间限制内未调用 startForeground()，则系统将停止服务并声明此应用为 ANR。

而且加入了对静态广播的限制：

Android 8.0 让这些限制更为严格。针对 Android 8.0 的应用无法继续在其清单中为隐式广播注册广播接收器。隐式广播是一种不专门针对该应用的广播。例如，ACTION_PACKAGE_REPLACED 就是一种隐式广播，因为它将发送到注册的所有侦听器，让后者知道设备上的某些软件包已被替换。不过，ACTION_MY_PACKAGE_REPLACED 不是隐式广播，因为不管已为该广播注册侦听器的其他应用有多少，它都会只发送到软件包已被替换的应用。应用可以继续在它们的清单中注册显式广播。应用可以在运行时使用 Context.registerReceiver() 为任意广播（不管是隐式还是显式）注册接收器。需要签名权限的广播不受此限制所限，因为这些广播只会发送到使用相同证书签名的应用，而不是发送到设备上的所有应用。在许多情况下，之前注册隐式广播的应用使用 JobScheduler 作业可以获得类似的功能。

于此同时，官方推荐用5.0推出的 JobScheduler 替换 Service + Broadcast 的方案。并且在 Android O，后台 Service 启动后的5秒内，如果不转为前台 Service 就会 ANR!

https://mp.weixin.qq.com/s/UKgPtJyMF8CJ8ffUuwCCvg