移动互联网实战--资源类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手机的硬件和存储方式有所了解, 这样才能合理的设计和优化.
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。