2018-12-25今天介绍的 “数据重排”相关的优化压榨了系统和硬件的时间，令我想起以前做存储驱动的相关工作。
手机存储的Nand Flash,emmc 等flash存储硬件有其读写的特点或者限制
* 最小读取单位sector ，512byte或其他
* 最小擦出单位为block(如128个sector64k)或其他
* 一个存储单元寿命因芯片质量不同，大概2-3k次
通常做法是增大缓存，做一层逻辑的映射，减少实际读写外部Flash的时间，因为每一次硬件操作成本较大，除了实际的数据传输还有开始握手和结束等待的时间。另外会结合磨损均衡和坏块管理算法，提升读写性能和延长存储的使用寿命。
调整Apk的文件顺序，使其更加紧凑，那内核I/O读取从flash读取回内存的数据在后续读取中更容易命中，减少了I/O时间。
最怕的是随机小文件的读写，因为这样破坏了存储驱动和内核的缓存，要增加很多实际I/O操作,性能很低。
在对比I/O性能时候设备也有差异:
* 新设备比旧设备性能好
* 存储剩余大的设备比存储几乎满的设备性能要好
因为旧设备坏块多，存储将满的设备剩余完整好块少，在I/O时候驱动需要调整腾挪数据，找到好的块去写，读时候没有连续读回更多块，降低了缓存的命中，增加了时间。展开 11
2018-12-23您上面说，Buffer不小心写成了 1 byte，总共要读取 1000次，这样会命中Page Cache中不会导致真正的IO。可是实际测试的时候，read同一个文件，buffer大小1byte和1k的read速度还有有差异的，这个是为什么呢？作者回复: 后面io会讲到。主要差别是系统调用跟数据拷贝的时间
3
2019-09-02请教一个问题，一定要回答啊，困扰了很久。
我们在使用tinker过程中，线上运行性能下降。
不光是app启动性能，整个app的运行生命周期都会下降，
tinker不应该只影响启动性能吗，为什么整个app的生命周期都有影响呢。
tinker也没有做全局插桩，是和您本文所说的，黑科技导致Android runtime的性能优化无法生效到有关系吗？作者回复: 1. 类的查找路径变长了
2. 系统base.art的那一套失效了
3. 8.0之后只能解释执行了 1 2
2019-12-01请问下怎么样去复写 ClassLoader，获取类的加载作者回复: 可以参考一下tinker的写法
1
2019-07-26重排顺序的依据是什么，是按照文件大小从小到大以此排序，这样一次磁盘读取可以尽可能多的读文件；还是要综合文件大小、文件读取次数、启动过程是否加载这些因素（这几个因素中哪个权重会大一些），进行文件排序。看过文章后觉得应该是第二种，因为老师有讲到统计、度量这些措施。另外，觉得老师应该就010 Editor查看效果简单介绍一下作者回复: 重排的目的是首次读取的时候减少缺页，那肯定是按照程序的读取顺序来排序的
1
2018-12-25对于dex中的class按文件大小重排没有明白为什么为优化i/o速度，class的加载和在dex的位置有什么关系？作者回复: Classdef在dex是连续存放的，所以可以一次读取一大段，mmap中断缺页就会少一些
1
2018-12-22感谢分享，启动这块的线上监控似乎没有崩溃卡顿内存这几个完整，实验室环境居多。我们最近也在尝试做一些线上启动完整过程的函数级微损监控，另外还有启动这块的代码框架似乎也可以写一些。 1
2020-01-19请问 ART虚拟机 都有什么科技借鉴的优化方案，在其他资料里还看到关于cpu Turbo的方案，请问具体是怎么做的
2019-09-29那个实验室监控在哪里
2019-05-24给了大厂优化的思路，继续理论高大
2019-03-26感谢精彩分享，请问app在android5.0以下由于multidex导致启动速度慢如何破，谢谢！作者回复: 1. 对于dex，不要先解压，然后再压缩
2. dex解压和编译只在单独的进程处理，防止多进程同步
3. 增加loading界面
2019-01-31感觉又迂回到文件系统了。。。基础不好，心塞作者回复: 一步一步来
2019-01-04优化Dex上文件的重排，是只会在首次安装或者覆盖安装上涉及到吗，其他情况呢?作者回复: Dex重排是任何时候都有效果的
2018-12-22你好，请问数据重排指的是根据代码中读取各种资源文件的顺序来调整这些文件在目录中的顺序吗？邻近读取的文件存放的位置也要邻近是吗？作者回复: 对的，对于大量连续读取，文件又比较小的，会比较有用