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开发高手课
登录|注册
12 | 存储优化（上）：常见的数据存储方法有哪些？
张绍文 2019-01-08
通过专栏前面我讲的 I/O 优化基础知识，相信你肯定了解了文件系统和磁盘的一些机制，以及不同 I/O 方式的使用场景以及优缺点，并且可以掌握如何在线上监控 I/O 操作。
万丈高楼平地起，在理解并掌握这些基础知识的同时，你肯定还想知道如何利用这些知识指导我们写出更好的代码。
今天我来结合 Android 系统的一些特性，讲讲开发过程中常见存储方法的优缺点，希望可以帮你在日常工作中如何做出更好的选择。
Android 的存储基础
在讲具体的存储方法之前，我们应该对 Android 系统存储相关的一些基础知识有所了解。
1. Android 分区
I/O 优化中讲到的大部分知识更侧重 Linux 系统，对于 Android 来说，我们首先应该对 Android 分区的架构和作用有所了解。在我们熟悉的 Windows 世界中，我们一般都把系统安装在 C 盘，然后还会有几个用来存放应用程序和数据的分区。
Android 系统可以通过 /proc/partitions 或者 df 命令来查看的各个分区情况，下图是 Nexus 6 中 df 命令的运行结果。
什么是分区呢？分区简单来说就是将设备中的存储划分为一些互不重叠的部分，每个部分都可以单独格式化，用作不同的目的。这样系统就可以灵活的针对单独分区做不同的操作，例如在系统还原（recovery）过程，我们不希望会影响到用户存储的数据。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Android开发高手课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(8)
李杰老师您好!
最近正打算利用MMKV替换SharedPreferences，研读了一下MMKV的源代码，发现他们在内存重组的时候是直接在原始文件中写重组过后的数据，并且重组完成之后没有sync, 感觉这样会有很大的风险。虽说mmap利用操作系统的机制来保证即使进程被杀，也能写数据, 但首先得保证把所有要写的数据写进mmap映射的内存中，如果在写完成之前进程就已经被杀了，那就有可能出现mmap中的数据是错误的，即使完成了写mmap内存，如果在操作系统将数据写入硬盘前突然关机，那也有可能丢失数据，造成最终的数据损坏。
而SharedPreferences的写操作，首先是将原始文件备份，再写入所有数据，只有写入成功了，并且通过sync完成落盘后，才会将Backup文件删除。如果在写入过程中进程被杀，或者关机，进程再次起来的时候发现存在Backup文件，就将Backup文件重命名为原始文件，原本未完成写入的文件就直接丢弃来，这样最多也就是未完成写入的数据丢失，文件是不会损坏的，所以可以认为SharedPreferences的写入在单进程中是安全的，也正是因为back的机制，导致多进程可能会丢失新写入的数据。
从MMKV的github上看到数据有效性的说明，在ios每天存在超过70万次的数据校验失败，是不是就是写数据实际是不安全的导致的呢？对MMKV和SharedPreferences的理解可能不对，请老师帮忙解答一下，谢谢！作者回复: 赞，研究的挺细的，大部分都对。不过mmkv有考虑这点做了crc检验，文件损坏之后支持recover模式，从文件中尽力而为的修复数据
2019-01-08 24- 李杰老师您好!
针对mmkv的recover模式，也正是我们担心的一个点。从mmkv源码来看，在crc校验失败后默认选择丢弃数据。recover模式作为一个可选模式，也没有看到有什么恢复数据的措施，只是仍然强行decode数据，这样的话理论上decode出来的数据就可能是错误的，不知道是不是哪里疏漏了或是理解有问题。作者回复: 因为用了pb的结构已经二进制了，如果某一行写出问题，应该是decode失败的。
不过这里可能的确有优化的空间，可能文件头上面可以记住上一次检验成功的行数。2019-01-08 2 
书虫老师，当应用收到系统广播，或者被调用 onPause 等一些时机，系统会强制把所有的 SharedPreferences 对象数据落地到磁盘，这说法依据的在哪里？作者回复: 可以看看源码，ActivityThread
2019-02-26 1
薯条打卡，一直以来，想用probuff作为数据传输，可是原生的操作有点麻烦，有幸得知mmkv库，收获2019-10-05- 薯条打卡，在职业生涯中，的确遇到Sh 保存数据 卡顿的问题。以后尽量使用MMKV框架2019-10-05
大土豆之前看专栏的时候，这个部分跳过了，结果我负责的App出现了严重的卡顿卡顿，BlockCanery查了半天，发现是sp的锅，性能差倒是其次，关键是Activity的生命周期中需要处理sp的任务，造成了很严重的卡顿，我的思路是一部分不需要持久化的数据改成内存缓存，还有一部分需要持久化的数据改成mmkv2019-05-04 1
HI谢谢，长见识了2019-01-14
东方张老师，今天跑了mmkv的demo，发现文件内容是append形式，不会覆盖前面的key，导致文件内容越来越大。作者回复: 在达到一定大小的时候会做自动合并，这块可以看看源码的介绍
2019-01-10 1
收起评论