Android开发高手课
张绍文
前微信高级工程师，Tinker负责人
立即订阅
12609 人已学习
课程目录
已完结 61 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 焦虑的移动开发者该如何破局？
免费
导读 (1讲)
导读 | 如何打造高质量的应用？
模块一 高质量开发 (25讲)
01 | 崩溃优化（上）：关于“崩溃”那些事儿
02 | 崩溃优化（下）：应用崩溃了，你应该如何去分析？
03 | 内存优化（上）：4GB内存时代，再谈内存优化
04 | 内存优化（下）：内存优化这件事，应该从哪里着手？
05 | 卡顿优化（上）：你要掌握的卡顿分析方法
06 | 卡顿优化（下）：如何监控应用卡顿？
06补充篇 | 卡顿优化：卡顿现场与卡顿分析
07 | 启动优化（上）：从启动过程看启动速度优化
08 | 启动优化（下）：优化启动速度的进阶方法
09 | I/O优化（上）：开发工程师必备的I/O优化知识
10 | I/O优化（中）：不同I/O方式的使用场景是什么？
11 | I/O优化（下）：如何监控线上I/O操作？
12 | 存储优化（上）：常见的数据存储方法有哪些？
13 | 存储优化（中）：如何优化数据存储？
14 | 存储优化（下）：数据库SQLite的使用和优化
15 | 网络优化（上）：移动开发工程师必备的网络优化知识
16 | 网络优化（中）：复杂多变的移动网络该如何优化？
17 | 网络优化（下）：大数据下网络该如何监控？
18 | 耗电优化（上）：从电量优化的演进看耗电分析
19 | 耗电优化（下）：耗电的优化方法与线上监控
20 | UI 优化（上）：UI 渲染的几个关键概念
21 | UI 优化（下）：如何优化 UI 渲染？
22 | 包体积优化（上）：如何减少安装包大小？
23 | 包体积优化（下）：资源优化的进阶实践
24 | 想成为Android高手，你需要先搞定这三个问题
模块二 高效开发 (9讲)
25 | 如何提升组织与个人的研发效能？
26 | 关于编译，你需要了解什么？
27 | 编译插桩的三种方法：AspectJ、ASM、ReDex
28 | 大数据与AI，如何高效地测试？
29 | 从每月到每天，如何给版本发布提速？
30 | 数据评估（上）：如何实现高可用的上报组件？
31 | 数据评估（下）：什么是大数据平台？
32 | 线上疑难问题该如何排查和跟踪？
33 | 做一名有高度的移动开发工程师
模块三 架构演进 (9讲)
34 | 聊聊重构：优秀的架构都是演进而来的
35 | Native Hook 技术，天使还是魔鬼？
36 | 跨平台开发的现状与应用
37 | 移动开发新大陆：工作三年半，移动开发转型手游开发
38 | 移动开发新大陆：Android音视频开发
39 | 移动开发新大陆： 边缘智能计算的趋势
40 | 动态化实践，如何选择适合自己的方案？
41 | 聊聊Flutter，面对层出不穷的新技术该如何跟进？
42 | Android开发高手课学习心得
练习Sample跑起来 (8讲)
练习Sample跑起来 | 热点问题答疑第1期
练习Sample跑起来 | 热点问题答疑第2期
练习Sample跑起来 | 热点问题答疑第3期
练习Sample跑起来 | 热点问题答疑第4期
练习Sample跑起来 | ASM插桩强化练习
练习Sample跑起来 | 唯鹿同学的练习手记 第1辑
练习Sample跑起来 | 唯鹿同学的练习手记 第2辑
练习Sample跑起来 | 唯鹿同学的练习手记 第3辑
特别放送 (7讲)
Android JVM TI机制详解（内含福利彩蛋）
专栏学得苦？可能是方法没找对
专栏学得苦？可能你还需要一份配套学习书单
Native下如何获取调用栈？
聊聊Framework的学习方法
Android工程师的“面试指南”
程序员修炼之路 | 设计能力的提升途径
结束语 (1讲)
结束语 | 移动开发的今天和明天
Android开发高手课
登录|注册
10 | I/O优化（中）：不同I/O方式的使用场景是什么？
张绍文 2019-01-01
今天是 2019 年的第一天，在开始今天的学习前，先要祝你新年快乐、工作顺利。
I/O 是一个非常大的话题，很难一次性将每个细节都讲清楚。对于服务器开发者来说，可以根据需要选择合适的文件系统和磁盘类型，也可以根据需要调整内核参数。但对于移动开发者来说，我们看起来好像做不了什么 I/O 方面的优化？
事实上并不是这样的，启动优化中“数据重排”就是一个例子。如果我们非常清楚文件系统和磁盘的工作机制，就能少走一些弯路，减少应用程序 I/O 引发的问题。
在上一期中，我不止一次的提到 Page Cache 机制，它很大程度上提升了磁盘 I/O 的性能，但是也有可能导致写入数据的丢失。那究竟有哪些 I/O 方式可以选择，又应该如何应用在我们的实际工作中呢？今天我们一起来看看不同 I/O 方式的使用场景。
I/O 的三种方式
请你先在脑海里回想一下上一期提到的 Linux 通用 I/O 架构模型，里面会包括应用程序、文件系统、Page Cache 和磁盘几个部分。细心的同学可能还会发现，在图中的最左侧跟右上方还有 Direct I/O 和 mmap 的这两种 I/O 方式。
那张图似乎有那么一点复杂，下面我为你重新画了一张简图。从图中可以看到标准 I/O、mmap、直接 I/O 这三种 I/O 方式在流程上的差异，接下来我详细讲一下不同 I/O 方式的关键点以及在实际应用中需要注意的地方。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Android开发高手课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(13)
恒老师好，文件IO这一块您讲的非常好，对我的帮助很大，谢谢了2019-01-01 7
廖凡老师好，请教下：
文章提到mmap的可靠性高。但是在内核崩溃、突然断电的情况下也一样有可能引起内容丢失。既然会有丢失，那mmap的可靠性高体现在哪里呢。
xlog和mmkv底层都是通过mmap来实现的，都宣称可以提高可靠性，这里实在不懂，一定要回复啊，困扰我一段时间了。作者回复: 直接写文件，也可能会遇到内核崩溃，突然断电的情况，同样会丢失的，除非采用同步的方式写。
mmap的高可靠性是对比内存而言的2019-07-15 3
董尚斌真值，以前就只知道，写文件，读文件，具体实现的代码，怎么写。现在发现有些情况下的文件读写速度在不同设备上的表现方式的原因。
我做的最多的文件读操作是，全盘扫描本地文件（涉及读文件里面的字节来区分是否符合要求），以及多进程写日志的问题（aidl统一交给主应用的主进程，涉及文件锁和磁盘io频繁的问题）
听了最近的两节，感觉，这些地方可以适当的优化下。
谢谢，老师。2019-01-01 2
SharryBinder 通信的图有些不能理解
进程的用户空间与内核空间是通过 binder_mmap 类似匿名映射的方式分配的, 用户与内核之间是不需要拷贝的
数据的拷贝, 应该在内核空间不同进程的 Binder 缓冲区
不知理解的是否正确, 请老师指教2019-06-20 1
Dimple看了中这部分，已经对I/O有了更深刻的认识，感觉自己学的Android都是皮毛呀2019-03-16 1
星风雪雨mmap，一次拷贝；我的理解是磁盘拷贝到主存，而普通文件是两次拷贝：磁盘-->页缓存-->用户空间，虽然是两次拷贝，但是页缓存-->用户空间是在内存拷贝，虽然多了一次，但是这次是内存操作，应该是很快的；那mmap速度相对读文件快，主要原因是系统调用少引起的吗？2019-11-21
放个屁臭到了自己想请教下，mmap 映射的是用户缓冲区和 page cache 页缓存吗？copy/write 也只需要发生在 page cache 和磁盘？2019-08-31- 廖凡嗯，那mmap可靠仅仅只对用户态缓存的缓存而言的，用户态缓存在app crash就没有了。而mmap是直接操作内核页的，所以app退出了也可以写进文件。2019-07-16
- 廖凡你看我这么理解对不对。mmap的可靠性是相对的文件缓存读写的，并不能彻底解决可靠性问题，事实上哪怕同步写文件方式也不能保证绝对可靠。
mmap的相对文件缓存io，可靠性体现在app异常退出这些场景，比如crash，内存不足被系统强杀等等。这些是文件io读写所不能解决的问题。往大了说，mmap只要操作系统不死，可靠性就能保证。作者回复: 文件io也是系统不死，可靠性也是可以保证的
2019-07-16 
neo好强2019-06-14
Swing很好奇，像微信这样一个权限普通的app，怎么接入的自己的小文件系统（或者说 替换原生的文件系统）？作者回复: 这个小文件系统是应用层的方案，只是把一大堆的小文件组织成一个超大文件。并没有替换原生的文件系统
2019-02-13 1- taotaomami“iowait高，io一定有问题” 这个观点有点异议，借用网上一篇文章对iowait的解释“%iowait 表示在一个采样周期内有百分之几的时间属于以下情况：CPU空闲、并且有仍未完成的I/O请求” iowait这个参数的值对我们观察io活动意义比较小
作者回复: 这里其实想表达的是这段时间的io操作一定会比较高的意思，并不一定能说明代码有问题
2019-01-06 
elephant"微信也开发了一套叫 SFS 的小文件管理系统，主要用在朋友圈图片的管理...."
真的是跪着看微信的技术方案 orz2019-01-02
收起评论