背景
恰逢项目小版本要上一个 极速版轻应用内嵌于主端 APP 内,在 APP 启动时通过读取配置决定是否优先显示轻应用界面。因此,在启动 APP 时需要实时进行不同场景切换。
问题来源
一开始我们通过新增一个 LauncherActivity 用于中转不同场景的切换,原 APP 主页面处理任何 Intent 的逻辑将需要从旧启动页进行 “继承” 处理。这意味着 LauncherActivity 收到任何 Intent 处理的逻辑需从旧启动页代码中拷贝。在继承 LauncherActivity 之后我们发现 一些第三方推送比如小米,华为在进程被杀死的情况下点击通知栏拉起 APP,其 Intent 并没有携带任何业务逻辑进而导致无法精准跳转业务页面。 同时当 APP 处于轻应用页面时收到推送需直接跳转到原主端二级页面时,这些页面的依赖还没有被主端初始化进而导致 Crash !
在该版本做 MTL 兼容测试和业务回归测试时发现:LauncherActivity Intent 处理上存在很多小细节问题,频繁的 “提单-修改-测试-回归” 的成本很大。在经过权衡之后决定不采用 LauncherActivity 方案来解决新版本调整导致问题,同时研究细化 Intent 类型来解决第三方推送通知时无法监听点击通知栏消息的问题。
解决方案
大部分问题都是因为原启动流程发生更改导致的,故不采用 LauncherActivity,而是在旧主页面 onCreate方法 在开头判断是否需要拉起 极速版轻应用 。这样的好处是:先拉起轻应用可以快速显示同时主页面流程继续走,比如一些 token 校验,登陆信息等行为。
由于第三方推送 华为/小米/魅族 等都开放了各自推送 SDK,不同的 ROM 经过测试发现:当 app 没有被启动情况下点击通知栏推动信息拉起应用时回调信息不一,有些甚至没有回调。
下面是经过测试并总结一些拉起场景。
由于被拉起