android启动service

1. AndroidFramework 之启动 ServiceManager

本文源码基于 Android 10 ，涉及相关源码如下。

ServiceManagaer 是 Binder 的守护进程，在 Binder 机制中起着重要的作用。本文将从源码的角度对其进行分析，整体流程如下：

时序图如下。

先来看看 ServiceManager 是如何启动的：

在 Zygote 一文中说过， init 进程启动的第二阶段会解析 init.rc 文件。

在这之后会触发 trigger init 。

结合 init.rc 看看 action init 做了什么。

当触发 trigger init 后，会启动 servicemanager 服务，其声明如下。

对应的执行文件为 /system/bin/servicemanager ，在编译前位于 frameworks/native/cmds/servicemanager 下，来看看 Android.bp 。

其对应的源码为 service_manager.c 和 binder.c ，入口函数 main() 位于 servicemanager.c 。

启动完 ServiceManager 后会打开 Binder 驱动。

在 main() 中首先调用 binder_open() 。

binder_open() 主要做了如下事情：

给结构体 binder_state 分配内存。

系统调用 open() 打开 /dev/binder ，如果打开驱动失败，则执行 fail_open 释放内存。

简单的解释一下什么是系统调用？

由于需要限制不同的程序之间的访问能力，防止程序获取别的程序的内存数据， CPU 划分出两个权限等级， 用户态 和 内核态 。

所有的用户程序都是运行在用户态，但有时需要做一些内核态的事情，而唯一可以做这些事情的就是操作系统，所以程序需要向操作系统发起请求，以程序的名字来执行这些操作。这时就需要一个从用户态切换到内核态但不能控制内核态中执行的机制，这种机制就是 系统调用 。

系统调用 ioctl() 传入 BINDER_VERSION 命令获取 Binder 驱动版本，对比版本是否一致，不一致则执行 fail_open 释放内存。

系统调用 mmap() 映射 128kb 的内存空间，即把 Binder 驱动文件的 128kb 映射到内存空间供 ServiceManager 使用，内存映射失败则执行 fail_map ，关闭 fd 并释放内存。

ServiceManager 进程 mmap 的内存大小可以通过 adb shell 命令查看。

可以看到内存映射地址为 0xf10f8000 ~ 0xf1118000 ，差为 0x20000 即十进制的 128kb 。

打开 Binder 驱动后会将 ServiceManager 设置为上下文管理者。

调用 binder_become_context_manager() 。

android 10 新增 BINDER_SET_CONTEXT_MGR_EXT 命令来设置安全的上下文管理者，如果设置失败，则使用原有的 BINDER_SET_CONTEXT_MGR 命令来设置上下文管理者，两者区别在于是否携带参数。

最后会进入循环，从 Binder 驱动读取和解析数据。

调用 binder_loop() 进入循环，不断地通过系统调用 ioctl() 从 Binder 驱动读取数据，并通过 binder_parse() 进行数据解析。

注意这里调用 binder_loop() 传入的 svcmgr_handler() ，后面会使用到。

binder_write() 会封装 struct binder_write_read ，并通过系统调用 ioctl() 将对应的命令传递给 Binder 驱动。

binder_parse() 用来解析从 Binder 驱动读取到的数据，然后根据不同的命令执行对应的操作。

因为 cmd 命令可能有多个，所以通过 while 循环每次处理一个 cmd 命令，多 cmd 的结构大致如下图所示。

这里重点看下 BR_TRANSACTION 命令。

BR_TRANSACTION 是 Binder 驱动向 Server 端发送请求数据。

binder_transaction_data 的结构如下，其表明了 transcation 传输的具体语义，语义码记录在 code 中，不同语义码携带的数据是不同的，这些数据由 data 指定。

在解析完 binder_transaction_data 的具体语义后，会调用前面传给 binder_loop() 的 svcmgr_handler() ，其实就是 switch case 语义码做不同的事情。

ServiceManager 的功能其实很简单：

至此 ServiceManager 就分析完了。

2. Android中怎么启动关闭Service及功能解释

下面根据问题，作出详细解答：

1. Service不是分离开的进程，除非其他特殊情况，它不会运行在自己的进程，而是作为启动运行它的进程的一部分。

