android独立进程

1. android 推送服务为什么要独立进程

“进程”？你应该是指在android中的“线程”吧，主线程是UI线程，不能阻塞。所以不建议放到主线程。既然不是主线程，那就要另启独立线程咯。如果不是，请勿喷～

2. android中线程,进程都是什么意思（通俗易懂的）

android中的进程就是一个个独立的APP应用。线程可以理解为进程中的时间片断：从代码执行的角度来看，主线程就是APP从开始一句一句代码从上往下执行，而子线程的执行时间片断与主线程的执行时间片断是分开的，执行时间不会影响到主线程的执行时间。

3. Android中的线程与进程之间的关系简单解释

一、Android中的进程
当一个程序第一次启动的时候，Android会启动一个LINUX进程和一个主线程。默认的情况下，所有该程序的组件都将在该进程和线程中运行。 同时，Android会为每个应用程序分配一个单独的LINUX用户。Android会尽量保留一个正在运行进程，只在内存资源出现不足时，Android会尝试停止一些进程从而释放足够的资源给其他新的进程使用， 也能保证用户正在访问的当前进程有足够的资源去及时地响应用户的事件。
我们可以将一些组件运行在其他进程中，并且可以为任意的进程添加线程。组件运行在哪个进程中是在manifest文件里设置的，其中<Activity>，<Service>，<receiver>和<provider>都有一个process属性来指定该组件运行在哪个进程之中。我们可以设置这个属性，使得每个组件运行在它们自己的进程中，或是几个组件共同享用一个进程，或是不共同享用。<application>元素也有一个process属性，用来指定所有的组件的默认属性。
Android中的所有组件都在指定的进程中的主线程中实例化的，对组件的系统调用也是由主线程发出的。每个实例不会建立新的线程。对系统调用进行响应的方法——例如负责执行用户动作的View.onKeyDown()和组件的生命周期函数——都是运行在这个主线程中的。这意味着当系统调用这个组件时，这个组件不能长时间的阻塞主线程。例如进行网络操作时或是更新UI时，如果运行时间较长，就不能直接在主线程中运行，因为这样会阻塞这个进程中其他的组件，我们可以将这样的组件分配到新建的线程中或是其他的线程中运行。
二、Android中的线程
线程在代码是使用标准的java Thread对象来建立，那么在Android系统中提供了一系列方便的类来管理线程——Looper用来在一个线程中执行消息循环，Handler用来处理消息，HandlerThread创建带有消息循环的线程。
三、进程与线程的关系
它们之间的区别：

1、线程是进程的一部分，所以线程有的时候被称为是轻权进程或者轻量级进程。
2、一个没有线程的进程是可以被看作单线程的，如果一个进程内拥有多个进程，进程的执行过程不是一条线（线程）的，而是多条线（线程）共同完成的。
3、系统在运行的时候会为每个进程分配不同的内存区域，但是不会为线程分配内存（线程所使用的资源是它所属的进程的资源），线程组只能共享资源。那就是说，出了CPU之外（线程在运行的时候要占用CPU资源），计算机内部的软硬件资源的分配与线程无关，线程只能共享它所属进程的资源。
4、与进程的控制表PCB相似，线程也有自己的控制表TCB，但是TCB中所保存的线程状态比PCB表中少多了。
5、进程是系统所有资源分配时候的一个基本单位，拥有一个完整的虚拟空间地址，并不依赖线程而独立存在。
它们之间的联系：
简单的说就是：一个程序包含进程，进程又包含线程，线程是进程的一个组成部分，进程是操作系统分配资源的基本单位，线程是不会分配资源的，一个进程可以包含多个线程，然后这些线程共享进程的资源。
分开来说就是：
线程是进程的一个实体，是CPU 调度和分配的基本单位，其本身不拥有系统资源，只含有程序计数器、寄存器和栈等一些运行时必不可少的基本资源。同属一个进程的线程共享进程中的全部资源。
进程是系统资源分配时的一个基本单位，拥有一个完整的虚拟空间地址。
系统在运行的时候会为每个进程分配不同的内存区域。
线程组只能共享资源，即除了CPU外，计算机内部的软硬件资源的分配与线程无关，线程只能共享它所属进程的资源。

4. android broadreceiver 运行在哪个进程

广播接收器是运行在UI线程。

下面介绍来自于android学习手册，android学习手册包含9个章节，108个例子，源码文档随便看，例子都是可交互，可运行，源码采用android studio目录结构，高亮显示代码，文档都采用文档结构图显示，可以快速定位。360手机助手中下载,图标上有贝壳

