Activity启动模式的深入分析

Posted 2020-09-22 jzssuanfa

      网上关于Activity启动模式的文章许多。可是看起来都千篇一律，看完之后我们都能理解这4种启动模式。只是官方api对singleTask这个启动模式解释有些争议，导致我事实上并没有真正理解这几种模式，特别是对实际开发究竟怎么用还是一知半解。于是花了一天时间好好研究这4种启动模式。

       首当其冲应该知道Task的概念，它是我们一系列操作连贯跳转activity形成的一个activity栈，后进先出也就是说当前看到的activity在最上面，关于Task的概念老罗一篇博客说的比較清楚，引自老罗博客：

          “在解开这个谜之前，我们先来简单了解一下在android应用程序中，任务（Task）是个什么样的概念。

我们知道。Activity是Android应用程序的基础组件之中的一个，在应用程序执行时。每个Activity代表一个用户操作。

用户为了完毕某个功能而执行的一系列操作就形成了一个Activity序列，这个序列在Android应用程序中就称之为任务。它是从用户体验的角度出发。把一组相关的Activity组织在一起而抽象出来的概念。”

         为什么要设置不同的启动模式呢？是为了更好的复用activity，带来两个优点一是节约系统资源，二是避免糟糕的用户体验。比方当前已经存在这个activity，除了standard其它三种模式就会去查找是否存在activity，假设存在就不再运行onCreate()去new而是直接把那个activity显示在栈顶并调用onNewIntent()。singleTop  singleTask singleInstance的差别就是查找的范围不一样，singleTop最小仅仅会在当前task的栈顶去看(单应用级别),而singleTask不仅在当前task还会在其它的Task查找(半应用半系统级别)，而singleInstance仅仅会去其它task查找,由于有singleInstance的activity都是独占一个task，你的当前task不可能含有这个activity！

那么广义上也能够觉得singleInstance是系统全局的。

        所以能够这么理解4种启动模式。更清晰：

            standard    不限实例个数。仅仅要启动就会在当前task最上面new一个实例。能够叠加，注意它不会创建新的Task

           singleTop   在当前栈顶(Top)仅仅有一个实例。

比方自己启动自己仅仅会是同一个实例。只是这样的需求貌似非常少，另一种就是一个界面打开着。被外部service或者广播重复启动，比方新闻client打开着接受推送打开界面。那么你在自己的acticityA打开另外应用的activityB，这个B设置成singleTop就是无意义的。由于它仅仅推断当前A的Task，so我前面把它理解成单应用级别。(当然更严谨一点仅仅限activity由于service或者广播能够是其它应用的)

            singleTask  在全部Task仅仅有一个实例。

这个启动模式争议最多特别是官方文档说："singleTask"会在新的任务中执行，而且位于任务堆栈的底部。

非常多人不认同，老罗也写了博客来解释，事实上官方文档没错，由于singleTask一般要跟android.intent.action.MAIN和android.intent.category.LAUNCHER一起配置。作为程序入口他当然是栈底，会在新的任务启动是指当前Task没有这个activity的情况，而singleTask的正确使用就应该满足这样的情况，所以官网文档的解释建立在我们正确使用这个属性的基础上，假设你非不把singleTask和android.intent.action.Main  category.LAUNCHER一起配置，那另当别论可是无意义。

            那么先说singleTask的启动逻辑：1. 假设当前task有这个activity我们直接把它上面全部activity clear掉，它就显示出来了。

2. 假设当前task A没有可是其它task B(通常是其它应用的task)有这个activity。我们直接把task B整个搬到task A上面。而且把task B上面的多余activity clear掉。当然若这个activity就在task B的顶部就不须要咯，搬过来就显示了，此时按回退键就会从task B開始一个个往task A回退  3. 若全部task都没有这个activity就会new一个实例在新的task B放在task A上面(注意这里new了Task)。依照这个逻辑思考一下。我们把浏览器的首页设置为singleTask而且加上Main和LAUNCHER的属性，一启动它就在栈底了。用了一段时间浏览器导致大量activity堆积。我们仅仅要回到首页，由于它是singleTask那么上面的activity都被clear，此时用户点后退就退出整个应用了，非常舒服人性化的操作。

还有，我们从别的应用比方微信想訪问网页就会打开这个浏览器首页，由于它肯定在栈底那我们訪问完了直接后退就能回到我们自己应用，试想一下这个首页activity不和Main&LAUNCH一起，那他以下肯定有浏览器其它activity堆积，我们訪问完了点后退就会看到浏览器之前未关闭的activity，多次后退才回到微信，非常奇怪不是吗。而且浏览器首页是笨重的界面，假设不设为singleTask我们从其它应用打开就得new非常多个，浪费资源。包含联系人APP首页也是一样的道理。

               

                   singleInstance  在全部Task仅仅有一个实例，而且这个task仅仅有它一个activity存在。这个用的少一些，比方在接听电话的那个界面InCallUi,就把他单独放在一个task，不与不论什么其它activity共存。由于不是必需，接电话的界面还能往哪跳？ 比方闹钟响铃提醒界面，都是些和其它activity无关联不需跳转的界面，也就是独立性非常强的activity。

           总结一下：能够把前两种模式归在一起学习，一般在单个应用开发，这个界面不会被其它应用启用的情况,并且跳转频繁用singleTop。不怎么跳转并且activity较少用标准也能够。要是系统级的比方浏览器，联系人，电话。短信就要考虑后两种模式了，别人写的应用场景。參考一下：

          

singleTop适合接收通知启动的内容显示页面。

比如，某个新闻client的新闻内容页面，假设收到10个新闻推送，每次都打开一个新闻内容页面是非常烦人的。

singleTask适合作为程序入口点。

比如浏览器的主界面。

无论从多少个应用启动浏览器。仅仅会启动主界面一次，其余情况都会走onNewIntent。而且会清空主界面上面的其它页面。

singleInstance适合须要与程序分离开的页面。

比如闹铃提醒，将闹铃提醒与闹铃设置分离。

singleInstance不要用于中间页面，假设用于中间页面，跳转会有问题，比方：A -> B (singleInstance) -> C，全然退出后。在此启动，首先打开的是B。

         

參考文档：     http://blog.csdn.net/luoshengyang/article/details/6714543

                        https://developer.android.com/guide/components/tasks-and-back-stack.html