Android 加载模型

为了更好的理解Activity的加载模式，首先先了解一下Android的进程，线程模型 ，其中对“Android的单线程模型”的描述，我们需要明白Activity的一些注意事项。

android进程模型：

在安装Android应用程序的时候，Android会为每个程序分配一个Linux用户ID，并设置相应的权限，这样其它应用程序就不能访问此应用程序所拥有的数据和资源了。

在 Linux 中，一个用户ID 识别一个给定用户；在 Android 上，一个用户ID 识别一个应用程序。

应用程序在安装时被分配用户 ID，应用程序在设备上的存续期间内，用户ID 保持不变。

 

默认情况下，每个apk运行在它自己的Linux进程中。当需要执行应用程序中的代码时，Android会启动一个jvm，即一个新的进程来执行，因此不同的apk运行在相互隔离的环境中。

下图显示了：两个 Android 应用程序，各自在其自己的基本沙箱或进程上。他们是不同的Linux user ID。

开发者也可以给两个应用程序分配相同的linux用户id，这样他们就能访问对方所拥有的资源。

为了保留系统资源，拥有相同用户id的应用程序可以运行在同一个进程中，共享同一个jvm。

如下图，显示了两个 Android 应用程序，运行在同一进程上。

不同的应用程序可以运行在相同的进程中。要实现这个功能，首先必须使用相同的私钥签署这些应用程序，然后必须使用 manifest 文件给它们分配相同的 Linux 用户 ID，这通过用相同的值/名定义 manifest 属性 android:sharedUserId 来做到。

Android进程知识的补充：

下图是标准的Android 架构图，

其中我们可以看到在“Android本地库 & Java运行环境层”中，Android 运行时中，

Dalvik是Android中的java虚拟机，可支持同时运行多个虚拟机实例；每个Android应用程序都在自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例； 
所有java类经过java编译器编译，然后通过SDK中的dx工具转成.dex格式交由虚拟机执行。

Android系统进程

init进程（1号进程），父进程为0号进程，执行根目录底下的init可执行程序，是用户空间进程 
——-> /system/bin/sh 
——-> /system/bin/mediaserver 
——-> zygote 
—————–> system_server 
—————–>com.android.phone 
—————–>android.process.acore(Home) 
… …

kthreadd进程（2号进程），父进程为0号进程，是内核进程，其他内核进程都是直接或者间接以它为父进程

  

Android的单线程模型

当一个程序第一次启动时，Android会同时启动一个对应的主线程（Main Thread），主线程主要负责处理与UI相关的事件，如：用户的按键事件，用户接触屏幕的事件以及屏幕绘图事件，并把相关的事件分发到对应的组件进行处理。所以主线程通常又被叫做UI线程。

在开发Android 应用时必须遵守单线程模型的原则： Android UI操作并不是线程安全的并且这些操作必须在UI线程中执行。

如果在非UI线程中直接操作UI线程，会抛出android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views，这与普通的java程序不同。

由于UI线程负责事件的监听和绘图，因此，必须保证UI线程能够随时响应用户的需求，UI线程里的操作应该向中断事件那样短小，费时的操作（如网络连接）需要另开线程，否则，如果UI线程超过5s没有响应用户请求，会弹出对话框提醒用户终止应用程序。

如果在新开的线程中需要对UI进行设定，就可能违反单线程模型，因此android采用一种复杂的Message Queue机制保证线程间通信。

 

Message Queue：

Message Queue是一个消息队列，用来存放通过Handler发布的消息。Android在第一次启动程序时会默认会为UI thread创建一个关联的消息队列，可以通过Looper.myQueue()得到当前线程的消息队列，用来管理程序的一些上层组件，activities，broadcast receivers 等等。你可以在自己的子线程中创建Handler与UI thread通讯。 

通过Handler你可以发布或者处理一个消息或者是一个Runnable的实例。每个Handler都会与唯一的一个线程以及该线程的消息队列管理。

Looper扮演着一个Handler和消息队列之间通讯桥梁的角色。程序组件首先通过Handler把消息传递给Looper，Looper把消息放入队列。Looper也把消息队列里的消息广播给所有的Handler，Handler接受到消息后调用handleMessage进行处理。

实例如下：

