android出栈

‘壹’ android的四大组件有哪些

Android四大组件分别为activity、service、content provider、broadcast receiver。
一、android四大组件详解
1、activity
（1）一个Activity通常就是一个单独的屏幕（窗口）。
（2）Activity之间通过Intent进行通信。
（3）android应用中每一个Activity都必须要在AndroidManifest.xml配置文件中声明，否则系统将不识别也不执行该Activity。
2、service
（1）service用于在后台完成用户指定的操作。service分为两种：
（a）started（启动）：当应用程序组件（如activity）调用startService()方法启动服务时，服务处于started状态。
（b）bound（绑定）：当应用程序组件调用bindService()方法绑定到服务时，服务处于bound状态。
(2)startService()与bindService()区别：
(a)started service（启动服务）是由其他组件调用startService()方法启动的，这导致服务的onStartCommand()方法被调用。当服务是started状态时，其生命周期与启动它的组件无关，并且可以在后台无限期运行，即使启动服务的组件已经被销毁。因此，服务需要在完成任务后调用stopSelf()方法停止，或者由其他组件调用stopService()方法停止。
(b)使用bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止，大有“不求同时生，必须同时死”的特点。
(3)开发人员需要在应用程序配置文件中声明全部的service，使用<service></service>标签。
(4)Service通常位于后台运行，它一般不需要与用户交互，因此Service组件没有图形用户界面。Service组件需要继承Service基类。Service组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。
3、content provider
（1）android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。
（2）只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处是统一数据访问方式。
（3）ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。
（4）开发人员不会直接使用ContentProvider类的对象，大多数是通过ContentResolver对象实现对ContentProvider的操作。
（5）ContentProvider使用URI来唯一标识其数据集，这里的URI以content://作为前缀，表示该数据由ContentProvider来管理。
4、broadcast receiver
（1）你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。
（2）广播接收者的注册有两种方法，分别是程序动态注册和AndroidManifest文件中进行静态注册。
（3）动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，该app订阅的广播在触发时也会对它起作用。
二、android四大组件总结：
（1）4大组件的注册
4大基本组件都需要注册才能使用，每个Activity、service、Content Provider都需要在AndroidManifest文件中进行配置。AndroidManifest文件中未进行声明的activity、服务以及内容提供者将不为系统所见，从而也就不可用。而broadcast receiver广播接收者的注册分静态注册（在AndroidManifest文件中进行配置）和通过代码动态创建并以调用Context.registerReceiver()的方式注册至系统。需要注意的是在AndroidManifest文件中进行配置的广播接收者会随系统的启动而一直处于活跃状态，只要接收到感兴趣的广播就会触发（即使程序未运行）。
（2）4大组件的激活
内容提供者的激活：当接收到ContentResolver发出的请求后，内容提供者被激活。而其它三种组件activity、服务和广播接收器被一种叫做intent的异步消息所激活。
（3）4大组件的关闭
内容提供者仅在响应ContentResolver提出请求的时候激活。而一个广播接收器仅在响应广播信息的时候激活。所以，没有必要去显式的关闭这些组件。Activity关闭：可以通过调用它的finish()方法来关闭一个activity。服务关闭：对于通过startService()方法启动的服务要调用Context.stopService()方法关闭服务，使用bindService()方法启动的服务要调用Contex.unbindService()方法关闭服务。
（4）android中的任务（activity栈）
（a）任务其实就是activity的栈，它由一个或多个Activity组成，共同完成一个完整的用户体验。栈底的是启动整个任务的Activity，栈顶的是当前运行的用户可以交互的Activity，当一个activity启动另外一个的时候，新的activity就被压入栈，并成为当前运行的activity。而前一个activity仍保持在栈之中。当用户按下BACK键的时候，当前activity出栈，而前一个恢复为当前运行的activity。栈中保存的其实是对象，栈中的Activity永远不会重排，只会压入或弹出。
（b）任务中的所有activity是作为一个整体进行移动的。整个的任务（即activity栈）可以移到前台，或退至后台。
（c）Android系统是一个多任务(Multi-Task)的操作系统，可以在用手机听音乐的同时，也执行其他多个程序。每多执行一个应用程序，就会多耗费一些系统内存，当同时执行的程序过多，或是关闭的程序没有正确释放掉内存，系统就会觉得越来越慢，甚至不稳定。为了解决这个问题，Android引入了一个新的机制，即生命周期(Life Cycle)。

‘贰’ Android的四种启动模式！

在Android开发中，为了高效地管理Activity实例，系统提供了四种启动模式，帮助开发者根据实际应用场景选择最合适的模式，以降低内存使用和提升应用性能。下面将详细探讨这四种启动模式及其应用场景。

一、Android的四种启动模式

1. **标准模式（standard）**：这是默认的启动模式，每启动一个Activity都会创建一个新的实例并置于栈顶。如果是由当前Activity启动的，则这个Activity会运行在启动它的那个Activity所在的栈中。应用场景广泛，一般不主动设置启动模式。

2. **栈顶模式（singleTop）**：如果栈顶存在当前Activity的实例，系统会复用这个实例而不创建新的实例。适用于点击通知跳转到详情页或新闻详情页点击推荐新闻条目等场景。

3. **栈内模式（singleTask）**：如果栈内存在当前Activity的实例，系统会将栈中的其他实例出栈并置当前实例于栈顶，如果栈内无实例则创建。适用于APP主页跳转后需要返回主页或浏览器主页等场景。

