ActivityManagerService之Service怎么启动(activitymanagerservice,service,开发技术)

Service 的启动最终会调用如下方法

Service 最终是通过 AMS 进行启动的，一旦启动成功，会返回 Service 的组件名，通过这个返回结果，可以判断 Service 是否启动成功，这一点往往被很多开发者忽略。

AMS 最终会调用 ActiveService#startServiceLocked() 来启动 Service

ActivityManagerService 把 Service 的所有事务都交给 ActiveServices 处理。

首先为 Service 在服务端建立一个记录 ServiceRecord 并缓存起来，这个过程比较简单，读者自行分析。

然后，在 Service 启动之前，施加一些限制，代码中展示了一段后台 app 无法启动 Service 的限制，但是也省略了其他限制的代码，有兴趣的读者可以自行分析。

本文旨在分析 Service 的启动流程，对于一些小细节，限于篇幅原因，就不细致分析，请读者自行研读代码。

最后进入下一步的启动的流程

Service 的启动，会调用好几个类似的函数，但是每一个函数最做了一部分功能，这样就可以把一个庞大的函数分割为几个小的函数，代码阅读性更高，我们要学习这种做法。

现在没有 Service 的启动限制了，是时候正式启动了，首先更新 ServiceRecord 数据，这里要注意，使用 ServiceRecord#pendingStarts 保存了要发送给 Service 的参数。

接下来有一段关于延时 Service 以及监听 后台Service 相关的代码，这是为了优化 Service 启动过多的情况，而做出的一个优化。对于系统优化的开发者，你可能要重点关注一下，本文先不管这个优化功能。

然后继续看下一步的启动流程

很简单，这一步主要是通过 bringUpServiceLocked() 拉起 Service

拉起一个 Service 要分好几种情况

如果 Service 已经启动过，那么直接发送参数给 Service 去执行任务即可。这是最简单的一种情况。

如果 Service 没有启动过，但是 Service 的宿主进程是存在的，那么通知宿主进程创建 Service，然后发送参数给它。

如果 Service 的宿主进程不存在，那么得先 fork 一个进程，然后用 mPendingServices 保存这个等待进程启动的 Service。当进程起来后，在执行 attach application 的过程中，AMS 会自动完成 Service 的启动流程。

第3种情况，明显是包含前面两种情况，因此下面直接分析这个过程。

Service 的宿主进程起来后，在执行 attach application 的过程中，AMS 会自动启动那些等待进程起来的 Service，如下

最终调用 ActiveServices#attachApplicationLocked() 完成 Service 的启动

终于，我们看到了我们想看到的东西，先从 mPendingServices 中过滤掉不属于进程的 Service，然后启动它

现在，正式与宿主进程交互来启动 Service

首先通过 IApplicationThread#scheduleCreateService() 来通知宿主进程创建 Service。

然后通过 IApplicationThread#scheduleServiceArgs() 把参数发送给宿主进程，宿主进程会把参数发送给 Service 执行任务。

宿主进程接收到创建 Service 的指令后，会通过 Handler 发送一个消息，最终调用如下方法

宿主继承会先创建 Application，并执行 Application#onCreate()，然后创建 Service，并执行 Service#onCreate()，最后通知服务端 Service 创建成功。这一套流程，简直行云流水。

宿主进程接收到服务端发送过来的 Service 启动参数后，最终调用如下方法

当宿主进程收到 Service 的启动参数后，调用 Service#onStartCommand() 接收参数，并执行任务。

注意，Service#onStartCommand() 是在主线程中执行，其实四大组件的生命周期都是在主线程中执行的，这一点大家要牢记。

然后把 Service#onStartCommand() 的返回结果返回给服务端。这个方法的返回结果很重要，它影响了 Service 重启的方式。这里简单展示下结果的处理流程

这里就涉及到 Service 的基本功，上面展示了两个返回值的处理过程，这两个返回值都表示，由于内存不足而杀掉的 Service，当内存充足时，会重启 Service，但是一个返回值需要再次发送之前的启动参数，而另外一个返回值不需要。

对于需要发送参数的返回值，不需要从 Service#deliveredStart 列表中删除已经发送的参数，因为 Service 重启时，需要发送它。相反，就需要从列表中删除已经发送的参数，因为 Service 重启不再需要它了。