public void onCreate(Bundle savedInstanceState) {  
   super.onCreate(savedInstanceState);  
   setContentView(R.layout.main);  
   editText = (EditText) findViewById(R.id.weather_city_edit);  
   Button button = (Button) findViewById(R.id.goQuery);  
   button.setOnClickListener(this);  

   Looper looper = Looper.myLooper();  //得到当前线程的Looper实例，由于当前线程是UI线程也可以通过Looper.getMainLooper()得到  
    messageHandler = new MessageHandler(looper);  //此处甚至可以不需要设置Looper，因为 Handler默认就使用当前线程的Looper  
} 

public void onClick(View v) {  
   new Thread() {  
      public void run() {  
          Message message = Message.obtain();  
          message.obj = "abc";  
          messageHandler.sendMessage(message);  //发送消息 
       }  
   }.start();  
} 

Handler messageHandler = new Handler {  
   public MessageHandler(Looper looper) {  
      super(looper);  
  } 
   public void handleMessage(Message msg) {  
      setTitle((String) msg.obj);  
   } 
}

对于这个实例，当这个activity执行玩oncreate,onstart,onresume后，就监听UI的各种事件和消息。

当我们点击一个按钮后，启动一个线程，线程执行结束后，通过handler发送一个消息，由于这个handler属于UI线程，因此这个消息也发送给UI线程，然后UI线程又把这个消息给handler处理，而这个handler是UI线程创造的，他可以访问UI组件，因此，就更新了页面。

由于通过handler需要自己管理线程类，如果业务稍微复杂，代码看起来就比较混乱，因此android提供了AsyncTask类来解决此问题。

 

AsyncTask:

首先继承一下此类，实现以下若干方法，

onPreExecute(), 该方法将在执行实际的后台操作前被UI thread调用。可以在该方法中做一些准备工作，如在界面上显示一个进度条。 

doInBackground(Params...), 将在onPreExecute 方法执行后马上执行，该方法运行在后台线程中。这里将主要负责执行那些很耗时的后台计算工作。

可以调用publishProgress方法来更新实时的任务进度。该方法是抽象方法，子类必须实现。 

onProgressUpdate(Progress...),在publishProgress方法被调用后，UI thread将调用这个方法从而在界面上展示任务的进展情况，例如通过一个进度条进行展示。 

onPostExecute(Result), 在doInBackground 执行完成后，onPostExecute 方法将被UI thread调用，后台的计算结果将通过该方法传递到UI thread.

使用时需要遵循以下规则：

1)Task的实例必须在UI thread中创建 

2)execute方法必须在UI thread中调用 

3)不要手动的调用这些方法，只调用execute即可

4)该task只能被执行一次，否则多次调用时将会出现异常

示例如下：

public void onCreate(Bundle savedInstanceState) {  
       super.onCreate(savedInstanceState);  
       setContentView(R.layout.main);  
       editText = (EditText) findViewById(R.id.weather_city_edit);  
       Button button = (Button) findViewById(R.id.goQuery);  
       button.setOnClickListener(this);  
}  

public void onClick(View v) {  
       new GetWeatherTask().execute(“aaa”);  
} 

class GetWeatherTask extends AsyncTask {  
    protected String doInBackground(String... params) {  
         return getWetherByCity(params[0]);  
    } 
    protected void onPostExecute(String result) {  
         setTitle(result);
    }  
}

接下来，需要了解什么是Android Application?

简单来说，一个apk文件就是一个Application。

任何一个Android Application基本上是由一些Activities组成，当用户与应用程序交互时其所包含的部分Activities具有紧密的逻辑关系，或者各自独立处理不同的响应。

这些Activities捆绑在一起成为了一个处理特定需求的Application, 并且以“.apk”作为后缀名存在于文件系统中。

Android平台默认下的应用程序 例如：Email、Calendar、Browser、Maps、Text Message、Contacts、Camera和Dialer等都是一个个独立的Apps。

 

安装 Application的过程也可以简单理解为将其所包裹的Activities导入到当前的系统中，如果系统中已经存在了相同的Activities， 那么将会自动将其关联，而不会重复安装相同的Activities，避免资源的浪费。