4. **单例模式（singleInstance）**：系统会为当前Activity新开一个任务栈，该栈内只存放当前实例。适用于需要保持应用开启后仅有一个实例的场景，如语音通话功能。

如何设置启动模式？在AndroidManifest.xml的activity节点中设置lauchmode属性即可。使用栈顶或栈内模式时，需通过onNewIntent回调中的Intent参数接收传递的内容。

设置启动模式不当可能导致应用启动异常，此外，系统bug也可能引发启动问题。为了确保应用质量，开发者应严谨测试，及时发现并解决潜在bug。借助工具如友盟U-APM，可帮助从研发测试到线上问题复现，有效提升测试效率。

云真机测试期间自动采集崩溃信息，提供详尽的崩溃报告，有助于快速定位和解决问题。未使用过的开发者不妨尝试一下，减轻工作压力。

回到主题，接下来将重点介绍启动模式的实际应用场景。

二、启动模式的实际应用场景

标准模式是最常见的选择，无特殊注意点。单例模式则用于需要保持应用中特定Activity实例的场景，一般不直接在应用中应用。下面详细介绍单顶模式（singleTop）和栈内模式（singleTask）的应用场景：

1. **单顶模式（singleTop）**：适用于点击通知跳转到详情页或新闻详情页点击推荐新闻条目等场景。在这种模式下，如果栈顶已有对应的Activity实例，系统会复用实例，避免重复创建。

2. **栈内模式（singleTask）**：适用于APP主页跳转后需要返回主页或浏览器主页等场景。在这种模式下，如果栈内已有对应Activity实例，系统会将实例置于栈顶，避免重复创建实例。

在使用单顶或栈内模式时，还需注意生命周期回调。当一个Activity设置了单顶或栈内模式后，跳转此Activity出现复用原有Activity的情况时，onCreate方法将不会再次运行。因此，需确保页面数据与跳转传递的参数解耦，避免数据获取问题。

以上内容希望能够为Android开发者在选择启动模式和理解其应用场景时提供帮助。通过合理的启动模式选择，可以有效提升应用性能和用户体验。如有更多问题，欢迎继续交流与讨论。

‘叁’ Android 深入探讨sigleTask和singletop的区别

1.singleTask和singletop都是保真了Activity在栈中的唯一性

2.singleTask和singleTop实例存在时，都不会重新创建 new task

不同之处有如下几点：

如果singleTask启动的ActivityA位于栈底，在栈顶startActivity到这个ActivityA时会调动
onNewIntent->onStart->onResume。

但singleTask启动的的ActivityA不存在时，会重新创建ActivityA,调用方式OnCreate->OnStart->OnResume

2.如果singletop启动的ActivityB在栈底时，在栈顶startActivity到这个ActivityB时会重新调动
onCreate->onStart->onResume，但不会调用OnDestroy

并且singletop启动的的ActivityB不存在时，会重新创建ActivityB,调用方式OnCreate->OnStart->OnResume

3.singleTask在栈底时，从栈顶startActivity到栈底ActivityA,那么该栈startActivity的发起者的中间部分Activity会被销毁。而singletop是逐级跳跃到栈顶

singleTask

追加一点singleInstance,虽然也是保证唯一性，但改模式的Activity是全局性的唯一性，生命周期和应用程序相同，不能及时回收，此外的话Activity在MVC充当Controller的角色，

这点显然对singleIntance来说不适合，因此不建议使用。

4.singleTask不适合充当ChildActivity，但singletop适合

5.对作业栈，默认情况下，没有任何影响，因为栈的taskid是相同的，可以获取getTaskid()，默认情况下每个activity的taskid相同

但是，如果自定义了栈的标签（这个标签相同的singletask activity在同一个作业栈中），那么taskid就会初选差别

android:taskAffinity="com.sample.lanchmode.tester.main"，那么一旦另一个作业栈被销毁，下次必然重建（相信我，这不是废话）。

为了一句不是废话，我需要来证明一下。

当我们的初始加载WelcomeActivity界面--->HomeActivity界面时，如果将HomeActivity的启动模式设置为sigleTask+android:taskAffinity="自定义（一般是类名）",

①那么WelcomeActivity销毁后，在到达HomeActivity之后，HomeActivity回作为一个新的作业栈栈底而存在，所以由HomeActivity启动的Activity的TaskId和HomeActivity相同。

②这个过程，WelcomeActivity和HomeActivity的TaskId是不相同的，问题出现了，当我们按下 Home键，然后在点击桌面上的app图标你会发现，WelcomeActivity再次出现了，

而且再次进入了HomeActivity，并且这个HomeActivity调用了OnNewIntent，却没掉用OnCreate，所以来说他一直存在这，但你需要再次过渡才能找到它。

（对于追求捕获Home键让app退出的读者是一个喜讯，这样可以做到每次Home之后都能再次进入登录界面），在这个过程中没有直接进入HomeActivity，而是WelcomeActivity（有人说不对么，不应该是这样么，在这里不想解释）。

注意，使用了不同作业栈的Activity,会在最近打开的app显示一个应用会出现2个界面。

在这里，需要强调一下singleTask+android:taskAffinity不一定必须使用，请依据需求而定，网上有人推荐使用，但我却想说，不要盲目，并不是所有的应用都适合。

1-->
singleTask+android:taskAffinity对于效率而言，优势并不存在，比如设置进程的，但对于带有登录状态的app需要慎用，否则造成信息泄露等问题，开发中只使用singleTask即可。

2-->
singleTask+android:taskAffinity适用于单用户保密性的app（可做到Home之后下次必须登录才能查看信息），建议在这方面试试。

转载