08 | 启动优化(下):优化启动速度的进阶方法
该思维导图由 AI 生成,仅供参考
启动进阶方法
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了应用启动的进阶优化方法,包括I/O优化、数据重排、类加载等技术内容。除了常规优化方法外,还介绍了一些“压箱底”方法,如对I/O性能、数据结构选择和资源文件重排的优化,以减少启动时间波动,提高速度。此外,还讨论了通过Hook去掉类加载过程中的verify步骤以及黑科技对启动速度的影响。总的来说,本文内容涵盖了多个方面的技术优化方法,对于想要进一步优化应用启动速度的读者具有一定的参考价值。 文章还介绍了启动监控的重要性,包括实验室监控和线上监控两种方式。实验室监控可以通过视频录制或图像识别来准确反映启动的耗时,而线上监控则需要考虑更多细节,如启动结束的统计时机、扣除逻辑和排除逻辑等。此外,文章还提到了衡量启动速度的指标,建议使用快开慢开比和90%用户的启动时间等指标来评估用户体验。 在总结部分,文章强调了启动优化需要耐心和深入了解整个流程,同时警示读者要警惕KPI化,解决的不是一个数字,而是用户真正的体验问题。最后,文章鼓励读者分享自己的“压箱底”的启动优化“秘籍”,并提出了课后练习,引导读者深入学习Dalvik虚拟机加载Dex和类的流程。 总的来说,本文内容丰富,涵盖了启动优化的多个方面,对于想要深入了解和优化应用启动速度的技术人员具有很高的参考价值。
《Android 开发高手课》,新⼈⾸单¥59
全部留言(19)
- 最新
- 精选
- 万里大鹏飞您上面说,Buffer不小心写成了 1 byte,总共要读取 1000次,这样会命中Page Cache中不会导致真正的IO。可是实际测试的时候,read同一个文件,buffer大小1byte和1k的read速度还有有差异的,这个是为什么呢?
作者回复: 后面io会讲到。主要差别是系统调用跟数据拷贝的时间
2018-12-235 - 廖凡请教一个问题,一定要回答啊,困扰了很久。 我们在使用tinker过程中,线上运行性能下降。 不光是app启动性能,整个app的运行生命周期都会下降, tinker不应该只影响启动性能吗,为什么整个app的生命周期都有影响呢。 tinker也没有做全局插桩,是和您本文所说的,黑科技导致Android runtime的性能优化无法生效到有关系吗?
作者回复: 1. 类的查找路径变长了 2. 系统base.art的那一套失效了 3. 8.0之后只能解释执行了
2019-09-0224 - MIAN-勉重排顺序的依据是什么,是按照文件大小从小到大以此排序,这样一次磁盘读取可以尽可能多的读文件;还是要综合文件大小、文件读取次数、启动过程是否加载这些因素(这几个因素中哪个权重会大一些),进行文件排序。看过文章后觉得应该是第二种,因为老师有讲到统计、度量这些措施。另外,觉得老师应该就010 Editor查看效果简单介绍一下
作者回复: 重排的目的是首次读取的时候减少缺页,那肯定是按照程序的读取顺序来排序的
2019-07-264 - 功夫熊猫对于dex中的class按文件大小重排没有明白为什么为优化i/o速度,class的加载和在dex的位置有什么关系?
作者回复: Classdef在dex是连续存放的,所以可以一次读取一大段,mmap中断缺页就会少一些
2018-12-252 - gmm请问下怎么样去复写 ClassLoader,获取类的加载
作者回复: 可以参考一下tinker的写法
2019-12-0121 - Swing感觉又迂回到文件系统了。。。基础不好,心塞
作者回复: 一步一步来
2019-01-311 - 小洁优化Dex上文件的重排,是只会在首次安装或者覆盖安装上涉及到吗,其他情况呢?
作者回复: Dex重排是任何时候都有效果的
2019-01-041 - 许圣明你好,请问数据重排指的是根据代码中读取各种资源文件的顺序来调整这些文件在目录中的顺序吗?邻近读取的文件存放的位置也要邻近是吗?
作者回复: 对的,对于大量连续读取,文件又比较小的,会比较有用
2018-12-221 - Geek_28d7fe感谢精彩分享,请问app在android5.0以下由于multidex导致启动速度慢如何破,谢谢!
作者回复: 1. 对于dex,不要先解压,然后再压缩 2. dex解压和编译只在单独的进程处理,防止多进程同步 3. 增加loading界面
2019-03-263 - 志伟今天介绍的 “数据重排”相关的优化压榨了系统和硬件的时间,令我想起以前做存储驱动的相关工作。 手机存储的Nand Flash,emmc 等flash存储硬件有其读写的特点或者限制 * 最小读取单位sector ,512byte或其他 * 最小擦出单位为block(如128个sector64k)或其他 * 一个存储单元寿命因芯片质量不同,大概2-3k次 通常做法是增大缓存,做一层逻辑的映射,减少实际读写外部Flash的时间,因为每一次硬件操作成本较大,除了实际的数据传输还有开始握手和结束等待的时间。另外会结合磨损均衡和坏块管理算法,提升读写性能和延长存储的使用寿命。 调整Apk的文件顺序,使其更加紧凑,那内核I/O读取从flash读取回内存的数据在后续读取中更容易命中,减少了I/O时间。 最怕的是随机小文件的读写,因为这样破坏了存储驱动和内核的缓存,要增加很多实际I/O操作,性能很低。 在对比I/O性能时候设备也有差异: * 新设备比旧设备性能好 * 存储剩余大的设备比存储几乎满的设备性能要好 因为旧设备坏块多,存储将满的设备剩余完整好块少,在I/O时候驱动需要调整腾挪数据,找到好的块去写,读时候没有连续读回更多块,降低了缓存的命中,增加了时间。2018-12-2525