Application卸载的过程也会检查当前所关联的 Activities是否有被其它Application标签所关联，如果仅仅是提供当前的Application使用，那么将会彻底被移除，相反则不做 任何操作。

 

就像我们已经知道的，Application基本上是由四个模块组成：Activity、Service、Content Provider 和 Broadcast Receiver，其中Activity是实现应用的主体。

 

什么是 Activity Stack？

操作应用程序时，有时需要调用多个Activities来完成需求，例如：发送邮件程序，首先是进入邮件主界面，然后启动一个新的Activity用于填写新邮件内容，同时可以调出联系人列表用于插入收件人信息等等。在这个操作过程中 Android平台有一个专门用于管理Activities堆栈的机制，其可以方便的线性记录Activities实例，当完成某个操作时，可以通过导航功能返回之前的Activity（通过按操作台的“Back”按钮）。

每次启动新的Activity都将被添加到Activity Stack。用户可以方便的返回上一个Activity直到Home Screen，到达Home Screen后，将无法再继续查看堆栈记录（俗话说：到头了）。如果当前Task被中止(Interrupting the task)，返回到系统主界面后启动了其它操作，当希望返回到前一个Task继续执行时，只需要再次通过主界面的Application launcher或者快捷方式启动这个Task的Root Activity便可返回其中止时的状态继续执行。

相对于Views、Windows、Menus和Dialogs而言，Activity是唯一可被记录在History stack中的数据，所以当你所设计的应用程序需要用户由A界面进入到次一级界面B，当完成操作后需要再次返回A,那么必须考虑将A看作为 Activity，否则将无法从历史堆栈中返回。

 

什么是Task

当我们需要一个Activity可以启动另一个Activity，可能另外一个Activity是定义在不同应用程序中的Activity。

例如，假设你想在你的应用中让用户显示一些地方的街景。而这里已经有一个Activity可以做到这一点，因此，你的Activity所需要做的只是在Intent对象中添加必要的信息，并传递给startActivity()。地图浏览将会显示你的地图。当用户按下BACK键，你的Activity会再次出现在屏幕上。

对于用户来说，看起来好像是地图浏览与你的Activity一样，属于相同的应用程序，即便是它定义在其它的应用程序里，并运行在那个应用程序的进程里。

Android通过将这两个Activity保存在同一个Task里来体现这一用户体验。简单来说，一个Task就是用户体验上的一个“应用”。 
它将相关的Activity组合在一起，以stack的方式管理（就是前面提到的Activity Stack），这就是Task。

 

在Android平台上可以将task简单的理解为幽多个Activity共同协作完成某项应用，而不管Activity具体属于哪个Application，

通过下图可以更清晰的理解Application、task、Activity三者之间的关系：

 

Task 有啥用？

我们用过Android的手机就会知道有下面的场景：

假设我们首先在用IReader在看书，从选书到具体书的阅读界面，这是有好几个Activity。我们每一个点击的Activity都被放在阅读这个Task对应的Activity Stack中了，这可以放我们通过回退键返回每一个前面的Activity。

我们在阅读到一半时，想看看Sina微博，按Home键离开了IReader。

在Sina微博界面也是有多个Activity，我们一步到阅读界面。这时候我们每一个点击的Activity都被放在Sina微博这个Task对应的Activity Stack中了，这可以放我们通过回退键返回每一个前面的Activity。

我们这时候再回到IReader读书界面，原先的状态还是保留的。

显然每一个Task有自己的 Activity Stack。

Task就是这样为了方便人们使用手机而设置的，就像前面提到的场景Task可以跨Application。

 

下面这个图从另外一个角度描述了Application Task Activities的关系

 

Task通过Application launcher、Home screen的快捷方式或者 由 “Recent Tasks”（长时间按住Home键）最近使用过的Task记录中启动。

当从一个Activity中启动另外一个Activity时，Back键将作用于返回前一个Activity,与此同时 新开启的Activity将被添加到Activity Stack中。

四种加载模式：

standard ：系统的默认模式，一次跳转即会生成一个新的实例。假设有一个activity命名为Act1，执行语句：

      startActivity(new Intent(Act1.this, Act1.class));

后Act1将跳转到另外一个Act1，也就是现在的栈里面有 Act1 的两个实例。按返回键后你会发现仍然是在Act1（第一个）里面。

 