1.Android广播机制概述

Android广播分为两个方面：广播发送者和广播接收者，通常情况下，BroadcastReceiver指的就是广播接收者（广播接收器）。广播作为Android组件间的通信方式，可以使用的场景如下：
1.同一app内部的同一组件内的消息通信（单个或多个线程之间）；

2.同一app内部的不同组件之间的消息通信（单个进程）；

3.同一app具有多个进程的不同组件之间的消息通信；

4.不同app之间的组件之间消息通信；

5.Android系统在特定情况下与App之间的消息通信。

从实现原理看上，Android中的广播使用了观察者模式，基于消息的发布/订阅事件模型。因此，从实现的角度来看，Android中的广播将广播的发送者和接受者极大程度上解耦，使得系统能够方便集成，更易扩展。具体实现流程要点粗略概括如下：

1.广播接收者BroadcastReceiver通过Binder机制向AMS(Activity Manager Service)进行注册；

2.广播发送者通过binder机制向AMS发送广播；

3.AMS查找符合相应条件（IntentFilter/Permission等）的BroadcastReceiver，将广播发送到BroadcastReceiver（一般情况下是Activity）相应的消息循环队列中；

4.消息循环执行拿到此广播，回调BroadcastReceiver中的onReceive()方法。

对于不同的广播类型，以及不同的BroadcastReceiver注册方式，具体实现上会有不同。但总体流程大致如上。

由此看来，广播发送者和广播接收者分别属于观察者模式中的消息发布和订阅两端，AMS属于中间的处理中心。广播发送者和广播接收者的执行是异步的，发出去的广播不会关心有无接收者接收，也不确定接收者到底是何时才能接收到。显然，整体流程与EventBus非常类似。

在上文说列举的广播机制具体可以使用的场景中，现分析实际应用中的适用性：

第一种情形：同一app内部的同一组件内的消息通信（单个或多个线程之间），实际应用中肯定是不会用到广播机制的（虽然可以用），无论是使用扩展变量作用域、基于接口的回调还是Handler-post/Handler-Message等方式，都可以直接处理此类问题，若适用广播机制，显然有些“杀鸡牛刀”的感觉，会显太“重”；

第二种情形：同一app内部的不同组件之间的消息通信（单个进程），对于此类需求，在有些教复杂的情况下单纯的依靠基于接口的回调等方式不好处理，此时可以直接使用EventBus等，相对而言，EventBus由于是针对统一进程，用于处理此类需求非常适合，且轻松解耦。可以参见文件《Android各组件/控件间通信利器之EventBus》。

第三、四、五情形：由于涉及不同进程间的消息通信，此时根据实际业务使用广播机制会显得非常适宜。下面主要针对Android广播中的具体知识点进行总结。

2.BroadcastReceiver

自定义BroadcastReceiver

自定义广播接收器需要继承基类BroadcastReceivre，并实现抽象方法onReceive(context, intent)方法。广播接收器接收到相应广播后，会自动回到onReceive(..)方法。默认情况下，广播接收器也是运行在UI线程，因此，onReceive方法中不能执行太耗时的操作。否则将因此ANR。一般情况下，根据实际业务需求，onReceive方法中都会涉及到与其他组件之间的交互，如发送Notification、启动service等。
下面代码片段是一个简单的广播接收器的自定义：

1 public class MyBroadcastReceiver extends BroadcastReceiver {
2 public static final String TAG = "MyBroadcastReceiver";
3 public static int m = 1;
4
5 @Override
6 public void onReceive(Context context, Intent intent) {
7 Log.w(TAG, "intent:" + intent);
8 String name = intent.getStringExtra("name");
9 Log.w(TAG, "name:" + name + " m=" + m);
10 m++;
11
12 Bundle bundle = intent.getExtras();
13
14 }
15 }

BroadcastReceiver注册类型

BroadcastReceiver总体上可以分为两种注册类型：静态注册和动态注册。

1).静态注册：
直接在AndroidManifest.xml文件中进行注册。规则如下：

<receiver android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permission="string"
android:process="string" >
. . .
</receiver>

