相信对于 Android 工程师来说，startActivity 就像初恋一般。要求低，见效快，是每一个菜鸟 Android 工程师迈向高级 Android 工程师的必经阶段。经过这么多年的发展，startActivity 在 google 的调教下已经变得愈发成熟，对工程师的要求也越来越高。、
taskAffinity
通过设置不同的启动模式可以实现调配不同的 Task，但是 taskAffinity 在一定程度上也会影响任务栈的调配流程。每一个 Activity 都有一个 Affinity 属性，如果不在清单文件(AndroidManifest.xml)文件中指定，默认为当前应用的包名。taskAffinity 主要有以下几点需要注意：
1. taskAffinity 会默认使 Activity 在新的栈中分配吗？
在一个 Android 项目 LagouTaskAffinity 中，创建两个 Activity，First 和 Second。除了类名之外，其他都是默认配置。
点击 First 中的 Button，从 First 页面跳转到 Second 页面。然后命令行中执行以下命令
adb shell dumpsys activity activities这个命令会将系统中所有存活的 Activity 信息打印到控制台，如下：
上图中的 TaskRecord 代表一个任务栈。在这个栈中存在两个 Activity 实例，First 和 Secode。其中，Second 位于栈顶。
接下来，修改 Second 的 taksAffinity 为 lagou.affinity，使他也 First 的不同。
重写运行代码，并再次查看任务栈中的代码，如下：
从上图可以看出，虽然 First 和 Second 的 taskAffinity 不同，但是它们都被创建在一个任务栈中。
如果将 Second 的 launchMode（启动模式） 改为 singleTask，再次重新运行，结果如下：
两个 Activity 被分配到了不同的任务栈中。
所以回到上面的问题，taskAffinity 会默认使 Activity 在新的栈中分配吗？
答案是：不会。单纯使用 taskAffinity 不能导致 Activity 被创建在新的任务中，需要配合 singleTask 或者 singleInstance。
2. taskAffinity + allowTaskReparenting
allowTaskReparenting 赋予 Activity 在各个 Task 中间转移的特性。一个在后台任务栈中的 Activity A，当有其他任务进入前台，并且 taskAffinity 与 A 相同，则会自动将 A 添加到当前启动的任务栈中。
生活中的场景：
1. 在某外卖App 中下好订单后，跳转到支付宝进行支付。当在支付宝中支付成功后，页面停留在支付宝支付成功页面。
2. 按 Home 键(支付成功的页面加入到了后台任务栈中)，在主页面重新打开支付宝，页面上显示的是之前的支付成功页面。（有一个与"支付成功"页面相同taskAffinity的任务进入到前台）
3. 再次进入外面 App，可以发现支付成功页面已经消失。
造成上面现象的原因就是 allowTaskReparenting 属性。
实例演示
分别创建2个Android工程: First 和 TaskAffinityReparent
●在First中有3个Activity: FirstA、 FirstB、 FirstC，打开顺序依次是FirstA -> FirstB -> FirstC 。其中FirstC的taskAffinity为“lagou.affinity” ，且allowTaskReparenting属性设置为true。
● TaskAffinityReparent 中只有一个 Activity：ReparentActivity，并且其TaskAffinity也等于“lagou.affinity”。
● 将这两个项目分别安装到手机上之后，打开First App。并从FirstA开始跳转到FirstB,再进入FirstC页面，然后按Home键，使其进入后台任务。
此时，系统中的 Activity 信息如下
● 打开TaskAffinityReparent 项目。屏幕上本应该显示 ReparentActivity，但实际上显示的却是 FirstC的内容。并且系统中 Activity 信息如下：
可以看出 FirstC 已经从后台任务栈中移动到与 ReparentActivity 相同的任务栈中。并且，FirstC 位于栈顶位置，再次点击返回键，才会显示 ReparentActivity 的内容。
通过 Binder 传递数据的限制
Activity 在界面跳转时，使用 Intent 传递数据是最常用的操作。但 Intent 传值偶尔也会导致程序崩溃。如下代码所示:
public void startFirstB(View view){
Intent intent = new Intent(this, FirstB.class);
intent.putExtra("bean", new Bean()); // 传递 Bean 中的数据
startActivity(intent);
}
static class Bean implements Serializable{
private byte[] data = new byte[1024 * 1024];
String str = "data string";
}在 startFirstB 中跳转 FirstB 页面，并通过 Intent 传递 Bean 中数据。但是，执行上述代码会报如下错误
上面日志中的信息是，intent 中的数据过大。最终的原因是 Android 对使用 Binder 传递数据进行了限制，通常情况为 1MB。但是，根据不同版本、不同厂商，这个值会有区别。
解决 Binder 传递数据的限制
1. 减少通过 Intent 传递的数据，将非必须字段使用 transient 关键字修饰。
比如上述代码 Bean 类中，byte 类型数据 data 并非必须使用的数据，则需要避免将其序列化，如下所示：
添加 transient 修饰后，再次运行代码，则不会再报异常。
2. 将对象转化为 Json 字符串，减少数据体积。
将类中数据转化为 JSON 字符串可以减少数据大小，比如使用 Gson.toJson() 方法。大多数时候，将类转化为 Json 字符串之后，还是会超出 Binder 限制，说明实际要传递的数据是很大的。这种情况则需要考虑使用本地持久化来实现数据共享，或者使用 EventBus 来实现数据传递。
通过 Process 造成多个 Application
在自定义的 Application 中做一些初始化的操作，比如 App 分包、推送初始化、图片加载库的全局配置等。
但实际上，Activity 可以在不同的进程中启动。而每一个进程都会创建一个 Application，因此有可能造成 Appcation 的 onCreate() 方法被多次执行，比如以下代码：
RemoteActivity 的 process 为 “lagou.process”，这会导致它在一个新的线程中创建。当中 MainActivity 跳转到 RemoteActivity 时，LagouApplication 会被再次创建。其代码如下：
最终打印日志如下：
可以看出，LagouApplication 的 onCreate() 方法被创建了2次。因此，各自初始化的操作也会执行2次。
解决办法：2种比较好的处理方法：
onCreate 方法中判断进程的名称，只有在符合要求的进程里，才执行初始化操作；
抽象出一个与 Application 生命周期同步的类，并根据不同的进程创建相应的 Application 实例。
后台启动 Activity 失效
试想这样一种情况，当用户正在玩着游戏，手机后台可能有某个下载 apk 的任务，但 apk 下载完之后，突然弹出 apk 安装界面，中断了游戏界面的交互。这种情况便造成了极差的用户体验。
为了避免这种情况的发生，从 Android10(API 29) 开始，Android 系统对后台进程启动 Activity 做了一定限制。主要目的就是避免当前的交互不被打断。
但是，这也造成了一些其它实际问题，例如
在项目中有 Force Update 功能，当用户选择升级之后会在后台进行新的安装包下载任务。正常情况下下载功能要弹出 apk 安装界面，但是在某一版升级时突然很多用户反馈无法弹出下载界面。经过查看抓取的 log 信息，最终发现有个特点就是都发生在 Android 10 版本，是版本兼容问题。
Android 官方建议使用通知来替代直接启动 Activity 操作。也就是，当后台执行的任务执行完毕，并不会直接调用 startActivity 来启动新的界面。而是通过 notificationManager 来发送 notification 到状态栏。这样，既不会影响当前的交互操作，用户也能及时获取后台的进展情况。
总结
使用startActivity时可能会遇到的问题:
● taskAffinity 实现任务栈的调配；
● 通过Binder传递数据的限制；
● 多进程应用可能会造成的问题；
● 后台启动Activity的限制。