singleTop：singleTop 跟standard 模式比较类似。唯一的区别就是，当跳转的对象是位于栈顶的activity（应该可以理解为用户眼前所 看到的activity）时，程序将不会生成一个新的activity实例，而是直接跳到现存于栈顶的那个activity实例。拿上面的例子来说，当Act1 为 singleTop 模式时，执行跳转后栈里面依旧只有一个实例，如果现在按返回键程序将直接退出。这个貌似用得比较少。

 

3、singleTask： singleTask模式和后面的singleInstance模式都是只创建一个实例的。在这种模式下，无论跳转的对象是不是位于栈顶的activity，程序都不会生成一个新的实例（当然前提是栈里面已经有这个实例）。我觉得这种模式相当有用。。在以后的多activity开发中， 经常会因为跳转的关系导致同个页面生成多个实例，这个在用户体验上始终有点不好，而如果你将对应的activity声明为 singleTask 模式，这种问题将不复存在。不过前阵子好像又看过有人说一般不要将除开始页面的其他页面设置为 singleTask 模式。。原因暂时不明，哪位知道的可以请教下。

设置了"singleTask"启动模式的Activity的特点：

        1. 设置了"singleTask"启动模式的Activity，它在启动的时候，会先在系统中查找属性值affinity等于它的属性值taskAffinity的任务存在；如果存在这样的任务，它就会在这个任务中启动，否则就会在新任务中启动。因此，如果我们想要设置了"singleTask"启动模式的Activity在新的任务中启动，就要为它设置一个独立的taskAffinity属性值。

        2. 如果设置了"singleTask"启动模式的Activity不是在新的任务中启动时，它会在已有的任务中查看是否已经存在相应的Activity实例，如果存在，就会把位于这个Activity实例上面的Activity全部结束掉，即最终这个Activity实例会位于任务的堆栈顶端中。

singleInstance: 看网上的解释好像都比较复杂。刚开始也没怎么明白这种模式，只知道它用的也不多。后来仔细看了网上的解释，稍微有些懂了。就按我的理解解释下。设置为 singleInstance 模式的 activity 将独占一个task（感觉task可以理解为进程），独占一个task的activity与其说是activity，倒不如说是一个应用，这个应用与其他activity是独立的，它有自己的上下文activity。拿一个例子来说明吧：

现在有以下三个activity: Act1、Act2、Act3，其中Acti2 为 singleInstance 模式。它们之间的跳转关系为： Act1 -- Act2 -- Act3 ，现在在Act3中按下返回键，由于Act2位于一个独立的task中，它不属于Act3的上下文activity，所以此时将直接返回到Act1。这就是singleInstance模式，不知道解释清楚了没。。

其他资料：

standard：

Activity的默认加载方法，即使某个Activity在 Task栈中已经存在，另一个activity通过Intent跳转到该activity，同样会新创建一个实例压入栈中。例如：现在栈的情况为：A B C D，在D这个Activity中通过Intent跳转到D，那么现在的栈情况为： A B C D D 。此时如果栈顶的D通过Intent跳转到B，则栈情况为：A B C D D B。此时如果依次按返回键，D  D C B A将会依次弹出栈而显示在界面上。

singleTop：

如果某个Activity的Launch mode设置成singleTop，那么当该Activity位于栈顶的时候，再通过Intent跳转到本身这个Activity，则将不会创建一个新的实例压入栈中。例如：现在栈的情况为：A B C D。D的Launch mode设置成了singleTop，那么在D中启动Intent跳转到D，那么将不会新创建一个D的实例压入栈中，此时栈的情况依然为：A B C D。但是如果此时B的模式也是singleTop，D跳转到B，那么则会新建一个B的实例压入栈中，因为此时B不是位于栈顶，此时栈的情况就变成了：A B C D B。

singleTask：

如果某个Activity是singleTask模式，那么Task栈中将会只有一个该Activity的实例。例如：现在栈的情况为：A B C D。B的Launch mode为singleTask，此时D通过Intent跳转到B，则栈的情况变成了：A B。而C和D被弹出销毁了，也就是说位于B之上的实例都被销毁了。

singleInstance：

