移动互联网实战--资源类APP的数据存储处理和优化

前言:
　　对于资源类的APP, 其音频/图形占据了APP本身很大的比例. 如何存储和管理这些资源文件, 成了一个颇具挑战性的难点. 移动端的碎片化, 高中低端手机的并存, 需要开发者不光是具备基础的存储知识, 更需要基本优化的能力. 本文首先介绍手机硬件的基础, 后续会分别介绍存储方式, 资源打包, 最后以一个具体例子作结. 内容还是浅显, 望能抛砖引玉.

*) 硬件基础
　　作为手机开发者人员, 你是否知道RAM/ROM/存储卡的区别? 而产商所宣传的运行内存, 机身内存又是什么?
1). RAM/ROM/存储卡
　　RAM (Random Access Memory): 随机存取存储器, 相当于PC电脑的内存, 掉电数据会失去.
　　ROM (Read Only Memory): 手机端的ROM不在限定于只读了, 事实上它包含三部分, 操作系统/系统软件/用户自由空间, 相当于PC电脑的硬盘
　　存储卡: 是对RAM/ROM之外的存储扩展, 可以理解为PC电脑的移动硬盘/U盘
2). 产商所宣传的运行内存, 机身内存的概念详解
　　运行内存: 运行内存就是RAM
　　机身内存: ROM + 内置存储卡, 一般市面上移动端的16G/32G内存, 都是ROM+内置存储卡的组合
以小编拥有的联想VIBE Z K910手机为例



其具体的参数如下:

机身内存	16GB ROM
运行内存	2GB RAM

评注:
　　产商一般使用1G=1000M, 而检测软件使用1G=1024M的单位, 因此实际用户能看到的数值小于产商所宣传的.
　　该机型不能扩展外置SDCard, 但APP却能使用ExternalStorage来存放资源数据, 也从另一个侧面佐证了机身内存(ROM + 内置存储卡)的事实.

*) 存储方式

　　在Android系统中, 数据的存储方式有如下四种: SharedPreference, SQLite, ContentProvider, File. 它们对应的目录以及存储介质各有不同, 现在小编一一道来.
　　


　　注: 此父路径为data/data, 此以豌豆荚的app的包名com.wandoujia.phoenix2目录为例, 其下包含shared_prefs/databases/files/caches,其属于ROM(用户空间)中.
1). SharedPreference
　　SharedPreference是一种轻型的数据存储方式, 它的本质是基于XML文件存储Key/Value的键值对数据.通常用来存储一些简单的配置信息.其配置位置在/data/data/<包名>/shared_prefs目录下.
2). SQLite
　　SQLite是一种轻量级的嵌入式数据库,以SQL形式组织和访问数据的方式总是给开发者更多的便利性.其数据的存储在data/data/<包名>/databases目录下.
3). ContentProvider
　　ContentProvider是Android平台中,在不同应用程序之间实现数据共享的一种机制. 一个应用程序如果需要让别的程序可以操作自己的数据, 即可采用这种机制. 该种方式忽略了底层的数据存储实现.
4). File

　　File是最简单的方式, 不过需要开发者自己去维护, 不同的存储介质/文件类型, 读取的方式不同.
　　#) 资源文件

RAW类型:
Context.getResource().openRawResource(R.raw.<id>);
Asset类型:
Context.getResource().getAssets().open(<filename>);

　　注: 该目录的文件大小不能超过1M.
　　#) 数据区(/data/data/<包名>/files)
　　其对文件的存取有特定的限制, 必须通过特定的api来访问

Context.openFileInput()
Context.openFileOutput()

　　#) SDCard文件
　　需要指定sdcard路径以及访问权限

Environment.getExternalStorageDirectory()
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

*) Apk的目录划分/安裝过程
　　Android应用有两个目录: assets目录和res目录(以资源id的方式访问). 对于res/drawable, res/string, res/layout大家耳熟能详. 这边具体讲讲assets和res/raw的作用和区别. 当然res/xml也特殊目录, 其用于存储相关的xml文件.
　　assets Vs res/raw

	二进制	支持目录	访问方式	文件格式限制
assets	不编译成二进制	任意深度的目录	以文件方式访问	除音频/图像文件外, 其他格式的文件需要压缩
res/raw	不编译成二进制	不支持子目录	以资源id的方式访问	没有这个限制

　　Apk安装流程可以描述如下:
　　1). Apk本身会复制到/data/app下
　　2). Apk解压后的classes.dex复制到/data/dalvik-cache
　　3). 在/data/data/<包名>/下, 创建cache/databases/files用于存储程序的应用数据
　　注: 安装过程中, 资源文件(来自于res, assets)依旧存在apk包中, 当访问时是从apk包里读取出数据来.

*) 应用实例
　　以一个资源类App语音电子书为例, 该App包含了大量的语音/图像资源. 当前所面临的难点在于:
　　1). 如何存储这些资源?
　　2). 如何去整理和组织这些资源?
　　语音电子书应用, 有多本书构成, 为了有效管理, 需要按电子书来划分. 因此选用apk的assets来存储电子书资源, 另一方面, 每本电子书包含了大量的音频/图像文件, 因此按书对资源文件进行压缩打成zip包.

assets/book1.zip
assets/book2.zip
assets/book3.zip
...

　　而具体每本电子书的资源组织如下:

book.zip
|-----------> images　　　　　　// 图像文件
|-----------> musics　　　　　　// 声音文件
|-----------> desc.xml	// 用于描述图像和声音文件之间的关系

　　Apk安装之后, 应用就从asset把zip包解压到sdcard中, 这样就能借用sdcard的大存储空间了.
　　这边还有个问题, 就是电子书的元信息以及书架信息, 怎么维护呢?
　　我们可以编辑一个xml文件去描述所以书籍的元信息, 同时维护书架信息, 然后把它搁置于apk的res/xml(华丽登场)中.

<books>
　　<book>
　　　　<name>致我们终将逝去的青春</name>
　　　　<author>辛夷坞</author>
　　　　<file>book1.zip</file>
　　</book>
　　...
<books>

　　这样整个资源类App,就这样合理的组织起来了.

总结:
　　要编写好好的资源类app, 就需要对Android手机的硬件和存储方式有所了解, 这样才能合理的设计和优化.