2. Service不是线程，这意味着它将在主线程里劳作。

   
   

启动service有两种方法：

1. Context.startService()调用者与服务之间没有关联，即使调用者退出，服务仍可运行

2. Context.bindService() 调用者与服务绑定在一起，调用者一旦退出，服务也就终止

Service的生命周期

如果使用startService()启动service，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate，然后运行onStartCommand （可在里面处理启动时传过来的Intent和其他参数），直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。

控制service运行的主要方式有两种，主要是根据onStartCommand方法返回的数值。方法：

1. START_STICKY

2. START_NOT_STICKY or START_REDELIVER_INTENT

   
   

这里主要解释这三个变量的意义：

1. START_STICKY

   在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent

2. START_NOT_STICKY

   在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。

3. START_REDELIVER_INTENT

   在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。

   
   

客户端也可以使用bindService来保持跟service持久关联。谨记：如果使用这种方法，那么将不会调用onstartCommand（跟startService不一样，下面例子注释也有解析，大家可试试）。客户端将会在onBind回调中接收到IBinder接口返回的对象。通常IBinder作为一个复杂的接口通常是返回aidl数据。

Service也可以混合start和bind一起使用。

要运行service，首先必须在AndroidManifest.xml里申明<service>标签。

Service能够保护个人的IPC调用，所以在执行实现该调用时前先使用checkCallingPermission(String) 方法检查是否有这个权限。

进程生命周期

当service运行在低内存的环境时，将会kill掉一下存在的进程。因此进程的优先级将会很重要：

1. 如果service当前正在执行onCreate、onStartCommand、onDestroy方法，主进程将会成为前台进程来保证代码可以执行完成避免被kill

2. 如果service已经启动了，那么主进程将会比其他可见的进程的重要性低，但比其他看不见的进程高。因为只有少部分进程始终是用户可见的，因此除非在极度低内存的时候，不然 service是不会被kill的。

3. 如果有客户端关联到service，那么service永远比客户端重要。也就是说客户端可见，那么service也可见（我理解这里的可见并不是可以看到，而是重要性，因为可见往往就表示重要性高）。

4. Service可以使用startForeground API将service放到前台状态。这样在低内存时被kill的几率更低，但是文档后面又写了，如果在极度极度低内存的压力下，该service理论上还是会被kill掉。但这个情况基本不用考虑。

当然如果service怎么保持还是被kill了，那你可以通过重写onStartCommand返回变量来设置它的启动方式。比如：START_STICKY、START_REDELIVER_INTENT等等，前面已经讨论了它们的作用，这里就不再累赘了

另外：

service 的onCreate和onStartCommand 是运行在主线程的，所以如果里面有处理耗时间的任务。两种处理：

1. 请将它们都挪到新的线程里。

2. 用系统提供的IntentService，它继承了Service，它处理数据是用自身新开的线程。

3. 如何在android系统中开启自己的服务

Android开机启动Service，需要使用BroadcastReceiver,Android系统，开机会发送一个开机广播，可以通过BroadcastReceiver来接收开机广播。
具体代码:
1.在配置文件AndroidManifest.xml中向系统注册receiver
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>

2.需要添加相应权限
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

3.在Receiver中就可以添加开机需要进行的操作
public class BootCompletedReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {

}
}

4.执行开机后的操作，Intent intent = new Intent(context,Service.class); context.startService(intent); 这样即可开机启动Service了。

4. Android中怎么启动关闭Service及功能解释

启动：
//首先注册服务
<service
android:name="com.wangdeyu.service.MusicService"
android:exported="false" >
<intent-filter>
<action android:name="com.abc" />
</intent-filter>
</service>

//启动服务
Intent service=new Intent(" com.abc");
startService(service);
//Service生命周期
①onCreate() 创建Service
②onStart(Intent intent, int startId) 启动Service
③onDestroy() 销毁Service
//关闭服务
stopService(service);