其中，需要注意的属性
android:exported ——此broadcastReceiver能否接收其他App的发出的广播，这个属性默认值有点意思，其默认值是由receiver中有无intent-filter决定的，如果有intent-filter，默认值为true，否则为false。（同样的，activity/service中的此属性默认值一样遵循此规则）同时，需要注意的是，这个值的设定是以application或者application user id为界的，而非进程为界（一个应用中可能含有多个进程）；
android:name —— 此broadcastReceiver类名；
android:permission ——如果设置，具有相应权限的广播发送方发送的广播才能被此broadcastReceiver所接收；
android:process ——broadcastReceiver运行所处的进程。默认为app的进程。可以指定独立的进程（Android四大基本组件都可以通过此属性指定自己的独立进程）

常见的注册形式有：

<receiver android:name=".MyBroadcastReceiver" >
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>

其中，intent-filter由于指定此广播接收器将用于接收特定的广播类型。本示例中给出的是用于接收网络状态改变或开启启动时系统自身所发出的广播。当此App首次启动时，系统会自动实例化MyBroadcastReceiver，并注册到系统中。

之前常说：静态注册的广播接收器即使app已经退出，主要有相应的广播发出，依然可以接收到，但此种描述自Android 3.1开始有可能不再成立，具体分析详见本文后面部分。

2).动态注册：
动态注册时，无须在AndroidManifest中注册<receiver/>组件。直接在代码中通过调用Context的registerReceiver函数，可以在程序中动态注册BroadcastReceiver。registerReceiver的定义形式如下：

1 registerReceiver(BroadcastReceiver receiver, IntentFilter filter)
2 registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheler)

典型的写法示例如下：

1 public class MainActivity extends Activity {
2 public static final String BROADCAST_ACTION = "com.example.corn";
3 private BroadcastReceiver mBroadcastReceiver;
4
5 @Override
6 protected void onCreate(Bundle savedInstanceState) {
7 super.onCreate(savedInstanceState);
8 setContentView(R.layout.activity_main);
9
10 mBroadcastReceiver = new MyBroadcastReceiver();
11 IntentFilter intentFilter = new IntentFilter();
12 intentFilter.addAction(BROADCAST_ACTION);
13 registerReceiver(mBroadcastReceiver, intentFilter);
14 }
15
16 @Override
17 protected void onDestroy() {
18 super.onDestroy();
19 unregisterReceiver(mBroadcastReceiver);
20 }
21
22 }

注：Android中所有与观察者模式有关的设计中，一旦涉及到register，必定在相应的时机需要unregister。因此，上例在onDestroy()回到中需要unregisterReceiver(mBroadcastReceiver)。

当此Activity实例化时，会动态将MyBroadcastReceiver注册到系统中。当此Activity销毁时，动态注册的MyBroadcastReceiver将不再接收到相应的广播。

3.广播发送及广播类型

经常说”发送广播“和”接收“，表面上看广播作为Android广播机制中的实体，实际上这一实体本身是并不是以所谓的”广播“对象存在的，而是以”意图“（Intent）去表示。定义广播的定义过程，实际就是相应广播”意图“的定义过程，然后通过广播发送者将此”意图“发送出去。被相应的BroadcastReceiver接收后将会回调onReceive()函数。

下段代码片段显示的是一个普通广播的定义过程，并发送出去。其中setAction(..)对应于BroadcastReceiver中的intentFilter中的action。

1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.putExtra("name", "qqyumidi");
4 sendBroadcast(intent);

根据广播的发送方式，可以将其分为以下几种类型：
1.Normal Broadcast：普通广播

2.System Broadcast: 系统广播

3.Ordered broadcast：有序广播

4.Sticky Broadcast：粘性广播(在 android 5.0/api 21中deprecated,不再推荐使用，相应的还有粘性有序广播，同样已经deprecated)

5.Local Broadcast：App应用内广播

下面分别总结下各种类型的发送方式及其特点。

1).Normal Broadcast：普通广播

此处将普通广播界定为：开发者自己定义的intent，以context.sendBroadcast_"AsUser"(intent, ...)形式。具体可以使用的方法有：
sendBroadcast(intent)/sendBroadcast(intent, receiverPermission)/sendBroadcastAsUser(intent, userHandler)/sendBroadcastAsUser(intent, userHandler,receiverPermission)。
普通广播会被注册了的相应的感兴趣（intent-filter匹配）接收，且顺序是无序的。如果发送广播时有相应的权限要求，BroadCastReceiver如果想要接收此广播，也需要有相应的权限。

2).System Broadcast: 系统广播

