Android 内存重启优化

发表于 | 分类于 | 阅读次数:

这篇文章是由Android App 的一种内存重启现象引发的思考，是基于Activity 基类的规范状态使用和数据处理。

这种设计的关键内存重启后怎么进行恢复关键数据和预加载数据，并且规范 Acitivity 基类，让团队减少处理内存重启的情况，并且减少因为 关键数据缺失 导致的崩溃问题。

概念：

  1. 内存重启：表现是 App 从后台进入前台的过程中，因为内存数据之前已经被回收，系统会从最后一个显示的 Activity 开始一步步恢复 Activity 和 Activity 状态。
  2. Activity 状态 - 初始状态 ：初始状态为 Activity 加载了一个 layout 布局，还没有获取任何的 id 、操作 view 、开始异步加载数据。
  3. Activity 状态 - 数据渲染状态：初始状态以后开始加载数据和渲染改变一些界面的状态，会以一个方法作为入口，正常启动会直接 onCreate 初始状态后进入 数据渲染状态，但我的做法是内存重启 的时候会在 Activity 的 onActivityResult 才进入数据渲染状态。那么具体怎么做到呢？

讲解

假定：恢复的 Activity 为 RestoreActivity，引导页 Activity 为 AppStartActivity

  • 在所有 Activity 的基类中有判断，若 onCreate 发现是内存重启的情况下，调用 RestoreActivity
    的 startActivityForResult 启动一个引导界面AppStartActivity，同时结束 onCreate 不进入 数据渲染状态，直到启动页面结束返回，这个恢复的 Activity 被系统调用了 onActivityResult 通知我们结果，然后根据接收到返回的对应 result code 进入 数据渲染状态 。
  • 第二点很重要的是，在这个引导界面进行一些 App 的全局数据单例的恢复（例如：已登录的用户单例信息），当然根据需求可以适当预访问或预加载一些比较急需的 App 全局数据，加速返回后的恢复页 Activity 的界面展现，因为引导页的时间一般都会有最低3秒或有个最低秒数阈值，所以理论上可以合理预加载一点数据利用一下，但是一定要注意是在 恢复关键数据 之后，并且到达一定时间就要返回，太长时间的引导界面会让人烦恼，这样设计的关键就是恢复关键数据和预加载数据

为什么会这么设计呢？有心人注意去测试看看 微信 的启动，真正的内存重启的时候，会让你看到 小人 + 地球 的引导 Activity，再返回真正的对应恢复 Activity，用户体验上也是内存重启就会出现一个相对较友好的引导界面做了一个长期的用户认知培养，而不是一个 正在加载或容易 crash 的界面。

拓展

可以不用依赖于一个 Activity 级别去实现这个 引导界面，通过 Fragment 和 属性变量来实现也可以，若发现是 内存重启 不进入 数据渲染状态，加载引导 Fragment，做对应的恢复关键数据和预加载数据，改变属性变量调用对应的入口方法，继续进入 数据渲染状态