AndroidWiki - App启动流程和性能优化精要

一、主页数据业务流程重构

图一：通行的缓存+刷新数据业务示例

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，前三次考虑缩小，如果发生重试，根据时间策略优化空间大；