Android系统中内置了多个系统广播，只要涉及到手机的基本操作，基本上都会发出相应的系统广播。如：开启启动，网络状态改变，拍照，屏幕关闭与开启，点亮不足等等。每个系统广播都具有特定的intent-filter，其中主要包括具体的action，系统广播发出后，将被相应的BroadcastReceiver接收。系统广播在系统内部当特定事件发生时，有系统自动发出。

3)Ordered broadcast：有序广播

有序广播的有序广播中的“有序”是针对广播接收者而言的，指的是发送出去的广播被BroadcastReceiver按照先后循序接收。有序广播的定义过程与普通广播无异，只是其的主要发送方式变为：sendOrderedBroadcast(intent, receiverPermission, ...)。

对于有序广播，其主要特点总结如下：

1>多个具当前已经注册且有效的BroadcastReceiver接收有序广播时，是按照先后顺序接收的，先后顺序判定标准遵循为：将当前系统中所有有效的动态注册和静态注册的BroadcastReceiver按照priority属性值从大到小排序，对于具有相同的priority的动态广播和静态广播，动态广播会排在前面。

2>先接收的BroadcastReceiver可以对此有序广播进行截断，使后面的BroadcastReceiver不再接收到此广播，也可以对广播进行修改，使后面的BroadcastReceiver接收到广播后解析得到错误的参数值。当然，一般情况下，不建议对有序广播进行此类操作，尤其是针对系统中的有序广播。

4)Sticky Broadcast：粘性广播(在 android 5.0/api 21中deprecated,不再推荐使用，相应的还有粘性有序广播，同样已经deprecated)。

既然已经deprecated，此处不再多做总结。

5)Local Broadcast：App应用内广播（此处的App应用以App应用进程为界）

由前文阐述可知，Android中的广播可以跨进程甚至跨App直接通信，且注册是exported对于有intent-filter的情况下默认值是true，由此将可能出现安全隐患如下：

1.其他App可能会针对性的发出与当前App intent-filter相匹配的广播，由此导致当前App不断接收到广播并处理；

2.其他App可以注册与当前App一致的intent-filter用于接收广播，获取广播具体信息。

无论哪种情形，这些安全隐患都确实是存在的。由此，最常见的增加安全性的方案是：

1.对于同一App内部发送和接收广播，将exported属性人为设置成false，使得非本App内部发出的此广播不被接收；

2.在广播发送和接收时，都增加上相应的permission，用于权限验证；

3.发送广播时，指定特定广播接收器所在的包名，具体是通过intent.setPackage(packageName)指定在，这样此广播将只会发送到此包中的App内与之相匹配的有效广播接收器中。

App应用内广播可以理解成一种局部广播的形式，广播的发送者和接收者都同属于一个App。实际的业务需求中，App应用内广播确实可能需要用到。同时，之所以使用应用内广播时，而不是使用全局广播的形式，更多的考虑到的是Android广播机制中的安全性问题。

相比于全局广播，App应用内广播优势体现在：

1.安全性更高；

2.更加高效。

为此，Android v4兼容包中给出了封装好的LocalBroadcastManager类，用于统一处理App应用内的广播问题，使用方式上与通常的全局广播几乎相同，只是注册/取消注册广播接收器和发送广播时将主调context变成了LocalBroadcastManager的单一实例。

代码片段如下：

1 //registerReceiver(mBroadcastReceiver, intentFilter);
2 //注册应用内广播接收器
3 localBroadcastManager = LocalBroadcastManager.getInstance(this);
4 localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);
5
6 //unregisterReceiver(mBroadcastReceiver);
7 //取消注册应用内广播接收器
8 localBroadcastManager.unregisterReceiver(mBroadcastReceiver);
9
10 Intent intent = new Intent();
11 intent.setAction(BROADCAST_ACTION);
12 intent.putExtra("name", "qqyumidi");
13 //sendBroadcast(intent);
14 //发送应用内广播
15 localBroadcastManager.sendBroadcast(intent);

4.不同注册方式的广播接收器回调onReceive(context, intent)中的context具体类型

1).对于静态注册的ContextReceiver，回调onReceive(context, intent)中的context具体指的是ReceiverRestrictedContext；

2).对于全局广播的动态注册的ContextReceiver，回调onReceive(context, intent)中的context具体指的是Activity Context；

3).对于通过LocalBroadcastManager动态注册的ContextReceiver，回调onReceive(context, intent)中的context具体指的是Application Context。

