diff --git a/blogs/Android/口水话/四大组件的启动流程口水话.md b/blogs/Android/口水话/四大组件的启动流程口水话.md
index 3267bef..12bd40e 100644
--- a/blogs/Android/口水话/四大组件的启动流程口水话.md
+++ b/blogs/Android/口水话/四大组件的启动流程口水话.md
@@ -25,4 +25,19 @@ Launcher 组件是如何获取这些信息的呢？其实是在系统启动时
 
 在 handleLauncherActivity 中，通过 Instrumentation 的 newActivity 去创建这个 Activity，然后创建 Application 对象以及 ContextImpl ，最后调用 Activity 的 attach 函数，这个函数里面会 new 一个 PhoneWindow 并关联 WindowManager，也就是 Activity 显示流程的入口函数了。最最后会调用到 Activity 的 onCreate 函数。
 
-至此，Activity 的启动流程讲完了。如果是非根 Activity 的启动呢，只需要去掉创建应用程序进程那一步即可。
\ No newline at end of file
+至此，Activity 的启动流程讲完了。如果是非根 Activity 的启动呢，只需要去掉创建应用程序进程那一步即可。
+
+#### Service 的启动过程
+
+首先说一下非绑定 Service 的启动过程。
+
+在我们调用 Context 的 startService 方法时，是调用了 ContextImpl 的 startService，这个方法同样是获取 AMS 的代理对象，然后向 AMS transact 一个 START_SERVICE 请求。在 AMS 的 startServiceLocked 去处理这个请求。在 AMS 中，每一个 Service 组件都是用一个 ServiceRecord 对象来描述，就像每一个 Activity 组件都使用一个 ActivityRecord 对象来描述一样。
+
+在 startServiceLocked 中，会首先向 AMS 中查找是否存在与参数 Intent 对应的一个 ServiceRecord 对象，如果不存在，就会到 PKMS 中去获取这个 Intent 对应的 Service 组件的信息，然后封装成一个 ServiceRecord 对象，最后调用 bringUpServiceLocked 来启动这个 Service。
+
+在 bringUpServiceLocked 中，同 Activity 的启动一样，都会去首先判断该 Service 组件所在的应用程序进程是否已经存在，如果不存在就会先去创建应用程序进程，创建完成之后会把 ApplicationThread 传递给 AMS，以便 AMS 可以和这个新创建的应用程序进程通信。接着，就是 realStartServiceLocked，这个方法无非就是通过 ApplicationThread 向应用程序进程发送一个 CREATE_SERVICE 进程间通信请求，在应用程序进程是如何处理的呢？其实还是老样子，往主线程 Handler 发现一个消息，然后调用 handleCreateService。
+
+在 handleCreateService 中，会通过 LoadedApk 的 ClassLoader 去加载这个 Service 类，然后在创建一个 ContextImpl，最后调用 Service 的 attach 和 onCreate 函数。
+
+至此，非绑定 Service 组件的启动流程就讲完了。下面再来说说绑定服务的启动流程。
+