Service的生命周期方法比Activity少一些，只有onCreate, onStart, onDestroy
我们有两种方式启动一个Service,他们对Service生命周期的影响是不一样的。
1 通过startService,就是上面这种
Service会经历 onCreate --> onStart
stopService的时候直接onDestroy
如果是 调用者 直接退出而没有调用stopService的话，Service会一直在后台运行。
下次调用者再起来仍然可以stopService。
2 通过bindService
Service只会运行onCreate， 这个时候 调用者和Service绑定在一起
调用者退出了，Srevice就会调用onUnbind-->onDestroyed
所谓绑定在一起就共存亡了。
注意：Service的onCreate的方法只会被调用一次，
就是你无论多少次的startService又 bindService，Service只被创建一次。
如果先是bind了，那么start的时候就直接运行Service的onStart方法，
如果先是start，那么bind的时候就直接运行onBind方法。如果你先bind上了，就stop不掉了，
只能先UnbindService, 再StopService,所以是先start还是先bind行为是有区别的。
Android中的服务和windows中的服务是类似的东西，服务一般没有用户操作界面，它运行于系统中不容易被用户发觉，可以使用它开发如监控之类的程序。
服务不能自己运行，需要通过调用Context.startService()或Context.bindService()方法启动服务。
这两个方法都可以启动Service，但是它们的使用场合有所不同。使用startService()方法启用服务，调用者与服务之间没有关连，
即使调用者退出了，服务仍然运行。使用bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止，大有“不求同时生，必须同时死”的特点。
如果打算采用Context.startService()方法启动服务，在服务未被创建时，系统会先调用服务的onCreate()方法，
接着调用onStart()方法。如果调用startService()方法前服务已经被创建，多次调用startService()方法并不会导致多次创建服务，
但会导致多次调用onStart()方法。采用startService()方法启动的服务，只能调用Context.stopService()方法结束服务，服务结束时会调用onDestroy()方法。
如果打算采用Context.bindService()方法启动服务，在服务未被创建时，系统会先调用服务的onCreate()方法，
接着调用onBind()方法。这个时候调用者和服务绑定在一起，调用者退出了，系统就会先调用服务的onUnbind()方法，
接着调用onDestroy()方法。如果调用bindService()方法前服务已经被绑定，
多次调用bindService()方法并不会导致多次创建服务及绑定(也就是说onCreate()和onBind()方法并不会被多次调用)。
如果调用者希望与正在绑定的服务解除绑定，可以调用unbindService()方法，调用该方法也会导致系统调用服务的onUnbind()-->onDestroy()方法.

5. Android 10.0 ActivityManagerService的启动流程

我们讲完了SystemServer的启动过程，本节主要来讲解ActivityManagerService的启动过程。ActivityManagerService简称AMS，管理Activity行为，控制Activity的生命周期，派发消息事件，内存管理等功能。

ActivityManagerService启动由SystemServer中startBootstrapService启动

ATM启动最终调用的是ActivityTaskManagerService.Lifecycle.onStart()来启动ATM服务的
源码：ActivityTaskManagerService.java#Lifecycle.class

将ActivityTaskManagerInternal添加到本地服务的全局注册表中。
ActivityTaskManagerInternal为抽象类，其实现类为ActivityTaskManagerService#LocalService.class

构造函数初始化主要工作就是初始化一些变量，供之后的service，broadcast，provider的管理和调度

start中做了两件事

AMS的systemReady处理分为三个阶段

同时获取一些配置参数。 需要注意的是，由于只有Java进程才会向AMS注册，而一般的Native进程不会向AMS注册，因此此处杀死的进程是Java进程。

主要是调用一些关键服务的初始化函数，然后杀死那些没有FLAG_PERSISTENT 却在AMS启动完成前已经存在的进程，同时获取一些配置参数。需要注意的是，由于只有Java进程才会向AMS注册，而一般的Native进程不会向AMS注册，因此此处杀手的进程是Java进程。

执行goingCallback的处理，主要的工作就是通知一些服务可以进行systemReady相关的工作，并进行启动服务或应用进程的工作

监控Native的crash，启动WebView，执行一些服务的systemReady和systemRunning方法

启动Home Activity，当启动结束，发送ACTION_BOOT_COMPLETED广播时，AMS的启动过程告一段落

启动Home Activity

AMS的启动主要经历了如下几个阶段：