Activity保活新方案

Activity保活新方案

背景

公司产品需要对Activity进行保活，有个全局悬浮球，任意时刻点击需要快速恢复界面

符号简写：

H -> HomeActivity

C -> ChatActivity（就是这个页面，需要时刻保活）

P -> PersonalActivity

O -> OtherActivity

接手前的状态

接手前采用的方案是singleInstance,网上关于singleInstance的文章不胜枚举。

1. 保活怎么做呢？用Activity的moveTaskToBack方法，把C所在的Activity栈切到后台，因为C还在activity栈中，所以不会被destory掉

2. 任意页面切回来怎么做的？正常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种策略：

1. 使用基类BaseACtivity，在onCreate中记录
2. 注册ActivityLifecycleCallbacks

onDestory的延迟问题

在activity被finish后，并不一定会立即触发onDestroy，有可能会延迟10秒，在这10秒内我们维持的activity列表中还保留了他的实例，在遍历的时候会被start

解决方法：不要在onDestory中才移除activity的引用，在基类BaseActivity的finish方法中就直接移除掉activity的引用

H是透明主题的情况

在测试到一些早期版本的时候，如果H是透明主题，会出现各种奇葩的activity回调bug，最好的方法就是把透明主题去掉，因为最开始加入透镜主题就是为了切换activity栈的，现在在一个栈里面，这种设定就不需要了。

还有一些策略，仅供参考

1. 正常的操作是onActivitySaveInstanceState，然后再恢复，如果有什么后台操作，需要创建service进行同步。
   • 这有几个问题，如果activity的UI复杂，重建时耗时就比较严重；把原先的activity再单独拆一个service出来改动较大。