移动互联网实战--资源类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手机的硬件和存储方式有所了解, 这样才能合理的设计和优化.

 

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

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。