本来呢,这种设计也是无伤大雅的,但是 Android Q 来了,就不一样了。最近刚发布了 Android Q Beta 4 版本,按照其时间表来看,今年第三个季度就会发布正式版。
Android Q 具有更强的隐私保护,其中有一条,它开始限制后台 App 启动 Activity。
以最新的 Android Q Beta 4 来举例,当你的 App 处于后台时,一旦尝试开启新的页面,会发生什么呢?首先你的新页面肯定是打不开的,在现有的 Beta 版本上,系统还会输出一条警告 Log,并弹出一条 Toast。
例如,我们开发者比较常用的 掘金App。
猜想,在正式版发布时,应该会去掉此 Toast 警告,没必要以这么强的提示来提醒用户。
但是这依然是我们需要提前做好适配准备的。毕竟在不少快速迭代的项目中,启动速度并不是优先考虑优化的指标,各种初始化也很随意的就放在了启动页里,到最后不得不优化的时候,就比较费时和令人头疼了。
二. MD 设计里的启动页
在启动页里,做大量的逻辑,甚至强制间隔几秒(显示广告),这种做法本身在 Google 的设计规范就是不推荐的,不少海外大厂的 App,也是遵循此设计规范。
![](https://upload-
images.jianshu.io/upload_images/15233854-d85d37e94a194a6a?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
而国内的 App 里,在启动页里加塞点功能,好像是一种更为普遍的做法。
在 Material Design 的设计规范中,也明确定义了启动图的设计规范,其核心就是为了解决冷启动时,那个短暂的白屏不至于显得太突兀,设计的好了,还可以增加品牌的辨识度。
启动页面的设计,其重点在于,它仅仅在应用启动的瞬间显示,也就是说,启动页面不应该导致应用的启动变慢,强制显示一段时间广告,更是不应该的做法。
毕竟打开 App 是为了它的功能,更快把首屏展示给用户,体验就更好。
三. Q 的后台启动建议
在 Android Q 之前的版本中,本质上就已经对一些页面的显示做了限制,例如 Android 8.0 增加了悬浮窗权限,其实更多的也是为了不让一些恶意的 App 打扰用户。
这次 Android Q 更彻底,当前处在后台的 App,没有打开新页的权限,这种设定,按照我们常规的思考,对开发者的影响应该不大,毕竟大多数时候,我们并不需要在后台弹出一个页面。
这不是撞上了国内较重的启动页设计,才会出现问题。
针对必要的显示,Google 也明确给出了解决建议,可以判断应用在后台时,通过向用户发送一条通知(Notification),来由用户决定是否开启这个页面。
这种解决方案,在本文这个语境中,自然是没有什么鸟用的,走都走了,总不能抱住用户的大腿。
这种安全级的升级优化,我觉得按照官方的规范,适配就好了。
四. 适配思路
4.1 遵循 MD 规范
前面也提到,如果我们遵循 Material Design 的规范,只让启动图,作为一个对冷启动的优化,瞬时展示,之后立即显示主页,就不会有问题。
在这个过程中,全程只有一个 Activity 参与,自然无需启动一个新页面,也就不会有问题。唯一需要注意的是,在 setContentView()
方法之前,别忘了修改当前页面的 Theme。
对于现有项目,这种优化,其实我们大部分的工作,来自如何协调已经在启动页中的各种资源的初始化逻辑,等于之前有一个空转的时间被利用起来初始化资源了,现在这些已经占用的时间,没有了。
不过也别担心,其实有不少优秀的开源库就在解决这些问题,例如之前推文中介绍的 Alibaba 的 Alpha 库,就是一个基于 PERT 图构建的 Android 异步启动框架。
4.2 先判断是否前台再跳转
正如小标题上写的,我们可以在启动页跳转到主页时,检测当前页面是否在前台,如果不在,就放弃跳转。因为在后台时,并没有打开新页的动作,自然也不会有警告提示。
这算是一种,在现有项目基础之上,改动最小适配方案。
此时再细化一些,在我们放弃跳转后,可以有两个选择:
1. 关闭启动页,下次再被点击重走启动页逻辑
这很好理解,把启动页 finish()
掉,假装它从来没有启动过。下次用户再启动时,之前所有的步骤再走一遍,该显示的广告再多一次曝光。
现在有一些 App 已经是这种方案在优化。
2. 关闭启动页,并设置标记位
在发现启动页不在前台显示时,不做跳转的动作,同时设置一个标志位,但是此时不关闭当前页面。下次启动页再被启动时,直接跳转到主页。
如果选择此方案,我推荐第二种细化的方案。