Android MediaProvider数据库模式(二):ICS的更改
简介:
本文介绍 Android 4.0 (ICS) 相对于 2.3 的修改,在之前说过的内容这里不再赘述,要了解详情请到介绍 2.3 的文章:Android MediaProvider数据库模式
Android 4.0 相对于 2.3 数据库改动较大,主要是为了加入 MTP 文件传输模式的支持而做的修改:
- 原本只有多媒体文件(音乐/视频/图片)才会保存进数据库,现在所有文件均会保存进叫 files 的表,只是非多媒体文件不用分析(如分析专辑名等)。
- 相应地,原来的音乐、视频、图片的表变成了视图,是从 files 表生成的。其他辅助表例如专辑封面、艺术家、缩略图的表保持不变。
- MTP 文件传输模式下读取的文件,就是 files 表中存在的文件,若文件没有保存进 files 表则不会显示。
- 为了使 MTP 模式下手机端删除文件时能通知到主机,在数据库中加入了一个触发器 files_cleanup,里面使用了一个 SQLite 自定义函数来发送通知。只要删除 files 表就会发送通知。
虽然做了若干修改,但上层应用访问数据库完全不受影响,可以不用关心。但媒体文件扫描速度会变慢,因为写入数据库操作占用了扫描的大部分时间,而现在需要写入的文件大幅度增加。
Android MediaProvider数据库模式(一):
摘要: Android MediaProvider 使用 SQLite 数据库存储图片、视频、音频等多媒体文件的信息,供视频播放器、音乐播放器、图库使用。本文详细分析了 Android MediaProvider 多媒体数据库(以 SDK 2.3.3 为例)的模式(schema),并简要叙述与系统媒体扫描服务 MediaScanner 的交互。
1. 如何提取数据库
以 root 权限进入 adb shell,使用 sqlite3 打开位于手机上 /data/data/com.android.providers.media/databases 上的一个数据库。以 external 开头的数据库存储的是 SD 卡媒体信息,一张卡对应一个,所以如果手机使用过多张卡会有多个数据库。以 internal 开头的数据库存储手机内部存储器的媒体信息。因为一般用户无法访问手机内部存储器,而且这两个数据库结构是大体上是相同的,所以只需要关注 external 数据库即可。
Note: 数据库都是以类似 external-ffffffff.db 的形式命名的, 后面的 8 个 16 进制字符是该 SD 卡 FAT 分区的 Volume ID。该 ID 是分区时决定的,只有重新分区或者手动改变才会更改,可以防止插入不同 SD 卡时数据库冲突。要简单了解 FAT 文件系统请看 Understanding FAT Filesystems
接着在 sqlite3 执行命令 .schema 即可导出创建数据库的 SQL 语句,也就是数据库模式,具体如下(单击展开代码):
1 |
CREATE TABLE album_art (album_id INTEGER PRIMARY KEY ,_data TEXT); |
2 |
CREATE TABLE albums (album_id INTEGER PRIMARY KEY ,album_key TEXT NOT NULL UNIQUE ,album TEXT NOT NULL ); |
3 |
CREATE TABLE android_metadata (locale TEXT); |
4 |
CREATE TABLE artists (artist_id INTEGER PRIMARY KEY ,artist_key TEXT NOT NULL UNIQUE ,artist TEXT NOT NULL ); |
5 |
CREATE TABLE audio_genres (_id INTEGER PRIMARY KEY , name TEXT NOT NULL ); |
6 |
CREATE TABLE audio_genres_map (_id INTEGER PRIMARY KEY ,audio_id INTEGER NOT NULL ,genre_id INTEGER NOT NULL ); |
7 |
CREATE TABLE audio_meta (_id INTEGER PRIMARY KEY ,_data TEXT UNIQUE NOT NULL ,_display_name TEXT,_size INTEGER ,mime_type TEXT,date_added INTEGER ,date_modified INTEGER ,title TEXT NOT NULL ,title_key TEXT NOT NULL ,duration INTEGER ,artist_id INTEGER ,composer TEXT,album_id INTEGER ,track INTEGER , year INTEGER CHECK ( year !=0),is_ringtone INTEGER ,is_music INTEGER ,is_alarm INTEGER ,is_notification INTEGER , is_podcast INTEGER , bookmark INTEGER ); |
8 |
CREATE TABLE audio_playlists (_id INTEGER PRIMARY KEY ,_data TEXT, name TEXT NOT NULL ,date_added INTEGER ,date_modified INTEGER ); |
9 |
CREATE TABLE audio_playlists_map (_id INTEGER PRIMARY KEY ,audio_id INTEGER NOT NULL ,playlist_id INTEGER NOT NULL ,play_order INTEGER NOT NULL ); |
10 |
CREATE TABLE images (_id INTEGER PRIMARY KEY ,_data TEXT,_size INTEGER ,_display_name TEXT,mime_type TEXT,title TEXT,date_added INTEGER ,date_modified INTEGER ,description TEXT,picasa_id TEXT,isprivate INTEGER ,latitude DOUBLE ,longitude DOUBLE ,datetaken INTEGER ,orientation INTEGER ,mini_thumb_magic INTEGER ,bucket_id TEXT,bucket_display_name TEXT); |
11 |
CREATE TABLE thumbnails (_id INTEGER PRIMARY KEY ,_data TEXT,image_id INTEGER ,kind INTEGER ,width INTEGER ,height INTEGER ); |
12 |
CREATE TABLE video (_id INTEGER PRIMARY KEY ,_data TEXT NOT NULL ,_display_name TEXT,_size INTEGER ,mime_type TEXT,date_added INTEGER ,date_modified INTEGER ,title TEXT,duration INTEGER ,artist TEXT,album TEXT,resolution TEXT,description TEXT,isprivate INTEGER ,tags TEXT,category TEXT,language TEXT,mini_thumb_data TEXT,latitude DOUBLE ,longitude DOUBLE ,datetaken INTEGER ,mini_thumb_magic INTEGER , bucket_id TEXT, bucket_display_name TEXT, bookmark INTEGER ); |
13 |
CREATE TABLE videothumbnails (_id INTEGER PRIMARY KEY ,_data TEXT,video_id INTEGER ,kind INTEGER ,width INTEGER ,height INTEGER ); |
15 |
CREATE VIEW album_info AS SELECT audio.album_id AS _id, album, album_key, MIN ( year ) AS minyear, MAX ( year ) AS maxyear, artist, artist_id, artist_key, count (*) AS numsongs,album_art._data AS album_art FROM audio LEFT OUTER JOIN album_art ON audio.album_id=album_art.album_id WHERE is_music=1 GROUP BY audio.album_id; |
16 |
CREATE VIEW artist_info AS SELECT artist_id AS _id, artist, artist_key, COUNT ( DISTINCT album_key) AS number_of_albums, COUNT (*) AS number_of_tracks FROM audio WHERE is_music=1 GROUP BY artist_key; |
17 |
CREATE VIEW artists_albums_map AS SELECT DISTINCT artist_id, album_id FROM audio_meta; |
18 |
CREATE VIEW audio as SELECT * FROM audio_meta LEFT OUTER JOIN artists ON audio_meta.artist_id=artists.artist_id LEFT OUTER JOIN albums ON audio_meta.album_id=albums.album_id; |
19 |
CREATE VIEW search AS SELECT _id, 'artist' AS mime_type,artist, NULL AS album, NULL AS title,artist AS text1, NULL AS text2,number_of_albums AS data1,number_of_tracks AS data2,artist_key AS match, 'content://media/external/audio/artists/' ||_id AS suggest_intent_data,1 AS grouporder FROM artist_info WHERE (artist!= '<unknown>' ) UNION ALL SELECT _id, 'album' AS mime_type,artist,album, NULL AS title,album AS text1,artist AS text2, NULL AS data1, NULL AS data2,artist_key|| ' ' ||album_key AS match, 'content://media/external/audio/albums/' ||_id AS suggest_intent_data,2 AS grouporder FROM album_info WHERE (album!= '<unknown>' ) UNION ALL SELECT searchhelpertitle._id AS _id,mime_type,artist,album,title,title AS text1,artist AS text2, NULL AS data1, NULL AS data2,artist_key|| ' ' ||album_key|| ' ' ||title_key AS match, 'content://media/external/audio/media/' ||searchhelpertitle._id AS suggest_intent_data,3 AS grouporder FROM searchhelpertitle WHERE (title != '' ); |
20 |
CREATE VIEW searchhelpertitle AS SELECT * FROM audio ORDER BY title_key; |
22 |
CREATE INDEX album_id_idx on audio_meta(album_id); |
23 |
CREATE INDEX album_idx on albums(album); |
24 |
CREATE INDEX albumkey_index on albums(album_key); |
25 |
CREATE INDEX artist_id_idx on audio_meta(artist_id); |
26 |
CREATE INDEX artist_idx on artists(artist); |
27 |
CREATE INDEX artistkey_index on artists(artist_key); |
28 |
CREATE INDEX image_bucket_index ON images(bucket_id, datetaken); |
29 |
CREATE INDEX image_id_index on thumbnails(image_id); |
30 |
CREATE INDEX sort_index on images(datetaken ASC , _id ASC ); |
31 |
CREATE INDEX title_idx on audio_meta(title); |
32 |
CREATE INDEX titlekey_index on audio_meta(title_key); |
33 |
CREATE INDEX video_bucket_index ON video(bucket_id, datetaken); |
34 |
CREATE INDEX video_id_index on videothumbnails(video_id); |
36 |
CREATE TRIGGER albumart_cleanup1 DELETE ON albums BEGIN DELETE FROM album_art WHERE album_id = old.album_id; END ; |
37 |
CREATE TRIGGER albumart_cleanup2 DELETE ON album_art BEGIN SELECT _DELETE_FILE(old._data); END ; |
38 |
CREATE TRIGGER audio_delete INSTEAD OF DELETE ON audio BEGIN DELETE from audio_meta where _id=old._id; DELETE from audio_playlists_map where audio_id=old._id; DELETE from audio_genres_map where audio_id=old._id; END ; |
39 |
CREATE TRIGGER audio_genres_cleanup DELETE ON audio_genres BEGIN DELETE FROM audio_genres_map WHERE genre_id = old._id; END ; |
40 |
CREATE TRIGGER audio_meta_cleanup DELETE ON audio_meta BEGIN DELETE FROM audio_genres_map WHERE audio_id = old._id; DELETE FROM audio_playlists_map WHERE audio_id = old._id; END ; |
41 |
CREATE TRIGGER audio_playlists_cleanup DELETE ON audio_playlists BEGIN DELETE FROM audio_playlists_map WHERE playlist_id = old._id; SELECT _DELETE_FILE(old._data); END ; |
42 |
CREATE TRIGGER images_cleanup DELETE ON images BEGIN DELETE FROM thumbnails WHERE image_id = old._id; SELECT _DELETE_FILE(old._data); END ; |
43 |
CREATE TRIGGER thumbnails_cleanup DELETE ON thumbnails BEGIN SELECT _DELETE_FILE(old._data); END ; |
44 |
CREATE TRIGGER video_cleanup DELETE ON video BEGIN SELECT _DELETE_FILE(old._data); END ; |
45 |
CREATE TRIGGER videothumbnails_cleanup DELETE ON videothumbnails BEGIN SELECT _DELETE_FILE(old._data); END ; |
Note: 如果手机没有 sqlite3 程序,可以搜索编译过的源代码的 out 目录找到可执行文件,大约 90kb,然后 adb push 到手机的 /system/bin/ 目录。安装 sqlite3、查询数据库均需要 adb root 权限。 Android 的多媒体数据库主要由表、视图、索引以及触发器组成。
接着还需要把数据库转换成图,手工转换的话就是根据 SQL 语句自行画图;推荐懒人使用自动转换,先使用 adb pull 把数据库导出,再使用 Power Designer 或者 Visio 的逆向工程(Reverse Engineer)功能生成物理数据模型(Physical Data Model)。注意要连接 sqlite 数据库文件的话需要先安装 sqlite 的 ODBC 驱动,教程在这里:SQLite ODBC Driver
2. 数据库模式分析
图片数据库
图片数据库由两个表组成,分别是 images 和 thumbnails,物理数据模型如下所示(Power Designer 逆向工程生成)
Note: 如何数据库物理模型图:<pk> 表示此为主键。其余的表名、字段名、数据类型应该都能看明白。
Note: SQLite 从 3.6.19 版才开始支持外键约束,Android 2.3.3 使用的是 3.7.x,但并没有使用此特性,而是通过操作数据库的程序(如 MediaScanner)以及触发器来维护数据库的一致性。这里可以了解 SQLite 的外键支持情况
数据表字段解析如下:
images:图片信息
字段 解析
_id |
主键。图片 id,从 1 开始自增 |
_data |
图片绝对路径 |
_size |
文件大小,单位为 byte |
_display_name |
文件名 |
mime_type |
类似于 image/jpeg 的 MIME 类型 |
title |
不带扩展名的文件名 |
date_added |
添加到数据库的时间,单位秒 |
date_modified |
文件最后修改时间,单位秒 |
description |
|
picasa_id |
用于 picasa 网络相册 |
isprivate |
|
latitude |
纬度,需要照片有 GPS 信息 |
longitude |
经度,需要照片有 GPS 信息 |
datetaken |
取自 EXIF 照片拍摄时间,若为空则等于文件修改时间,单位毫秒 |
orientation |
取自 EXIF 旋转角度,在图库旋转图片也会改变此值 |
mini_thumb_magic |
取小缩略图时生成的一个随机数,见 MediaThumbRequest |
bucket_id |
等于 path.toLowerCase.hashCode(),见 MediaProvider.computeBucketValues() |
bucket_display_name |
直接包含图片的文件夹就是该图片的 bucket,就是文件夹名 |
thumbnails:缩略图
字段 解析
_id |
主键。缩略图 id,从 1 开始自增 |
_data |
图片绝对路径 |
image_id |
缩略图所对应图片的 id,依赖于 images 表 _id 字段,可建立外键 |
kind |
缩略图类型,1 是大缩略图,2 基本不用,3 是微型缩略图但其信息不保存在数据库 |
width |
缩略图宽度 |
height |
缩略图高度 |
视频数据库
数据表字段解析如下:
video:视频信息
字段 解析
_id |
主键。视频 id |
_data |
视频绝对路径 |
_display_name |
文件名 |
_size |
文件大小,单位为 byte |
mime_type |
类似于 video/avi 的 MIME 类型 |
date_added |
添加到数据库的时间,单位秒 |
date_modified |
文件最后修改时间,单位秒 |
title |
不带扩展名的文件名 |
duration |
视频时长,单位毫秒 |
artist |
艺术家 |
album |
专辑名,一般为文件夹名 |
resolution |
|
description |
|
isprivate |
|
tags |
|
category |
|
language |
|
mini_thumb_data |
|
latitude |
|
longitude |
|
datetaken |
|
mini_thumb_magic |
取小缩略图时生成的一个随机数,见 MediaThumbRequest |
bucket_id |
等于 path.toLowerCase.hashCode(),见 MediaProvider.computeBucketValues() |
bucket_display_name |
直接包含视频的文件夹就是该图片的 bucket,就是文件夹名 |
bookmark |
|
videothumbnails:视频缩略图
字段 解析
_id |
主键。缩略图 id |
_data |
缩略图绝对路径 |
video_id |
缩略图所对应视频的 id,依赖于 video 表 _id 字段 |
kind |
缩略图类型,1 是大图,视频只能取类型 1 |
width |
缩略图宽度 |
height |
缩略图高度 |
音频数据库
音频数据库是最复杂的,由 10 个表组成。物理数据模型如下所示:
album_art:专辑封面
字段 解析
album_id |
主键。专辑 id |
_data |
专辑封面缓存的路径 |
albums:专辑信息
字段 解析
album_id |
主键。专辑 id |
album_key |
全大写字母,用于字母索引 |
album |
专辑名 |
android_metadata:当前字符编码
字段 解析
locale |
默认字符编码,例如 zh_CN |
artists:艺术家
字段 解析
artist_id |
主键。艺术家 id |
artist_key |
全大写字母,用于字母索引 |
artist |
艺术家 |
audio_genres:流派
字段 解析
_id |
主键。流派 id |
name |
流派名称 |
audio_genres_map:音频流派映射
字段 解析
_id |
主键。映射 id |
audio_id |
音频 id |
genre_id |
流派 id |
Note: 为何要建立映射表:为了消除数据冗余。假如有大量音频属于同一流派,如果没有映射表则需要每个音频都需要记录同样的流派数据,有了映射表之后则只有一条记录就够了。这符合数据库设计的第三范式(the 3rd normal form)
audio_meta:音频信息
字段 解析
_id |
主键。音频 id |
_data |
文件绝对路径 |
_display_name |
文件名 |
_size |
文件大小,单位 byte |
mime_type |
类似于 audio/mpeg 的 MIME 类型 |
date_added |
添加到数据库的时间,单位秒 |
date_modified |
文件最后修改时间,单位秒 |
title |
来自 ID3 信息的标题,无则为不带扩展名的文件名 |
title_key |
全大写字母的标题 |
duration |
时长 |
artist_id |
艺术家 id |
composer |
来自 ID3 信息,作曲家 |
album_id |
专辑 id |
track |
来自 ID3 信息,音轨 |
year |
来自 ID3 信息,年代 |
is_ringtone |
是否铃声,0 或 1 |
is_music |
是否音乐,1 才会在音乐播放器显示 |
is_alarm |
是否闹钟铃声 |
is_notification |
是否通知铃声 |
is_podcast |
是否 podcast |
bookmark |
|
audio_playlists:播放列表
字段 解析
_id |
主键。播放列表 id |
_data |
|
name |
播放列表名 |
date_added |
|
date_modified |
|
audio_playlists_map:音频播放列表映射
字段 解析
_id |
主键。映射 id |
audio_id |
音频 id |
playlist_id |
播放列表 id |
play_order |
播放顺序 |
索引
在 Android 数据库当中基本上使用自增 id 值作为主键,并建立了索引。索引可以加快数据查找速度,但由于需要维护索引所以插入/删除等写入操作速度会变慢。索引如下:
1 |
CREATE INDEX album_id_idx on audio_meta(album_id); |
2 |
CREATE INDEX album_idx on albums(album); |
3 |
CREATE INDEX albumkey_index on albums(album_key); |
4 |
CREATE INDEX artist_id_idx on audio_meta(artist_id); |
5 |
CREATE INDEX artist_idx on artists(artist); |
6 |
CREATE INDEX artistkey_index on artists(artist_key); |
7 |
CREATE INDEX image_bucket_index ON images(bucket_id, datetaken); |
8 |
CREATE INDEX image_id_index on thumbnails(image_id); |
9 |
CREATE INDEX sort_index on images(datetaken ASC , _id ASC ); |
10 |
CREATE INDEX title_idx on audio_meta(title); |
11 |
CREATE INDEX titlekey_index on audio_meta(title_key); |
12 |
CREATE INDEX video_bucket_index ON video(bucket_id, datetaken); |
13 |
CREATE INDEX video_id_index on videothumbnails(video_id); |
由于比较简单就不解释了,要深入了解索引可以参考这个关于 SQL Server 的分析MySQL索引背后的数据结构及算法原理,原理应该是差不多的。
视图
视图类似于表,但并非独立存在,是从其他表里面查询数据得到的。使用视图可以加快数据库查询速度,不用每次都执行复杂的 SQL 语句查询。图如下所示:
Note: 如何看视图:图下面的部分是数据来源的表,中间是从表中选取的字段,但类似于 COUNT 等 SQL 查询操作无法在图上体现,最好还是看实际 SQL 语句。
Note: SQLite 当中视图都是只读的,也就是说不能对视图进行插入、更新、删除等操作。但是可以在视图建立 INSTEAD OF 触发器来达到同样的目的,多媒体数据库当中的 audio_delete 触发器就是如此。
触发器
触发器是为了维护数据库删除操作而建立的,因为所删除的表可能与另外的表有关系,需要同时删除另外一个表的字段。可以看以下一个例子:
1 |
CREATE TRIGGER audio_meta_cleanup |
4 |
DELETE FROM audio_genres_map WHERE audio_id = old._id; |
5 |
DELETE FROM audio_playlists_map WHERE audio_id = old._id; |
这是关于 audio_meta 表的触发器,意思是当删除此表上的记录时,同时删除 audio_genres_map 表上 audio_id 与此表 id 相同的记录,删除 audio_playlists_map 表上 audio_id 与此表 id 相同的记录。这样当删除 audio_meta 表的记录时,另外两个表的相应记录也会自动删除,不会由于漏删除而残留多余数据。
3. 如何维护数据库
插入
插入、更新主要由 MediaScanner 进行,当删除/移动媒体文件时 MediaScanner 会扫描磁盘并更新数据库。数据插入主要在 endFile() 方法中进行,例如插入音频记录时相关的表都会插入相应的记录。而图片、视频缩略图,专辑封面这几个则是第一次取图片的时候才会生成缩略图保存到磁盘,并把记录插入到数据库中。
删除
删除操作主要由触发器维护。例如当一个应用删除图片时,一般只会删除图片数据库,所以必须要有触发器同时删除缩略图数据库。