本文详细探讨了Android应用启动过程中的优化策略，包括IO操作优化、类重排、IdleHandler利用、App瘦身、启动框架选择、全链路优化、网络链路优化以及业务和流程梳理，以提升启动速度和用户体验。
- 转移到 Native 实现
可以参考下面这篇文章 支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」)
启动过程中负载比较高，有许多系统 IO 都在此时发生，这时候 IO 的性能下降会比较快，此时 App 中的 IO 操作会比平时更慢一些，尤其是在性能比较差的机器上。
IO 分网络 IO 和磁盘 IO ，启动过程中不建议进行网络 IO ，对于磁盘 IO 则要细扣，邵文在高手课里面有讲到：
-
我们要清楚启动过程中读了什么文件、多少个字节、 Buffer 是多大，使用了多长时间、在什么线程等一系列信息
-
进行启动过程中的 IO 监控，微信在监控 IO 时发现有用户的 db 文件达到了 500MB
下面图中可以看到低内存的时候，启动应用主线程有较多的 IO 等待（UI Thread 这一栏，橘红色代表 IO 等待 ）
利用 Linux 的 IO 读取策略，PageCache 和 ReadAhead 机制，按照读取顺序重新排列，减少磁盘 IO 次数 。具体操作可以参考支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能 这篇文章
Linux 底层文件系统中 VFS 上次 App 进程之间，存在一层 pagecache，pagecache 由内存中的物理 page 组成，其内容对应磁盘上的 block。Pagecache 的大小是动态变化的，可以扩大，也可以在内存不足时缩小。Cache 缓存的存储设备被称为后备存储（backing store），一个 page 通常包含多个 block，这些 block 不一定是连续的
利用文件重布局结合Pagecache 机制可以减少启动过程中的真正 IO 的次数，简单的说，通过文件重布局的目的，就是将启动阶段需要用到的文件在 APK 文件中排布在一起，尽可能的利用 pagecache 机制，用最少的磁盘 IO 次数，读取尽可能多的启动阶段需要的文件，减少 IO 开销，从而达到提升启动性能的目的
类重排的实现通过 ReDex 的 Interdex 调整类在 Dex 中的排列顺序。Interdex 优化不需要去分析类引用，它只需要调整 Dex 中类的顺序，把启动时需要加载的类按顺序放到主 dex 里，这个工作我们完全可以在编译过程中实现，而且这个优化可以提升启动速度，优化效果从 facebook 公布的数据来看也比较可观，性价比高。具体实现可以参考 Redex 初探与 Interdex：Andorid 冷启动优化
应用主界面布局优化是老生常谈了，综合起来无非就是下面两点，这个需要结合具体的界面布局去做优化，网上也有比较多的资料可以查阅
-
通过减少冗余或者嵌套布局来降低视图层次结构
-
用 ViewStub 替代在启动过程中不需要显示的 UI 控件
-
使用自定义 View 替代复杂的 View 叠加
IdleHandler：当 Handler 空闲的时候才会被调用，如果返回 true, 则会一直执行，如果返回 false，执行完一次后就会被移除消息队列。比如，我们可以将从服务器获取推送 Token 的任务放在延迟 IdleHandler 中执行，或者把一些不重要的 View 的加载放到 IdleHandler 中执行
可以在 systrace 生成的文件中看到 verifyClass 过程，因为需要校验方法的每一个指令，所以是一个比较耗时的操作。
App 瘦身包括代码瘦身和资源瘦身，通常的做法如下：
-
Inspect Code ：Android Studio 提供的代码审查工具，实际上是内嵌了 Lint
-
代码混淆
-
图片格式的选择：如果对图片的要求不高，可以换成 565
-
接入资源混淆
-
减少 Dex 数量
启动优化整个流程的梳理，流程的梳理，我们这里引入了一个有向无环图的概念，我们会把整个的概念梳理成有向无环图的结构，然后会去挨个加载。右边的部分，可以看到我们其实在启动的时候，首先会去加载一些必要的启动项，必要的启动项是左边流程，会用一个多进程的方式加载，以来有向无环图进行控制，比如说我是在非必须的时候启动加载我可以放在后面再去加载。当然在整个有向无环图的顺序加载，其实还是会做一些进程的判断，要判断某些项目是不是要在主进程里加载，某些要在初始进程里面加载
从 Spark 的 DAGScheduler 中领悟到它的核心思想，面向阶段调度（Stage-Oriented Scheduler）：把应用划分成一个个的阶段（Stage），再把任务（Task）安排到各个阶段中去，任务的编排则是通过构建 有向无环图（DAG），把任务依赖通过图的方式梳理得 井井有条。因为它分阶段执行，先集中资源把阶段一搞定，再齐心协力去执行阶段二，这样即能控制拥塞，又能保证时序，还能并发执行，让设备性能尽可能得到发挥
[图片上传失败…(image-6f2fdf-1574833214431)]
大家可以参考淘宝的全链路优化的案例：历时1年，上百万行代码！首次揭秘手淘全链路性能优化（上）
问题和优化点
-
发送处理阶段：网络库bindService影响前x个请求，图片并发限制图片库线程排队
-
网络耗时：部分请求响应size大，包括 SO文件，Cache资源，图片原图大尺寸等
-
返回处理：个别数据网关请求json串复杂解析严重耗时（3s）,且历史线程排队设计不合适
-
上屏阻塞：回调UI线程被阻，反映主线程卡顿严重。高端机达1s，低端机恶化达3s以上
-
回调阻塞：部分业务回调执行耗时，阻塞主线程或回调线程
优化
-
多次重复的请求，业务方务必收敛请求次数，减少非必须请求。
-
数据大的请求如资源文件、so文件，非启动必须统一延后或取消。
-
业务方回调执行阻塞主线程耗时过长整改。我们知道，肉眼可见流畅运行，需要运行60帧/秒， 意味着每帧的处理时间不超过16ms。针对主线程执行回调超过16ms的业务方，推动主线程执行优化。
-
协议json串过于复杂导致解析耗时严重，网络并发线程数有限，解析耗时过长意味着请求长时间占用MTOP线程影响其他关键请求执行。推动业务方handler注入使用自己的线程解析或简化json串。
Activity 打开之前就预加载数据，在 Activity 的 UI 布局初始化完成后显示预加载的数据，大大缩短启动时间。 可以参考 ：https://github.com/luckybilly/PreLoader/blob/master/README-zh-CN.md
保活，是各个应用开发者的噩梦，也是 Android 厂商关注和打击的重点。不过从启动的角度来看，如果应用进程不被杀，那么启动自然就快了，所以保活对应用启动速度也是有极大的帮助。
当然这里说的保活，并不是建议大家用各种黑科技、相互唤醒、通知轰炸这种保活手段，而是提供真正的功能，能让用户觉得你在后台是合理的、可以接收的。比如在后台的时候，资源能释放的都释放掉，不要一直在后台做耗电操作，该停的服务停掉，该关的动画关掉。
当然对于应用开发者来说，上面说的都太多理想化了，而且目前的手机厂商也会很暴力，应用到了后台就会处理掉，不过这毕竟是一个方向，Google 也在规范应用后台行为和规范厂商处理应用这两方面都在做努力，Android 系统的生态，还是需要应用开发者和 Android 厂商一起取改善。
当然保活还有一条路就是走跟厂商的合作，优化后台内存、去掉重复拉起、去掉流氓逻辑、积极响应低内存警告，做好这些话后可以跟系统厂商联系，谈放到查杀白名单和自启动白名单的可行性
这里涉及到具体的业务，每个 App 都不一样，但是所要做的事情都是一样的，下面是邵文在高手课里面提到的：
-
梳理清楚启动过程中的每一个模块，哪些是一定需要的，那些是可以砍掉，那些是可以懒加载的
-
根据不同的业务场景决定不同的启动模式
-
懒加载防止集中化
可以把具体的业务分为下面四个维度（此处图文来自https://juejin.im/post/5c21ea325188254eaa5c45b1#heading-5）
-
必要且耗时：启动初始化，考虑用线程来初始化
-
必要不耗时：首页绘制
-
非必要但耗时：数据上报、插件初始化
-
非必要不耗时：不用想，这块直接去掉，在需要用的时再加载
然后按需进行加载优化
-
优化业务中的代码效率，抓大放小，先从比较明显的瓶颈处下手，逐步进行优化
-
历史债务要偿还，历史的代码要重构，不能一直拖着
具体的业务会有具体的优化场景，大家可以参考这篇文章中的优化流程和优化项(https://www.jianshu.com/p/f5514b1a826c)
- 数据库及IO操作都移到工作线程，并且设置线程优先级为THREAD_PRIORITY_BACKGROUND，这样工作线程最多能获取到10%的时间片，优先保证主线程执行
- 流程梳理，延后执行；实际上，这一步对项目启动加速最有效果。通过流程梳理发现部分流程调用时机偏失等， 例如
\*\* 1. 更新等操作无需在首屏尚未展示就调用，造成资源竞争
\*\* 2. 调用了IOS为了规避审核而做的开关，造成网络请求密集
\*\* 3. 自有统计在Application的调用里创建数量固定为5的线程池，造成资源竞争
\*\* 4. 修改广告闪屏逻辑为下次生效
- 去掉用无但被执行的老代码
- 去掉开发阶段使用但线上被执行的代码
- 去掉重复逻辑执行代码
- 去掉调用三方SDK里或者Demo里的多余代码
- 信息缓存，常用信息只在第一次获取，之后从缓存中取
- 项目是多进程架构，只在主进程执行Application的onCreate()
StartingWindow 会在用户点击 App 后立即创建并显示(前提是 App 没有禁止 StartingWindow)，在 AppWindow 创建好之后，StartingWindow 消失，AppWindow 显示
默认 App 的启动窗口流程
StartingWindow(SystemWindow)
->MainActivity(AppWindow)
大部分三方 App 启动流程
StartingWindow(SystemWindow)
-> SplashActivity(AppWindow)
-> MainActivity(AppWindow)
###糟糕一点的启动流程是这样的
StartingWindow(SystemWindow)
-> MainActivity(AppWindow)
-> SplashActivity(AppWindow)
-> MainActivity(AppWindow)
更糟糕一点的启动流程：去掉了 StartingWindow
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）
如何做好面试突击，规划学习方向？
面试题集可以帮助你查漏补缺，有方向有针对性的学习，为之后进大厂做准备。但是如果你仅仅是看一遍，而不去学习和深究。那么这份面试题对你的帮助会很有限。最终还是要靠资深技术水平说话。
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。建议先制定学习计划，根据学习计划把知识点关联起来，形成一个系统化的知识体系。
学习方向很容易规划，但是如果只通过碎片化的学习，对自己的提升是很慢的。
同时我还搜集整理2020年字节跳动，以及腾讯，阿里，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。
在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多。
点击：《Android架构视频+BAT面试专题PDF+学习笔记》即可免费获取~
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
动，以及腾讯，阿里，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。
[外链图片转存中…(img-VzTemhWT-1710496115034)]
在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多。
[外链图片转存中…(img-f4hfqTmp-1710496115035)]
点击：《Android架构视频+BAT面试专题PDF+学习笔记》即可免费获取~
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
