在之前 Android 系统服务管理 ServiceManager 中学习了各种系统服务 Service 都是通过 ServiceManager 来管理的，从 ServiceManager 中来获得系统服务的 Binder 对象引用。这内容涉及到了 ContextImpl 类、SystemServiceRegistry 类、ServiceManager 类、ServiceManagerNative 类等等。

那么问题就来了，ServiceManager 所管理的那些 Service 的 Binder 对象引用又是何时注册添加的呢？

事实上这些服务 Service 是 SystemServer 进程中启动的。

在应用程序编程时，经常使用到 getSystemService(String serviceName) 方法来获得一个系统服务，它的实现也是在 ContextImpl 中的，根据不同的参数返回不同的系统服务，这些系统服务都是由 ServiceManager 管理的。

总结一下 Material Design 控件使用。

总结一下 Material Design 控件使用。

Dagger2 是一个进行依赖注入的框架，早先是由 Square 公司写的，后来由 Google 来维护了，能由 Google 亲自维护的东西，肯定值得学习。

在如下三篇文章中过了一遍 Launcher 启动 Activity 的代码流程。

• Android 6.0 Launcher 启动 Activity 过程源码分析（一）
• Android 6.0 Launcher 启动 Activity 过程源码分析（二）
• Android 6.0 Launcher 启动 Activity 过程源码分析（三）

然而， 即使看过了多遍代码流程依旧有点云里雾里的感觉。不从整体上来把握，光抓住细节代码会始终不得要领。

由于是从 Launcher 组件启动一个 Activity 组件，其中还需要与 ActivityManagerService 通信，而这三个部分都是位于不同的进程内，涉及进程间通信，因此可以将整个过程划分为三个不同的部分来分析，在 Launcher 进程内的操作，在 ActivityManagerService 进程内的操作，在创建的应用程序进程内的操作。

在 Android 6.0 Launcher 启动 Activity 过程源码分析（二） 分析完了对待启动 Activity 组件的验证过程，获得组件信息，以及 ActivityRecord 添加至栈顶，将其他 Activity 进入中止状态，最后将待启动的 Activity 组件进入 Resumed状态，然而，由于待启动的 Activity 组件的应用程序进程尚未启动，最后执行 startSpecificActivityLocked方法创建进程。

在 Android 6.0 Launcher 启动 Activity 过程源码分析（一） 分析完了 Launcher 组件中启动的步骤，接下来的环节是该 ActivityManagerService 出场了。

通过 ActivityManagerNative.getDefault() 方法得到 ActivityManagerService 的代理对象后执行的 startActivity 方法，最终会发起进程间通信请求，通过 Binder 驱动，再调用 ActivityManagerService 中对应的方法。

当 Android 系统在启动时，会扫描系统特定目录，然后自动安装里面的 Android 应用程序。当系统启动完成之后，会启动一个 Home 应用程序来显示安装在系统中的 Android 应用程序。

这个应用程序就是 Launcher 应用，也就是手机屏幕上显示的各种应用图标，Launcher 是 Android 系统启动的第一个应用程序。

而当我们点击应用程序图标时，也就开启了从 Launcher 启动 Activity 的过程。

在知乎上看到这样一个问题：RxJava正确的封装callback的方式应该是怎么样的？。虽说已经是个一年前的问题了，自己现在才遇到 (羞愧脸) 。