继续上篇的app启动，本篇将从zygote接受到消息跟到activity启动。
下一篇将着重分析应用进程加载代码与资源的过程，并分析实现应用壳的加载方案。
ActivityStarter是Android 7.0新加入的类，它是加载Activity的控制类，会收集所有的逻辑来决定如何将Intent和Flags转换为Activity，并将Activity和Task以及Stack相关联。
参考文：
http://duanqz.github.io/2016-10-23-Activity-LaunchProcess-Part2#%E6%A6%82%E8%A7%88
gityuan
当系统决定要在一个新的进程中启动一个Activity或者Service时，ActivityManagerService组件负责通知Zygote创建一个新的进程，然后在这个新的进程中启动这个Activity或者Service。
Android应用程序架构中非常核心的一点：MainActivity不需要知道SubActivity的存在，即它不直接拥有SubActivity的接口，但是它可以通过一个字符串来告诉应用程序框架层，它要启动的Activity的名称是什么，其它的事情就交给应用程序框架层来做，这种模式大大降低了模块间的耦合，利于开发。
对于每一个应用程序来说，都有一个ActivityThread来表示应用程序的主进程，而每一个ActivityThread都包含有一个ApplicationThread实例，它是一个Binder对象，负责和其它进程进行通信。
Binder是Android系统进程间通信（IPC）方式之一。
目前linux支持的IPC包括传统的管道，System V IPC，即消息队列/共享内存/信号量，以及socket中只有socket支持Client-Server的通信方式。
而Client-Server的通信方式在android系统中被广泛使用，诸如媒体播放，视音频频捕获，到各种让手机更智能的传感器（加速度，方位，温度，光亮度等）都由不同的Server负责管理，应用程序只需做为Client与这些Server建立连接便可以使用这些服务，花很少的时间和精力就能开发出令人眩目的功能。因此需要高效的CS通信。
传输性能方面：socket通用主用于跨网络性能低，消息队列与管道都是二次拷贝，共享性能控制复杂。binder只有一次拷贝。
安全性：传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。接入点开放，无法私有通道。
Binder是一个实体位于Server的对象，client使用它的句柄调用其方法
Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。形形色色的Binder对象以及星罗棋布的引用仿佛粘接各个应用程序的胶水，这也是Binder在英文里的原意。
Binder的四个角色：Server、Client、ServiceManager、Binder驱动。驱动位于内核空间。与互联网类似：服务器、客户端、域名服务器、路由器
https://blog.csdn.net/universus/article/details/6211589
目前知道：可用于进程间通信，大量用于android各层即可。
参考文：
http://duanqz.github.io/2016-07-29-Activity-LaunchProcess-Part1#%E6%A6%82%E8%BF%B0
老罗
gityuan
不得不说http://duanqz.github.io/ 这位大佬的博客写的太详细了而且版本很新……接下来尽量都看完
总结下android应用开发中常出现的依靠第三方加固无法解决的代码漏洞问题。这些代码漏洞通常可用自动化检测工具检验。搭建行为检测检验环境也是十分有效的做法。
https://www.zhihu.com/question/22933619/answer/392842386
https://blog.csdn.net/whklhhhh/article/details/79116894
2014年6月25日，Android L-5.0 正式亮相于召开的谷歌I/O大会，Android L 改动幅度较大，谷歌将直接删除Dalvik，代替它的是传闻已久的ART。
安装后：data/data放应用私有数据，data/app放apk、lib、oat(vdex\odex\art 文件魔数为vdex、elf、art)
date/dalvik-cache放虚拟机执行码的(vdex\oat\art)
旧的优化叫dexopt,现安装时调用/system/bin/dex2oat（8.1.0下存在）编译
无论是对dex字节码进行优化，还是将dex字节码翻译成本地机器码，最终得到的结果都是保存在相同名称的一个odex文件里面的，但是前者对应的是一个dey文件（表示这是一个优化过的dex），后者对应的是一个oat文件（实际上是一个自定义的elf文件，里面包含的都是本地机器指令）。
应用程序的安装发生在两个时机，第一个时机是系统启动的时候，第二个时机系统启动完成后用户自行安装的时候。在第一个时机中，系统除了会对/system/app和/data/app目录下的所有APK进行dex字节码到本地机器码的翻译之外，还会对/system/framework目录下的APK或者JAR文件，以及这些APK所引用的外部JAR，进行dex字节码到本地机器码的翻译。这些都挂载在存储中了。
在ART中，打包在APK里面的Dex字节码是通过LLVM翻译成本地机器指令的–现在的加固也需要研究这个。
oat结构：
加了俩个段oatdata和oatexec，分别用来储存原来打包在APK里面的dex文件和翻译这个dex文件里面的类方法得到本地机器指令。
动态段（dymanic section，用于以数组指向动态连接器所需信息，该段在程序头表与节头表中都有指向）中添加了三个符号oatdata、oatexec和oatlastword分别用来描述oatdata和oatexec段加段到内存后的起止地址。
在oatdata段中，包含了两个重要的信息，一个信息是原来的classes.dex文件的完整内容，另一个信息引导ART找到classes.dex文件里面的类方法所对应的本地机器指令，这些本地机器指令就保存在oatexec段中。
可见oat中含有完整的dex文件。
我们在classes.dex文件中有一个类A，那么当我们知道类A的名字后，就可以通过保存在oatdata段的dex文件得到类A的所有信息，比如它的父类、成员变量和成员函数等。另一方面，类A在oatdata段中有一个对应的OatClass结构体。这个OatClass结构体描述了类A的每一个方法所对应的本地机器指令在oatexec段的位置。也就是说，当我们知道一个类及其某一个方法的名字（签名）之后，就可以通过oatdata段的dex文件内容和OatClass结构体找到其在oatexec段的本地机器指令，这样就可以执行这个类方法了。
art加载运行壳时是加载优化后的oat代码，但壳用classloader加载dex时会为其生成oat文件，可能会破坏处理的dex，hook掉可以运行dex但会慢，所以为了提升速度不会阻止dex优化为oat，也就是说原dex尽力保留了，因此采用大块的native化进行加固！
基于https://blog.csdn.net/luoshengyang/article/details/8852432的分析整理。
涉及dalvik启动过程，运行过程
目标为搞懂虚拟机native中的本质。现在基本都不用dalvik了，在我的8.0机子下persist.sys.dalvik.vm.lib.2=libart.so 表示用art虚拟机，dalvik已经完全不见踪影。
linux下分析：
vim:
:sp可直接分屏，ctrl+w切换分屏，ctrl+w+o只留选中的
:/用来搜索 按n下一个、N上一个 光标选中单词shift+*直接搜索该单词
基于栈的虚拟机字节更小，指令所需多；基于寄存器的字节更长，缓存命中小
RISC精简指令集操作更原子，CISC复杂指令集操作更大，二者都是栈与寄存器运行结构。
android内部C++代码大量使用智能指针管理对象声明周期，防止内存释放问题。开发使用java自动回收
每个进程都有dalvik实例，每个应用进程由Zygote fork出，Zygote进程是由init进程启动，在系统启动时加载所需。
这些被fork出来的Android应用程序进程，一方面是复制了Zygote进程中的虚拟机实例，另一方面是与Zygote进程共享了同一套Java核心库。这样不仅Android应用程序进程的创建过程很快，而且由于所有的Android应用程序进程都共享同一套Java核心库而节省了内存空间。
运用gcc的交叉编译形成的多平台。HAL屏蔽硬件细节时也编译了多个平台的，因此可选择生成多平台系统。
有几张好的表：https://www.jianshu.com/p/ad87f687f2fa
以上先开发出来，再看源码分析+文章。记录流程与图
看情况阅读….工作量大的暂时不用的跳过，以使用先为主。