一、主页数据业务流程重构
图一:通行的缓存+刷新数据业务示例
1.1 调整线程机制
这个修改点需要排查和解决包含但不是限于以下五个问题:
1,各线程业务由于历史原因,在单独子模块执行,没有做统一的通知/回调机制,获取执行结果采用土笨的全局标志和轮询的方式,极不合理。此处为紧密流程,应该采用接口回调。
2,全局标志位的作用域太大,不安全。在多人开发和维护的项目中,隐患非常大。
3,不同线程对同一标志位的操作没有做线程同步。
4,假如3.2秒完成获取后台数据,但现有轮询方式是1秒一次,实际显示主页时间还要多等0.8秒,造成不必要的性能损失。
5,线程的使用不合理,每个流程都创建一个或多个线程,没有利用线程池技术。
1.2 将网络请求提前
这个修改点将网络请求从Activity提前到application,无缓存情况下节省400毫秒,有缓存情况下节省200毫秒
1.3 多余启动界面合并
存在一个仅用于跳转逻辑的Activity,无故的启动销毁占用数百毫秒,使用MVP将其维护到闪屏页的Presenter。
1.4 主页分页加载
主页元素过多,每一行都是不同的数据配置加载自定义ViewGroup,没有采用RecyclerView做Item管理,因此数据量过重,但数据集带有id,可基于有序id采用分页,在满足用户体验的基础上,加快流程。
1.5 主页非核心view懒加载
主要利用getWindow().getDecorView().post(){Handler.postDelay()} 懒加载机制,将主页的非核心view做延迟渲染;
二、性能优化
2.1 启动页背景大图剪裁
主要修改
背景图片一般需要在主线程优先加载,影响较大,考虑将各种背景图片改小,包括主题图片、layout背景图片、广告图片,改用主题颜色背景,或者使用轻量Image;
2.2 广告图片加载优化
主要修改
将耗时的广告File文件加载,改为异步加载,将主线程时机让出。
使用Glide加载File使得该图片纳入整体内存,回收可控。
广告1.2M高清图片也是非常大的图片,可以再剪裁,不仅占cpu时间片还耗内存。
2.3 Json解析
主要修改:
导入Logansquare解析组件,构建MasterParseEntity数据模型类系;
对原来分散的数据解析,合并为一次解析,各处需要时直接读取。
2.4 分散与启动无关的非紧急业务
主要修改:
页面跳转的同时发起历史记录及打点等数据上报,有SharedPreferences和较多的IO数据操作;配置文件及各种第三方sdk也集中在启动时初始化。
排查非必要初始化业务,靠后发起;
排查非主线程业务,子线程发起。
2.5期间各种子线程管理
导入线程池管理模块,使得线程开销和切换可控。
2.6 动画处理
主要修改
剔除退场动画,如有特别必要,应该给主页做轻量级入场动画即可
主页启动时,logo发起一个循环动画,将动画发起时机后移到view渲染完成之后,让出此时宝贵的主线程
2.7 其它
包括大量的静态变量修改、同步锁机制优化等等,不做细表。
2.8 网络重试
启动期间几个网络任务,如重试,时间策略粒度较大Math.pow(2, count) * 3000,前三次考虑缩小,如果发生重试,根据时间策略优化空间大;