Android数据持久化的设计
title: Android数据持久化
版 本 历 史
| 版本 | 责任人 | 日期 | 备注 |
|---|---|---|---|
| V1.0 | 曾维铭 | 2017-04-12 | 创建文档。 |
1. 数据持久化简介
1.1 数据持久化的需求
- 在网络异常或离线情况下，保证基本功能使用。
- 在有网情况下，更新本地数据，保证数据同步。
- 减少对同一URL的请求次数，甚至只从服务器下载更新过或更改过的资源。节约用户流量，并且也可以减少服务器请求压力。
- 还有确保用户敏感数据的安全。
- 日志持久化，方便跟踪跟踪问题。
- 在线参数的配置
- 不同账户数据隔离
- 数据一键清空
1.2 数据持久化需要关注的问题
- 持久化方案的可维护性和扩展性
- 方案的性能
- 方案设计的效率，对开发人员是否友好
- 不同业务缓存目录的选择，读写规范
- 支持多用户切换，以及多用户切换带来的数据库迁移操作变化
- 敏感信息需要加密
- 持久化数据的安全性
- 文件读写的线程安全，多线程的并发读写的效率和安全性
- 数据库的读写隔离
- 数据库的多线程实现和线程安全
- 数据库的版本升级和数据迁移
- 第三方app清理数据时会清空cache目录缓存的问题
2. 数据持久化方式
2.1 内存缓存
使用LruCache。最近最少使用的数据移除，让出内存给最新读取的数据。
存储的数据类型：
- 网络数据的内存缓存,如图片。
LruCache初始化:
// 获取应用程序最大可用内存
int maxMemory = (int) Runtime.getRuntime().maxMemory();
int cacheSize = maxMemory / 8;
// 设置图片缓存大小为程序最大可用内存的1/8
mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {}
};
总结： 在工具类中实现即可。作为三级缓存的第一级内存缓存。因为不同配置手机为每个应用分配的内存不同，故将内存缓存设为应用最大内存的1/8。
2.2 SharedPreference
使用键值对以xml文件形式存储到手机内存的data/data/package name/shared_prefs目录下。
存储的数据类型：
- 登录信息
- app的简单配置信息（是否第一次进入/字体大小等）：
- 密码、token等需要加密的信息
总结： SharedPreference弱业务、数据量小、不涉及频繁的修改，简单的封装就可以。
2.3 数据库
适合存储一些结构化的数据，这里使用GreenDao创建和操纵数据库。GreenDao是一个将对象映射到SQLite数据库中的轻量且快速的ORM解决方案。可实现快速创建数据库和数据表，并生成对应的实体类和数据访问层。数据库文件会存放在data/data/package name/databases目录下。
存储的数据类型：
- 涉及需要与服务器同步的数据（如与账号对应的消息数据：拉取消息、删除消息同步）
- 复杂的关系型，结构化数据
- 其他频繁修改的业务数据
<font size=4>持久层与业务层的隔离：</font>
01.png
Present层负责业务调度，调用相应模块的Manager接口进行数据操作。Manager层根据各功能模块来划分，统一管理GreenDao的生成类，进行数据操作，并在该类中根据需要实现拓展。
<font size=4>数据库的多线程和线程安全：</font>
- 插入，更新，删除批量的数据库操作时，通过使用GreenDao的事务，保证了数据的原子性
- 为每一个Thread定义一个专属的Query对象，每个Query只能在定义它的线程中使用。通过forCurrentThread()获取当前线程的query。
<font size=4>数据库的版本升级和数据迁移：</font>
- 用GreenDao工具类重新生成新的实体文件。
- 修改DaoMaster.SCHEMA_VERSION 为升级后的数据库版本
- 在DaoMaster.DevOpenHelper的onUpgrade()中，执行数据迁移的方法。（利用临时表的方案）
总结： 需要对GreenDao生成的数据访问层进行简单的封装，使用单例的方式创建一个manager类，对生成的master，DevOpenHelper，session等类进行统一管理和操作，并在该类中提供数据访问的功能扩展。最后根据提供的接口进行数据操作。
2.4 文件存储(File)
适合存储些不需要特殊加工的数据，如一些简单的文本数据或二进制数据。读写需要通过流来实现，需要进行封装和定义自己的格式规范。
内部存储：手机内部存储空间目录/data/data/package name，可设置访问控制权限。在app卸载时会跟着被清除掉。
外部存储：没有严格访问控制权限，外部存储又分为外部私有存储和公有公共存储。可供其他应用访问，公有存储对用户可见。
存储的数据类型：
- 用户Log日志
- 下载的需要缓存的文件
- XML，JSON
- 图片视频
持久化架构：
02.png
线程安全： 为了兼顾性能和线程安全，在对文件操作封装时，应对锁的粒度进行考量，尽量细化加锁粒度。
一键清除功能： 通过用户名和设备两个维度进行文件数据管理，一键清空时只需到对应路径下删除文件即可。
第三方软件/系统清理问题： 当系统或第三方软件清理时，会清理掉cache目录下的缓存文件。而file目录下的不会被清理。因此不希望被清理的文件应该放到file目录下。
设备碎片化问题： 市面上部分手机取消了可拆卸的SD卡，直接与机身焊接在一起。虽然这部分手机不存在SD卡，但是在Android系统中，依然有分内部存储和外部存储。使用的方式依然不变。
总结: 文件读写需要通过IO流的方式，需要进行封装。封装时需要考虑将业务与读写操作隔离开。
2.5 ContentProvider
提供应用程序共享数据的数据存储方式，以数据表格的方式实现应用程序之间数据共享。
存储的数据类型：
- 需要给其他应用使用的数据
2.6 DiskLruCache
Google官方认证的硬盘缓存的解决方案,使用LRU算法。
存储的数据类型：
- 需要进行磁盘缓存的数据
总结: 用几个方法在工具类实现即可，与LruCache结合，实现三级缓存中的硬盘缓存。
3. 数据安全性问题：
Android系统本身有对文件访问的控制，保证内部存储中的文件不能被其他应用所访问。然而在root情况下，文件访问控制机制失效，所以需要对关键数据进行加密存储。
4. 内部存储目录结构：
内部存储的数据拥有访问控制权限，无法被用户和其他程序直接查看和修改，用以存放一些对外不可见的数据，具体使用情况需要视业务而定。
|--shared_prefs
|--databases
|--cache
|--files
|--app
|--app_crashrecord
|--download
|--user
|--guest
|--userA
|--userB
|--image
|--voice
|--device
|--deviceA
|--deviceB
shared_prefs: SharedPreference。
databases: 数据库数据。
cache： 图片加载的缓存目录，存放一些不重要的数据，通过getCacheDir()访问到。如果手机的内部存储空间不足，系统会自行选择cache目录进行删除。Glide图片加载框架默认缓存该路径，无法修改。该目录系统会进行管理，暂时不考虑进行细分。
files： 本地文件存储，通过getFileDir()访问。
app: 整个app的相关文件，例如是否第一次安装；deviceId等配置。
app_crashrecord: 存放crash记录文件。文件不大，且内容需要一定保密性，放在内部存储中。
download: app文件下载目录，包含断点下载内容，具体的内容视业务而定。
user： 按用户来隔离，以账号作为标识，该目录下存储一些与用户相关的数据。
image/voice: 为了保证用户间数据隔离，以用户作为划分。
device： 按设备来隔离，以每个设备的MAC地址为标识。MAC地址存在数据库中，通过user_table获取。一般存储一些与设备相关的数据(如设备固件之类)。
5. 外部存储目录结构
通过Environment.getExternalStorageDirectory()获取外部公共存储根目录。
|--PhiComm
|--appA
|--appB
|--logs
|--download
|--banner
|--device
|--deviceA
|--deviceB
|--user
|--userA
|--userB
|--image
|--voice
|--video
logs: 存放app日志。
banner: 广告文件。
device: 设备文件，如设备信息，设备固件等。
image: 图片。
voice: 音频文件。
video: 视频文件.
针对存在内部存储和外部存储有相同文件夹（如image，download等），需要在底层封装时，根据内外存储的特性区分清楚。上层业务只需根据具体业务情况，使用提供的API进行文件操作，不能自行在业务层进行文件操作，以此避免不同开发人员进行文件操作产生的混乱。
