Activity保活新方案
背景
公司产品需要对Activity进行保活，有个全局悬浮球，任意时刻点击需要快速恢复界面
符号简写：
H -> HomeActivity
C -> ChatActivity（就是这个页面，需要时刻保活）
P -> PersonalActivity
O -> OtherActivity
接手前的状态
接手前采用的方案是singleInstance,网上关于singleInstance的文章不胜枚举。
保活怎么做呢？用Activity的moveTaskToBack方法，把C所在的Activity栈切到后台，因为C还在activity栈中，所以不会被destory掉
任意页面切回来怎么做的？正常startActivity就可以了，因为搜索activity栈的时候能找到已经有一个实例在栈中了，就把这个栈带到前台，完成了页面的展示
但是这样会带来几个问题（假设C为singleInstance）：
-
H->C->P
（H和P位于一个activity栈，C位于另外一个activity栈）
返回栈是什么呢？对了！从P页面按返回键是返回到H的，然后在返回到C，具体可以参考Activity栈与返回栈
这个还好解决，设置H为singleTask的启动模式，在P返回的时候直接startActivity（H）就可以了
如果P有多个，就要记录activities了，然后需要用到activityLifeCycle来监听activity的生命周期，自己来管理返回栈这就太复杂了
-
Activity {C} did not call finish() prior to onResume() completing
实际上线后，出现了一大堆这样的崩溃，基本无解，有能解决这问题的请联系我。
使用newTask尝试
还是回到H->C->P上，通过设置flag，我们可以给C单独开一个activity，而且这个栈上还有堆其他activity（singleInstance是不能在activity栈上继续堆activity的）
虽然这样解决了返回栈的问题，但是却不能保证任一页面随心所欲的调用C，而且也无法解决activity栈切换遇到的其他很多问题。
最烦人的就是每次按下home建再返回时，所有的activity栈顶的activity都会重建，而且没法控制具体显示哪个activity栈。
所以只能寻找有木有什么办法不单独开activity栈
最终解决方案
Intent.FLAG_ACTIVITY_REORDER_TO_FRONT
就是这个，仔细读了下源码，最终的方案就是这个，字面意思就是重新调整activity栈的顺序，让启动的activity位于activity栈的最前端，H->C->P->O,如果由O来启动C的话，把C调整到最上层，变成H->P->O->C。看到有些地方说道activity栈的顺序是不能调整的，这其实是不对的，官方就有调整策略。
解决了任意页面都能正常启动C，那么怎么解决C的保活呢？
把C放到H前面
也就是C->H->P->O，把C调整到activity栈首，这样就能避免activity被回收了。做法也很简单，把记录的activity都依次启动一遍：
activities.filter(activity -> activity!=this).foreach(activity ->
startActivity(Intent(this, activity.getClass()))
)
因为所有的activity都是已经存在于activity栈中的，所以activity只会走到onNewIntent里面，时间复杂度为O(n)，只要onNewIntent里面不要处理太多事务，就没有什么性能的影响。
这其实是一种变通的方法来处理activity栈，说出来大家都懂。
其他一些问题
H为singleTask
H为singleTask的情况很普遍，主要就是想一步回到主页面，其他页面全部出栈。但是官方文档说的很明确singleTask其实是设置flag为clear_top，这会导致Intent.FLAG_ACTIVITY_REORDER_TO_FRONT失效。直接在代码里setFlags也是不行的，并不是简单的
动态设置flag会覆盖xml中的设置
解决办法就是找到所有singleTask的activity，在xml中去掉singleTask，然后在代码中动态设置FLAG_ACTIVITY_CLEAR_TOP
activity栈记录
因为Android9不允许在获取activity栈了，所以我们需要自己保存所有启动的activity，2种策略：
- 使用基类BaseACtivity，在onCreate中记录
- 注册ActivityLifecycleCallbacks
onDestory的延迟问题
在activity被finish后，并不一定会立即触发onDestroy，有可能会延迟10秒，在这10秒内我们维持的activity列表中还保留了他的实例，在遍历的时候会被start
解决方法：不要在onDestory中才移除activity的引用，在基类BaseActivity的finish方法中就直接移除掉activity的引用
H是透明主题的情况
在测试到一些早期版本的时候，如果H是透明主题，会出现各种奇葩的activity回调bug，最好的方法就是把透明主题去掉，因为最开始加入透镜主题就是为了切换activity栈的，现在在一个栈里面，这种设定就不需要了。
还有一些策略，仅供参考
- 正常的操作是onActivitySaveInstanceState，然后再恢复，如果有什么后台操作，需要创建service进行同步。
- 这有几个问题，如果activity的UI复杂，重建时耗时就比较严重；把原先的activity再单独拆一个service出来改动较大。
