Mobile Internet combat--data storage processing and optimization of resource-type app

Objective:
For resource class apps, the audio/graphics occupy a large proportion of the app itself. How to store and manage these resource files has become a challenging challenge. The fragmentation of mobile, the coexistence of high school low-end mobile phones, the need for developers is not only basic storage knowledge, but also need basic optimization capabilities. This paper first introduces the basics of mobile phone hardware, the following will introduce the storage method, resource packaging, and finally a concrete example to knot. Content or superficial, hope can be a point.

*) Hardware Basics
As a developer of mobile phone, do you know the difference between ram/rom/memory cards? What is the running memory that the producers advertise and what is the body memory?
1). ram/rom/Memory Card
RAM: Random access memory, which is equivalent to the memory of a PC, loses power.
Rom (read only Memory): The ROM on the phone is not limited to read-only, in fact it contains three parts, operating system/system software/user free space, the equivalent of a PC computer hard disk
Memory card: is a storage extension outside of Ram/rom, can be understood as a PC's mobile HDD/u disk
2). The concept of running memory and body memory advertised by the producers
Running memory: Running memory is RAM
Body Memory: ROM + Internal storage card, the general market on the mobile side of the 16g/32g memory, are rom+ built-in memory card combination
A case study of Lenovo Vibe Z K910 mobile phone with small series

The specific parameters are as follows:

Body memory 16GB ROM running memory 2GB RAM

Commentary:
Manufacturers generally use 1g=1000m, while the detection software uses 1g=1024m units, so the actual user can see the value is less than the propaganda of the producers.
The model does not extend the external sdcard, but the app can use Externalstorage to store resource data and the fact that the body's memory (ROM + built-in storage card) is supported from another side.

*) Storage mode

In Android, data is stored in the following four ways: Sharedpreference, SQLite, ContentProvider, File. They correspond to the directory and storage media are different, now small series one by one.
　　
Note: This parent path is Data/data, which is an example of the package name com.wandoujia.phoenix2 directory of the Pea Pod app, which contains Shared_prefs/databases/files/caches, which belongs to ROM (user space).
1). sharedpreference
Sharedpreference is a lightweight method of data storage, and its essence is to store Key/value key-value pairs of data based on XML files. Typically used to store some simple configuration information. Its configuration location is in the /data/data/< package name >/ The Shared_prefs directory.
2). SQLite
SQLite is a lightweight, embedded database that organizes and accesses data in SQL in a way that is always more convenient for developers. The data is stored in the data/data/< package name >/databases directory.
3). ContentProvider
ContentProvider is a mechanism for data sharing among different applications in the Android platform. An application can use this mechanism if it needs to allow other programs to manipulate its own data. This approach ignores the underlying data storage implementations.
4). File

File is the simplest way, but needs to be maintained by the developer themselves, different storage media/file types, read in different ways.
#) resource file

Raw type: Context.getresource (). Openrawresource (r.raw.<id>); Asset Type: Context.getresource (). Getassets (). open (<filename>);

Note: The file size of this directory cannot exceed 1M.
#) Data area (/data/data/< package name >/files)
It has specific restrictions on file access and must be accessed through a specific API

Context.openfileinput () Context.openfileoutput ()

#) sdcard file
You need to specify the SDcard path and access permissions

*) APK directory partition/install process
Android apps have two directories: the assets directory and the Res directory (accessed as resource ID). For Res/drawable, res/string, res/layout all familiar. Here is the specific talk about the role and difference between assets and Res/raw. Of course Res/xml is also a special directory, which is used to store related XML files.
　　Assets Vs Res/raw

	Binary	Support Directory	Access mode	File Format Restrictions
Assets	Do not compile into binary	Directories of any depth	Access by file	In addition to audio/image files, files in other formats need to be compressed
Res/raw	Do not compile into binary	Sub-directories are not supported	Access as resource ID	There's no such limit.

The APK installation process can be described as follows:
1). The apk itself will be copied to/data/app
2). apk extracted Classes.dex copied to/data/dalvik-cache
3). Under/data/data/< package name >/, create cache/databases/files application data for the stored program
　　Note: During the installation process, the resource file (from res, assets) still exists in the APK package, and when accessed is read out from the APK package.

*) Application examples
As an example of a resource-class app voice book, the app contains a lot of voice/image resources. The current challenges are:
　　1). How do I store these resources?
　　2). How do I organize and organize these resources?
Voice e-book applications, there are many books, in order to effectively manage, need to be divided by e-book. So choose APK assets to store e-book resources, on the other hand, each ebook contains a large number of audio/image files, so the book on the resource files compressed into a ZIP package.

Assets/book1.zipassets/book2.zipassets/book3.zip ...

The resources for each ebook are organized as follows:

Book.zip  |-----------> Images//image file  |-----------> musics//sound file  |-----------> desc.xml// Used to describe the relationship between an image and a sound file

After the APK is installed, the app extracts the ZIP packet from the asset into the sdcard so that it can borrow SDcard's large storage space.
Here is another question, is the e-book meta-Information and bookshelf information, how to maintain it?
We can edit an XML file to describe the meta-information of the book, while maintaining the bookshelf information, and then put it on the APK's res/xml(gorgeous debut).

<books> <book> <name> The youth we will die </name> <author> <file>book </author> 1.zip</file> </book> ...<books>

So the entire resource class app, it is so reasonable to organize up.

Summarize:
To write a good resource class app, you need to understand the hardware and storage of your Android phone so that you can design and optimize it properly.