图片格式的选择:如果对图片的要求不高,可以换成 565
接入资源混淆
减少 Dex 数量
12、选择合适的启动框架
启动优化整个流程的梳理,流程的梳理,我们这里引入了一个有向无环图的概念,我们会把整个的概念梳理成有向无环图的结构,
然后会去挨个加载。右边的部分,可以看到我们其实在启动的时候,首先会去加载一些必要的启动项,必要的启动项是左边流程,
会用一个多进程的方式加载,以来有向无环图进行控制,比如说我是在非必须的时候启动加载我可以放在后面再去加载。当然在整
个有向无环图的顺序加载,其实还是会做一些进程的判断,要判断某些项目是不是要在主进程里加载,某些要在初始进程里面加载
从 Spark 的 DAGScheduler 中领悟到它的核心思想,面向阶段调度(Stage-Oriented Scheduler):把应用划分成一个个的阶段
(Stage),再把任务(Task)安排到各个阶段中去,任务的编排则是通过构建 有向无环图(DAG),把任务依赖通过图的方式梳
理得 井井有条。因为它分阶段执行,先集中资源把阶段一搞定,再齐心协力去执行阶段二,这样即能控制拥塞,又能保证时序,还
能并发执行,让设备性能尽可能得到发挥大家可以参考淘宝的全链路优化的案例:历时1年,上百万行代码!首次揭秘手淘全链路性能优化(上)
13、启动网络链路优化
问题和优化点
发送处理阶段:网络库bindService影响前x个请求,图片并发限制图片库线程排队
网络耗时:部分请求响应size大,包括 SO文件,Cache资源,图片原图大尺寸等
返回处理:个别数据网关请求json串复杂解析严重耗时(3s),且历史线程排队设计不合适
上屏阻塞:回调UI线程被阻,反映主线程卡顿严重。高端机达1s,低端机恶化达3s以上
回调阻塞:部分业务回调执行耗时,阻塞主线程或回调线程
优化
多次重复的请求,业务方务必收敛请求次数,减少非必须请求。
数据大的请求如资源文件、so文件,非启动必须统一延后或取消。
业务方回调执行阻塞主线程耗时过长整改。我们知道,肉眼可见流畅运行,需要运行60帧/秒, 意味着每帧的处理时间不超过
16ms。针对主线程执行回调超过16ms的业务方,推动主线程执行优化。
协议json串过于复杂导致解析耗时严重,网络并发线程数有限,解析耗时过长意味着请求长时间占用MTOP线程影响其他关键
请求执行。推动业务方handler注入使用自己的线程解析或简化json串。
14、预加载
Activity 打开之前就预加载数据,在 Activity 的 UI 布局初始化完成后显示预加载的数据,大大缩短启动时间。 可以参考 :https://g
ithub.com/luckybilly/PreLoader/blob/master/README-zh-CN.md
15、保活
保活,是各个应用开发者的噩梦,也是 Android 厂商关注和打击的重点。不过从启动的角度来看,如果应用进程不被杀,那么启动
自然就快了,所以保