将Activity压入一个新建的任务栈中。例如：Task栈1的情况为：A B C。C通过Intent跳转到D，而D的Launch mode为singleInstance，则将会新建一个Task栈2。此时Task栈1的情况还是为：A B C。Task栈2的情况为：D。此时屏幕界面显示D的内容，如果这时D又通过Intent跳转到D，则Task栈2中也不会新建一个D的实例，所以两个栈的情况也不会变化。而如果D跳转到C，则栈1的情况变成了：A B C C，因为C的Launch mode为standard，此时如果再按返回键，则栈1变成：A B C。也就是说现在界面还显示C的内容，不是D。 
好了，现在有一个问题就是这时这种情况下如果用户点击了Home键，则再也回不到D的即时界面了。如果想解决这个问题，可以为D在Manifest.xml文件中的声明加上 
     
     

加上这段之后，也就是说该程序中有两个这种声明，另一个就是那个正常的根 activity，在打成apk包安装之后，在程序列表中能看到两个图标，但是如果都运行的话，在任务管理器中其实也只有一个。上面的情况点击D的那个图标就能回到它的即时界面（比如一个EditText，以前输入的内容，现在回到之后依然存在）。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Intent的常用Flag参数：

FLAG_ACTIVITY_CLEAR_TOP：例如现在的栈情况为：A B C D 。D此时通过intent跳转到B，如果这个intent添加FLAG_ACTIVITY_CLEAR_TOP 标记，则栈情况变为：A B。如果没有添加这个标记，则栈情况将会变成：A B C D B。也就是说，如果添加了FLAG_ACTIVITY_CLEAR_TOP 标记，并且目标Activity在栈中已经存在，则将会把位于该目标activity之上的activity从栈中弹出销毁。这跟上面把B的Launch mode设置成singleTask类似。

FLAG_ACTIVITY_NEW_TASK：例如现在栈1的情况是：A B C。C通过intent跳转到D，并且这个intent添加了FLAG_ACTIVITY_NEW_TASK 标记，如果D这个Activity在Manifest.xml中的声明中添加了Task affinity，并且和栈1的affinity不同，系统首先会查找有没有和D的Task affinity相同的task栈存在，如果有存在，将D压入那个栈，如果不存在则会新建一个D的affinity的栈将其压入。如果D的Task affinity默认没有设置，或者和栈1的affinity相同，则会把其压入栈1，变成：A B C D，这样就和不加FLAG_ACTIVITY_NEW_TASK 标记效果是一样的了。      注意如果试图从非activity的非正常途径启动一个activity，比如从一个service中启动一个activity，则intent比如要添加FLAG_ACTIVITY_NEW_TASK 标记。

FLAG_ACTIVITY_NO_HISTORY：例如现在栈情况为：A B C。C通过intent跳转到D，这个intent添加FLAG_ACTIVITY_NO_HISTORY标志，则此时界面显示D的内容，但是它并不会压入栈中。如果按返回键，返回到C，栈的情况还是：A B C。如果此时D中又跳转到E，栈的情况变为：A B C E，此时按返回键会回到C，因为D根本就没有被压入栈中。

FLAG_ACTIVITY_SINGLE_TOP：和上面Activity的 Launch mode的singleTop类似。如果某个intent添加了这个标志，并且这个intent的目标activity就是栈顶的activity，那么将不会新建一个实例压入栈中。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Activity的主要属性：

allowTaskReparenting：设置成true时，和Intent的FLAG_ACTIVITY_NEW_TASK 标记类似。

alwaysRetainTaskStat:   如果用户长时间将某个task 移入后台，则系统会将该task的栈内容弹出只剩下栈底的activity，此时用户再返回，则只能看到根activity了。如果栈底的 activity的这个属性设置成true，则将阻止这一行为，从而保留所有的栈内容。

clearTaskOnLaunch：根activity的这个属性设置成true时，和上面的alwaysRetainTaskStat 的属性为true情况搞好相反。

finishOnTaskLaunch：对于任何activity，如果它的这个属性设置成true，则当task被放置到后台，然后重新启动后，该activity将不存在了。

问了一下公司的大神，加载模式一般啥时候用。回答如下：

一般一些比较大的,内容比较丰富的Activity使用singleTask或者singleInstance，这实际上是个单例模式，全局只有一个实例存在。