注：对于LocalBroadcastManager方式发送的应用内广播，只能通过LocalBroadcastManager动态注册的ContextReceiver才有可能接收到（静态注册或其他方式动态注册的ContextReceiver是接收不到的）。

5.不同Android API版本中广播机制相关API重要变迁

1).Android5.0/API level 21开始粘滞广播和有序粘滞广播过期，以后不再建议使用；

2).”静态注册的广播接收器即使app已经退出，主要有相应的广播发出，依然可以接收到，但此种描述自Android 3.1开始有可能不再成立“

Android 3.1开始系统在Intent与广播相关的flag增加了参数，分别是FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES。

FLAG_INCLUDE_STOPPED_PACKAGES：包含已经停止的包（停止：即包所在的进程已经退出）

FLAG_EXCLUDE_STOPPED_PACKAGES：不包含已经停止的包

主要原因如下：

自Android3.1开始，系统本身则增加了对所有app当前是否处于运行状态的跟踪。在发送广播时，不管是什么广播类型，系统默认直接增加了值为FLAG_EXCLUDE_STOPPED_PACKAGES的flag，导致即使是静态注册的广播接收器，对于其所在进程已经退出的app，同样无法接收到广播。

详情参加Android官方文档：http://developer.android.com/about/versions/android-3.1.html#launchcontrols

由此，对于系统广播，由于是系统内部直接发出，无法更改此intent flag值，因此，3.1开始对于静态注册的接收系统广播的BroadcastReceiver，如果App进程已经退出，将不能接收到广播。

但是对于自定义的广播，可以通过复写此flag为FLAG_INCLUDE_STOPPED_PACKAGES，使得静态注册的BroadcastReceiver，即使所在App进程已经退出，也能能接收到广播，并会启动应用进程，但此时的BroadcastReceiver是重新新建的。

1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES);
4 intent.putExtra("name", "qqyumidi");
5 sendBroadcast(intent);

注1：对于动态注册类型的BroadcastReceiver，由于此注册和取消注册实在其他组件（如Activity）中进行，因此，不受此改变影响。

注2：在3.1以前，相信不少app可能通过静态注册方式监听各种系统广播，以此进行一些业务上的处理（如即时app已经退出，仍然能接收到，可以启动service等..）,3.1后，静态注册接受广播方式的改变，将直接导致此类方案不再可行。于是，通过将Service与App本身设置成不同的进程已经成为实现此类需求的可行替代方案。

5. android 关屏 如何保持程序继续运行

主要看第二个方法：（A,Bservice在两个进程中，所以要用到AIDL来跨进程）

在原本只有一个serviceA的情况下再声明一个serviceB，并为之新开启一个进程；

serviceA被杀死的时候，serviceB立刻重启serviceA；（在serviceB中重写ServiceConnection中的Connect和Disconnect方法，在disconnect中start和bindserviceA）；

如下：在主服务StepService中的Disconnect方法中start和bindservice GuardService；

serviceB被杀死的时候，serviceA立刻重启serviceB；（在serviceA中重写ServiceConnection中的Connect和Disconnect方法，在disconnect中start和bindserviceB）

两个进程互相守护

6. android服务和进程的区别

他们之间的区别：Service很大程度上充当了应用程序后台线程管理器的角色。（如果Activity中新开启一个线程，当该Acitivyt关闭后，该线程依然在工作，但是与开启它的Activity失去联系。也就是说此时的这个线程处于失去管理的状态。但是使用Service，则可以对后台运行的线程有效地管理。）
一个服务不是一个单独的进程。服务对象本身并不意味着它是在自己的进程中运行，除非另有规定，否则它与运行程序是同在一个进程中。
一个服务不是一个单独的线程。Service和其他组件一样，默认情况下，Service中的所有代码都是运行在主线程中。
在android中，为什么不使用后台线程而使用Service？ 有3大要点：
1、Service可以放在独立的进程中，所以更安全；

2、使用Service可以依赖现有的binder机制，不需要在应用层面上处理线程同步的繁杂工作；

3、系统可以重新启动异常死去的Service。

说明：进程是由若干线程组成。（线程是进程中的一部分，进程包含多个线程在运行。）

7. Android进程与线程区别

