落魄影子

总结下第三阶段干的任务：上图3中的ClientTransaction流程中，会进行一次跨进程调用，进入到app的进程，在主进程中会调用Binder线程IAppicationThread中的方法（它是app的子线程），就是在ClientTransactionHandler中会向主线程发送消息，这里又进行了一次子线程向主线程的消息传递过程，主线程在处理的时候，就会调用真正的执行触发器 mTransactionExecutor 去执行对应的transaction，触发生命周期的管理。

application启动时，会通过AMS的IBinder远程调用ApplicationThread的BindApplication(),在创建App的时候，先创建Application对象，然后再进行installProvider等后续的处理，处理的过程主要做两件事，一个是创建ProcessRecord并登录在ProcessList中，然后是开始执行ActivityStackSupervisor的realStartActivityLocked方法，开启activity生命周期流程的执行。

补充一个要点：ApplicationThread是什么？分析时需要注意的是，底层调用linux fork()接口之后，会有两个返回值，如果pid =0,表示返回的是子进程，如果pid >0,返回的是父进程（即zygote的程序运行路线），父进程（zygote进程）可以得知子进程的pid号。上一篇讲了Zygote是如何收到启动Application的启动消息,并一步步进入Fork()，下面来分析zygote fork启动application后，application进程后续处理操作，是如何真正的启动的。

但是现在要讨论的是APP进程不存在的时候，这个APP的启动流程，这种启动方式会覆盖所有app的启动流程。如果进程存在， 直接走上面的第五步，这一步的处理过程也是跨进程通信的，通过获取APP进程在AMS中的客户端代理即ApplicationThreadProxy， 通过这个代理Binder远程调用app进程的scheduleLauncherActivity()方法直接启动进程中的Activity,这个流程是基于APP进程已经存在了，所以走的是第5和6步分支。以上两种方式均可触发app进程的启动。

通过Binder给到Application使用，我们需要将这些ATMS\AMS等服务的Binder注册进ServiceManager. Application要使用它们的时候，会去公共的ServiceManager中去查找对应的ATMS或AMS的binder，通过他们提供的Binder接口来使用这些服务的。解决办法：可以在类里面创建一个内部类(LiftCycle)，内部类去继承需要的父类SystemService，在这个内部类里面与我们的外部类（ATMS）结合来完成所有的功能。把这些关键的信息收集起来。

是SystemServer中的一个非常重要的类，得力助手，SystemServer通过它管理各种Services,如AMS, WMS, PKMS等，并且这些服务必须封装成一个对象，这个类就是SystemService，也就是说SysermServiceManager管理的都是SystemService的类对象。系统各类服务需要封装的类，每一种系统服务都要直接或间接的继续这个SystemService类，成为一个SystemService的类对象，方便让SystemServiceManager统一管理。

前面的流程是说明Zygote进程如何fork创建出SystemServer进程，需要知道的是SystemServer进程被fork()出来之后，到底是如何运行的，如果这个逻辑研究明白了，Zygote fork其它进程后，它们的运行逻辑也是相同的。linux程序在调用fork之后，如果创建成功，会返回两个pid, 其中一个是孩子的pid，上面代码在这个过程分析的时候需要特别注意。它主要承担的职责是为APP的运行提供各种服务，像AMS,WMS这些服务并不是一个独立的进程，

因此，zygote进程的所有的目的是为了生孩子 ，通过zygote启动app，而app是java层代码，它要运行，需要JVM的支持，所以zygote需要先准备好Jvm提前准备好虚拟机，并且app在启动后，可能需要调用访问C++ Native代码，这时需要JNI的支持，所以JNI的注册也放到了zygote进程中，也提前准备好了。所需要的一些java资源，包括系统资源，系统库，classes，RES等，因为这些资源app的java都有可能去调用的。

zygote的程序源文件为app_main.cpp: 根据frameworks/base/cmds/app_process/Android.bp找到对应的cpp文件。也就是说app_process这个可执行程序的名称其实就是zygote, 它的C++源文件是app_main.cpp.zygote在启动时，在init.${ro.zygote}.rc脚本中，里面描述了zygote是如何被启动的，当init进程解析到zygote.rc文件时，将根据解析出来的命令启动zygote.

然后进入bootloader，在安卓系统中基本上这个bootloader是uboot, 通过uboot引导启动内核，此时运行在kernel空间，这时的idle属于内核中的进程，它的pid = 0,它负责初始化进程、内存、驱动等相关工作，随后由idle启动fork一个为init进程，这个属于用户空间的进程，pid = 1，然后再fork创建pid=2的kthreadd内核进程，这个是内核进程的鼻祖。init进程则是用户空间的鼻祖，应用空间的所有进程要么直接或间接都是由init进程创建的。

它其实是一个独立的进程，由init解析init.rc文件并由它创建，要早于zygote进程，ServiceManager的main函数进程文件位于：framework/native/cmds/servicemanager/main.cpp。下面先给出一个非常重要的结论，就是ServiceManager的父类继承关系，最顶层的父类是IServiceManager和BBinder，后面的源码分析的时候这个很有用，否则看不懂代码。下面是ServiceManager在init.rc中的描述。

通过前面的代码分析，可以得到一个结论，ServiceManager的Binder封装过程如下图所示：其它所有服务端提供的Service的Binder的封装逻辑也是相同的逻辑，举一反三。SM内存放着许多的数组，可以通过getService(String name)获取到对应用Binder,这是键值对。

现在要搞明白JAVA层app调用跨进程的Service接口时，它的binder是怎样从Java->jni-->native--->binder驱动的这条链路：就是上图中的左半部分从上至下的流程。上面就是整体的调用流程，非常的清晰明了。

第5步：server收到schduleBindService()后不能直接把它的IBinder发给Client，它也只能通过AMS，所以它调用AMS的getService获取AMS服务。第7步：Server调用AMS的publishService服务，将Server的IBinder发送给Client,通过调用client的connected()接口。//拿到AMS的binder，然后调用它的publishService方法将Server端的binder送出去。//对象表示一个Service.

通过本文了解Android通信机制的核心思想

思路从最上层调用到底层编写，流程如下：1 实现与APP直接对接的操作硬件的接口，这个最简单。只需要实现AIDL文件（Android Interface Define Language)，其目的是让安卓系统自动帮我们实现对应用JAVA接口文件。PS:可以搜索源码中的例子比如：IVibrator.aidl，修改成如下代码：package.android.osInterfac

如果某个硬件资源只能被某一个应用使用，可以使用下面的方法访问硬件：JAVA APP--->JNI_OnLoad（）加载C库---->将JAVA三个地方法与C库函数进行关联并注册---->调用JAVA本地Native方法就可以访问C库的C接口------>进而访问硬件驱动中的open, read, write，从进访问硬件。但是，以上场景仅限于只有一个APP使用这个硬件资源，如果有多

最近由于项目的开发需要，需要用到安卓系统，由此开始安卓的一些学习，下面只作为个人的一些记录。        安卓应用是由java编写的，而在android底层，如安卓底层的硬件驱动程序，都是由C/C++编写的，那应用层java是必须通过某种手段才能使用底层提供的硬件资源。毫无疑问，在java看要调用底层C实现的代码，中间必须要有一层接口，那就是JNI。本例要实现的就是JAVA如何访问底层C库。

注：本文的主要目的是为了记录自己的学习过程，也方便与大家做交流。转载请注明来自：http://blog.csdn.net/ab198604一、修改从机端代码（Server端)：A 对Profile的修改如果要使用Notification或Indification方法，必须在Profile中添加configuration，如下：

TI BLE