来谈谈SystemServer

参考博客：
http://blog.csdn.net/myfriend0/article/details/55098173

源码位置：
frameworks/base/services/java/com/android/server/SystemServer.java

System Server是android 基本服务的提供者，是android系统运行的最基本需求，所有service运行在一个叫system_server的进程中，system_server进程是android java虚拟机跑的第一个进程，从Zygote 创建而来，是andorid系统最重要的java虚拟机。可以说，整个android系统的业务都是围绕system server而展开，所以，当system_server死掉了，手机必须重启。

从Zygote创建system_server进程时，便实例化了该类

SystemServiceManager 与 ServiceManager

SystemServiceManager在SystemServer类中被创建，运行在进程ServiceManager中，用SystemServiceManager.startService()初始化一部分的SystemService，（为什么说是只是初始化一部分SystemService呢？因为还有一部分在ServiceManager中初始化），SystemServiceManager可能也是一个service

ServiceManager不知道在哪被创建（也许是因为平时都是调用它的static getService()方法，所以不用创建对象），不知道运行在哪个进程，用ServiceManager.addService()初始化一部分SystemService，本身是 一 个 Service

各个SystemService的管理者应该是ServiceManager而不是SystemServiceManager，因为ServiceManager有getService()和addService()方法，用于获取和初始化系统服务，这就体现了管理的职能；而SystemServiceManager虽然有startService()初始化系统服务，但却没有类似于getService()获取系统服务的对外方法。
这观点不同于参考博客一中说的SystemServiceManager是系统服务的管理者，我的观点在《Android内核剖析》中也有体现！

（ps：SystemServiceManager和ServiceManager的不同在下文提到）

ServiceManager与各个service的manager是什么关系？答案如下

在Framework层中registerService()方法有以下情况：
1.一般情况下通过ServiceManager.getService获得各个service的binder引用，然后再通过这个引用生成相应的manager对象，可以说是ServiceManager统一管理各个service的Manager。ServiceManager是各种manager的对外暴露接口

2.不过也有一些services是有manager，但是没有通过ServiceManager.getService获得各个service的binder引用，然后再去new出manager，而是直接new出manager。

3.但是会有一些service是没有mannger的，例如VIBRATOR_SERVICE震动服务，那怎么调用service呢？
答案是通过ServiceManager获得各个service的引用，然后再通过这个service引用生成相应的具有类似manager具有管理service能力的对象

以上情况可以参考源码的frameworks/base/core/java/android/app/SystemServiceRegistry.java中的static代码块，当中有很多的registerService()方法对应不同的services

这里有个问题就是各个service的manager又是运行在哪个进程中？
答案是运行在system_server进程

--为啥会造成以上不同的情况呢？造成不同意的原因是各种services的实现不同吗？或者是因为SystemServer启动服务的三种方式所致？

SystemServer启动服务的三种方式：
SystemServiceManager.startService()
LocalServices.addService()
ServiceManager.addService()

首先关于这三种方式的不同点，经过验证发现在源码android 5.1中有一些观点和参考博客不同：
1.LocalServices.addService()只用于在run()方法中
LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);把SystemServiceManager的引用设置到LocalServices，然后并没有发现用于启动其他服务，并没有见到在startBootstrapServices()、startCoreServices()中有使用。这个观点和参考博客中：“startBootstrapServices()、startCoreServices()中见到SystemServiceManager.startService()和LocalServices.addService()的方式”的观点有冲突。

2.博客一中的更详细关于这三种方式的不同点见下图

20171031.png

自己验证结论与上图的观点的差异：

1.SystemServiceManager.startService()启动的系统服务的确是SystemService的子类，启动这些服务后会回调SystemService的onStart()方法。（PS：我是觉得继承了SystemService就会得到进程通信的能力，但是看了SystemService的源码还没发现！）
但是也会有个别情况是继承service类中的LifeCycle内部类，而且这些service是一般继承与Stub类，这个stub类就是用AIDL写的，
但有时这个LifeCycle内部类是不存在于对应的service类中。（那么找不到的话会不会是在SystemServiceManager.startService()中有判断呢？但是看了startService()的实现是没有LifeCycle内部类是否存在的判断，所以现在还是不理解！！！）

ServiceManager.addService()启动的系统服务的确是实现了Android IPC 的Binder的子类，因为这些service是一般继承与Stub类，这个stub类就是用AIDL写的，但是说这些服务启动后会调用systemReady()或systemRunning()方法，这还没找到根据！

然后就是上图的第2点，第3点，第4点都觉得是无关痛痒，没有什么价值。

SystemServiceManager与ServiceManager有啥不同？或者是有啥关联？
暂时不知道

不过SystemService倒是和ServiceManager与LocalServices有关联，在SystemService中有以下代码：

    protected final void publishBinderService(String name, IBinder service, boolean allowIsolated) {
        ServiceManager.addService(name, service, allowIsolated);
    }

    protected final IBinder getBinderService(String name) {
        return ServiceManager.getService(name);
    }

    protected final <T> void publishLocalService(Class<T> type, T service) {
        LocalServices.addService(type, service);
    }

    protected final <T> T getLocalService(Class<T> type) {
        return LocalServices.getService(type);
    }

    private SystemServiceManager getManager() {
        return (SystemServiceManager)LocalServices.getService(SystemServiceManager.class);
    }

LocalService：

SystemServiceManager的实例通过LocalServices.addService(SystemServiceManager.class, mSystemServiceManager)语句设置到LocalService中，LocalServices的功能类似SystemServiceManager，不同点在于LocalServices专门用来管理system_process进程中的SystemService，也就没有真正的跨进程通信，也就没有Binder对象。

• getLocalService()
  应用层一般很少用这种方式去获取services，例如getLocalService(LightsManager.class);
• Context.getSystemService()，例如Context.getSystemService(Context.VIBRATOR_SERVICE)；
  应用层常用这种方式去获取services
• ServiceManager.getService（）
  不用于应用层的调用，只是用于应用层在使用Context.getSystemService()时，在framework层的方法调用到而已