上篇介绍了应用程序从源码到安装包的整个过程，考虑到篇幅过长，遂将原理内容分成两部分来介绍。接下来，在本篇中，主要介绍Android平台应用程序的运行原理。
在阅读了SDK文档中“Application Fundamentals”一篇的内容后，根据自己的理解绘制了下面的示意图：
每个应用程序安装后，系统便会为其分配一个独立的存储空间，所谓的“Security Sandbox”，用于存放字节码文件、资源文件及配置文件等，同时，系统会为每一个应用程序分配唯一的ID，用以标识该应用程序的相关文件和资源，系统通过设置权限从而实现一个应用程序在一般情况下只能访问该应用程序的文件和资源。当应用程序或者它的某个组件需要运行时，系统便为其创建一个Linux进程，每个进程中实例化一个Dalvik虚拟机用以执行程序的字节码。程序运行中根据给自己设定的权限来访问相应的资源。这样的设计保证了应用程序间的独立性和安全性，但是，应用程序常常要访问其他应用程序的数据或者访问系统资源，为此，Android平台提供了两种方式来实现这一目的：
（1）可以安排两个应用程序共享一个ID，从而可以彼此访问对方的文件；还可以安排两个应用程序在一个进程中运行，并共享一个虚拟机
（2）应用程序在安装时，可以通过使用者来设置权限，根据设置的权限应用程序可以发起访问系统资源和数据的请求。
---------------------------------------------------------------------------------------------------------------------------------------------------
了解应用程序运行原理的目的是为了构建应用程序，因此了解上述内容是远远不够的，如果把上述内容理解成物理结构，那么下面所讲的便是以构成应用程序的基本组件为主的逻辑结构。
Android应用程序主要由四种不同类型的组件组成，分别是Activity（活动）、Service（服务）、Content Provider（内容提供者）和Broadcast Receiver（广播接收者）：
◆Activity是一个显示在设备屏幕上的用户界面组件，有点儿类似视图（View）。一个应用程序可以包含多个Activity来呈现其不同的功能界面。在某一个程序允许的前提下，另一个程序可以启动该程序中的一个Activity来完成相应的功能。
◆Service是一个在后台运行的，没有用户界面，用以执行运行周期较长的操作或者执行远程进程的任务的组件。Activity可以启动一个Service并与其绑定用以实现二者之间的交互。
◆Content Provider是一个用于数据共享的组件。无论应用程序是以何种数据持久化形式保存的数据，通过Content Provider组件，其他应用程序可以访问或修改该应用程序的数据。
◆Broadcast Receiver是一个相应系统范围内的广播消息的组件。广播以Intent对象的形式发送，Broadcast Receiver接收后根据其内容作出相应操作。
Android系统这样设计的目的就是凸显组件的复用性，当一个程序需要使用另一个程序的组件时，首先需要向系统发送一个Intent来表明你的意图，系统根据权限设定，在允许的条件下，将组件所在的应用程序的进程启动，组件对应的类被实例化，组件执行完需要的功能后，将结果返回到调用该组件的应用程序，所以，Android应用程序与其他系统的应用程序不同，即没有单一的入口（例如Main函数）。对于组件激活的方式，不同的组件有不同的方式。其中，Activity、Service和Broadcast Receiver是被所谓“Intent”的异步消息激活的，Intent将独立的组件进行绑定；Content Provider是被来自Content Resolver的请求激活的。
根据上述内容，结合自己的理解，将Android应用程序创建和运行的过程用下图描绘：
上述内容主要是对原理的宏观描述，可能看着有点儿晕，后续的博文会结合具体的实例程序来详细介绍。同时，这些毕竟是个人理解的结果，可能会有不少内容描述不准确，希望各位经验丰富者积极指正，谢谢！