所以下来特地去查了以下资料，先说说线程：
（1）在Android APP中，只允许有一个主线程，进行UI的渲染等等，但是不能进行耗时操作（网络交互等等），否则会造成ANR，就是线程阻塞卡死，未响应。
（2）除了主线程之外，耗时操作都应该规范到子线程中,线程之间会有相应的通信方式，但相互独立。
（3）然后看了一下所查资料：
线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位。线程比进程更小，基本上不拥有系统资源，故对它的调度所用资源小，能更高效的提高系统内多个程序间并发执行的。 嗯，从大的说就是这样。
在平时的Android开发过程中，基本上都会用到线程handler，thread等等，具体的实现方法我就不在这里写了。

进程：
根据所查资料：是一个具有独立功能的程序关于某个数据集合的一次运行活动。进程是系统进行资源分配和调度的一个独立单位。可以申请和拥有系统资源，是一个动态的概念，是一个活动的实体，是一个“执行中的程序”。不只是程序的代码，还包括当前的活动。
这应该是一个比较大的概念，存在于一个系统中，与线程的区别是：

1、子进程和父进程有不同的代码和数据空间，而多个线程则共享数据空间，每个线程有自己的执行堆栈和程序计数器为其执行上下文。
2、进程间相互独立，同一进程的各线程间共享。某进程内的线程在其它进程不可见。

3、进程间通信IPC，线程间可以直接读写进程数据段（如全局变量）来进行通信——需要进程同步和互斥手段的辅助，以保证数据的一致性。

4、线程上下文切换比进程上下文切换要快得多。

8. 在android里Service不是一个单独的进程也不是一个单独的线程,那么为什么用户可以在

根据API的描述：
service是运行在主线程上的，而不是运行在另一个线程中，如果你想在service中处理很占时间的操作，你必须在service中开线程，这样可以降低activity没有响应的风险。

9. android 应用进程是怎么创建的

程序关闭后确实也会有数据就在内存里，如果不使用强行停止就不会清理，你不信可以打开浏览器然后打开一个网站，然后使用任务管理器关掉(不要用设置里的强行停止，会清空数据的)，再打开浏览器，会发现你打开的网页还在 安卓启动进程时需要先优化和解释应用程序的源码，然后复制一个虚拟机，将虚拟机内容换成应用程序的 最开始的虚拟机是安卓开机时创建的，所有的进程都由这个母进程复制过来的。所以你知道为什么应用程序开机启动可以加速了，开机时就把这个进程的虚拟机准备好 并且解释程序代码的过程实际上把程序缓存了一下 内存比存储快，启动就快。可以理解为类似于windows7上的superfetch当然原理完全不同。也可以给应用程序做odex，就是一个事先优化和解释好的文件 你看你手机自带程序都有odex，就是为了起到加速作用。 安卓的apk与windows完全不同，它实际上是个zip，而且所有的资源都在这个包里面，不像windows还会有什么dll在外面。所谓应用程序安装，实际上是把apk复制到了手机内存里(路径 /data/app)，然后在data/data里为应用程序创建独立的存储空间(实际上是个ext文件系统的文件夹)，然而运行的过程就像java一样，还要打开压缩包什么的。

10. Android应用程序启动流程总结

AMS主要功能：
AMS是Android中最核心的服务，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作。还负责启动或杀死应用程序的进程。

WMS主要功能：
为所有窗口分配Surface。
管理Surface的显示顺序、尺寸、位置。
管理窗口动画。
输入系统相关：WMS是派发系统按键和触摸消息的最佳人选，当接收到一个触摸事件，它需要寻找一个最合适的窗口来处理消息。

PWS主要功能：
PMS 用来管理跟踪所有应用APK，包括安装，卸载，解析，控制权限等。

SystemServer也是一个进程，包括AMS、PMS、WMS等等。

zygote意为“受精卵“。Android是基于Linux系统的，而在Linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote进程也不例外。

App进程是用户点击桌面icon时，通过Launcher进程请求SystemServer，再调用Zygote孵化的。

①点击启动一个App，Launcher进程采用Binder IPC向ActivityManagerService发起startActivity请求；

②ActivityManagerService接收到请求后，向zygote进程发送创建进程的请求；

③Zygote进程fork出新的子进程，即App进程；

④App进程通过Binder IPC向sytem_server进程发起绑定Application请求；

⑤system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheleLaunchActivity请求；

⑥App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；

⑦主线程在收到Message后，通过发射机制创建目标Activity，并回调Activity.onCreate()等方法。

⑧到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。

备注：
Launcher，PMS，Zygote，App进程是三个独立的进程，相互通信就需要使用进程间通信机制。与Zygote通信是使用的socket通信，Launcher，PMS，App进程间使用的是Binder机制。