这是一次在App 启动过程优化的经验之谈,没有什么高深的知识。主要是简述用户使用App帐密登录的后,在此从桌面点击打开App之后的启动(冷启动)后App内部逻辑的优化过程。
参加Android 项目开发,该项目和大多数App一样是需要先登录,登录帐号成功后再去获取用户的其他业务信息。App 没有真正的在线状态,后端服务器和终端是通过登录后返回的一个token 来维护用户的登录状态信息(类似http的cookie)。
1 没有优化之前,逻辑如下:
用户点击桌面App 到进入主页面过程,最初版本流程如下:
1)进入StartActivity(闪屏);
2)使用上次保存的用户的帐密信息发起API登录请求(还是在闪屏);
3)API 登录完成后,拿到了token信息,闪屏结束,进入MainActivity;
4)MainActivity 启动后进入加载状态,API 请求带着token 去获取其他更多用户主要业务信息;
5)获取业务信息完成,MainActivity展示主要业务信息。
时序图:
上面从App 启动到用户业务信息展示,这个过程一共启动了两次Activity,发起了两次API网络请求。启动两次Activity 在一下老点差点的设备上,可能花费2秒或者更多时间;两次API请求,在网络环境不那么好的情况下,可能会花费2-3秒甚至更久,也就是App 启动闪屏开始到用户业务信息完全展示,过程可能经过五秒的加载过程状态。
还没优化之处,常常收到用户反馈:启动太慢了。
Activity 每次按回退键回到后台时候,会被销毁掉。再次在桌面点击App 时候,又会重新跑一遍上面的1-5个步骤,这样,用户感觉启动慢的过程就更加明显了。
2 第一步优化
App 回退到后台时候,进程是不一定被回收的,系统资源紧张时候后台进程才可能被回收。还在运行的App,再次点击桌面打开时候,这个过程是热启动了,这里有个很明显的优化点,已经登录过了的进程,再次进入StartActivity 时候是没有必要再次发起登录请求了的,进入步骤2 时候,应该先判断下内存有没有登录过了的token了,如果有,步骤2、3 不用再次登录了,直接进入步骤4即可。
在用户高频使用App 情况下,只是启动了两次Activity,一个更新用户业务数据的App 请求,这样启动过程时间就会明显缩短了(上图中,也就是高频用户大部分都走了红线的逻辑);但在App 使用频率不高的用户下,每次启动App 时候,几乎都是从进程创建开始的,所以这批用户的使用环境下,启动过程还是可能慢的。
3 第二步优化
仔细想想那个token的原理,就会知道token 是会有有效期的。研发约定token 有限期时长是3天,所以这里有个很大的优化点。
API 返回token 后,同时保存一份到本地存储(浅蓝色箭头)。在第一次优化基础上,若内存没有token 信息(冷启动,也就是该进程生命周期内没有登录过的情况下),再去读取下本地存储有没有保存了这个token 信息,如果有并且token 在有效期内,那么也不需要发起登录API 请求了,直接进入步骤4了。
这次优化是在有效期内重用token 的机制,在App 被回收后再次打开时候(冷启动的情况),达到和第一次的效果。使得大多数情况下,App 启动过程都是闪屏下一闪而过了就进入了MainActivity 的业务界面了(也就是大部分用户都走红线的逻辑,token 过期时候才完整流程 )。
这次优化后,用户抱怨App 启动慢的怨言几乎没有了。
3 第三步优化
重写MainAcitity 的onBackPressed,如下:
@Override
public void onBackPressed() {
moveTaskToBack(true);
}
其实这次不算是优化。只是在业务窗口时,用户按回退时候使得业务MainActvity 只是回到后台,而不是finish 销毁掉。
这样用户在业务信息页面上使用时,点击手机的回退键,MainActivity 不会被销毁,而是回退到后台。在手机资源不紧张的情况下。用户再次从桌面点击打开App,这时候的App 进程没有被回收,在业务窗口MainActvity 也没有被回收的情况下,就没有经过上面的步骤了,系统直接把MainActivity 切换到前台,这样就达到秒开的效果了。
至此,几乎没有听说用户在叫App 启动闪屏转很久启动慢之类的问题了。
4 后记
这次优化过程比较基础,但也比较实用。在有登录状态的App 启动时候可以按照上述步骤进行优化,用户体验至上嘛。打开App,如果达到秒开效果,这样的体验就给人很自然的感觉了。看过很多App启动时候,闪屏会转很久,就算刚刚按back键把它回到后台再次打开也是这样,用户体验感觉挺差的,估计就是这块没有做好了。
(全文完)
(欢迎转载本站文章,但请注明作者和出处 云域 – Yuccn )