1. 創建MediaScanner
認識一下MediaScanner,它的代碼如下所示:
**MediaScanner.java**
~~~
public class MediaScanner
{
static {
/*
加載libmedia_jni.so,這么重要的庫竟然放在如此不起眼的MediaScanner類中加載。
個人覺得,可能是因為開機后多媒體系統中最先啟動的就是媒體掃描工作吧。
*/
System.loadLibrary("media_jni");
native_init();
}
//創建媒體掃描器
public MediaScanner(Context c) {
native_setup();//調用JNI層的函數做一些初始化工作
......
}
~~~
在上面的MS中,比較重要的幾個調用函數是:
- native_init和native_setup,關于它們的故事,在分析JNI層時再做介紹。
MS創建好后,MSS將調用它的scanDirectories開展掃描工作,下面來看這個函數。
2. scanDirectories的分析
scanDirectories的代碼如下所示:
**MediaScanner.java**
~~~
public void scanDirectories(String[]directories, String volumeName) {
try {
long start = System.currentTimeMillis();
initialize(volumeName);//①初始化
prescan(null);//②掃描前的預處理
long prescan = System.currentTimeMillis();
for(int i = 0; i < directories.length; i++) {
/*
③ processDirectory是一個native函數,調用它來對目標文件夾進行掃描,
其中MediaFile.sFileExtensions是一個字符串,包含了當前多媒體系統所支持的
媒體文件的后綴名,例如.MP3、.MP4等。mClient為MyMediaScannerClient類型,
它是從MediaScannerClient類派生的。它的作用我們后面再做分析。
*/
processDirectory(directories[i], MediaFile.sFileExtensions,
mClient);
}
long scan = System.currentTimeMillis();
postscan(directories);//④掃描后處理
long end = System.currentTimeMillis();
......//統計掃描時間等
}
~~~
上面一共列出了四個關鍵點,下面逐一對其分析。
(1)initialize的分析
initialize主要是初始化一些Uri,因為掃描時需把文件的信息插入媒體數據庫中,而媒體數據庫針對Video、Audio、Image文件等都有對應的表,這些表的地址則由Uri表示。下面是initialize的代碼:
**MediaScanner.java**
~~~
private void initialize(String volumeName) {
//得到IMediaProvider對象,通過這個對象可以對媒體數據庫進行操作。
mMediaProvider=
mContext.getContentResolver().acquireProvider("media");
//初始化Uri,下面分別介紹一下。
//音頻表的地址,也就是數據庫中的audio_meta表。
mAudioUri =Audio.Media.getContentUri(volumeName);
//視頻表地址,也就是數據庫中的video表。
mVideoUri = Video.Media.getContentUri(volumeName);
//圖片表地址,也就是數據庫中的images表。
mImagesUri = Images.Media.getContentUri(volumeName);
//縮略圖表地址,也就是數據庫中的thumbs表。
mThumbsUri = Images.Thumbnails.getContentUri(volumeName);
//如果掃描的是外部存儲,則支持播放列表、音樂的流派等內容。
if(!volumeName.equals("internal")) {
mProcessPlaylists = true;
mProcessGenres = true;
mGenreCache = new HashMap<String, Uri>();
mGenresUri = Genres.getContentUri(volumeName);
mPlaylistsUri = Playlists.getContentUri(volumeName);
if ( Process.supportsProcesses()) {
//SD卡存儲區域一般使用FAT文件系統,所以文件名與大小寫無關
mCaseInsensitivePaths = true;
}
}
}
~~~
下面看第二個關鍵函數prescan。
(2)prescan的分析
在媒體掃描過程中,有個令人頭疼的問題,來舉個例子,這個例子會貫穿在對這個問題整體分析的過程中。例子:假設某次掃描之前SD卡中有100個媒體文件,數據庫中有100條關于這些文件的記錄,現因某種原因刪除了其中的50個媒體文件,那么媒體數據庫什么時候會被更新呢?
讀者別小瞧這個問題。現在有很多文件管理器支持刪除文件和文件夾,它們用起來很方便,卻沒有對應地更新數據庫,這導致了查詢數據庫時還能得到這些媒體文件信息,但這個文件實際上已不存在了,而且后面所有和此文件有關的操作都會因此而失敗。
其實,MS已經考慮到這一點了,prescan函數的主要作用是在掃描之前把數據庫中和文件相關的信息取出并保存起來,這些信息主要是媒體文件的路徑,所屬表的Uri。就上面這個例子來說,它會從數據庫中取出100個文件的文件信息。
prescan的代碼如下所示:
**MediaScanner.java**
~~~
privatevoid prescan(String filePath) throws RemoteException {
Cursor c = null;
String where = null;
String[] selectionArgs = null;
//mFileCache保存從數據庫中獲取的文件信息。
if(mFileCache == null) {
mFileCache = new HashMap<String, FileCacheEntry>();
}else {
mFileCache.clear();
}
......
try {
//從Audio表中查詢其中和音頻文件相關的文件信息。
if (filePath != null) {
where = MediaStore.Audio.Media.DATA + "=?";
selectionArgs = new String[] { filePath };
}
//查詢數據庫的Audio表,獲取對應的音頻文件信息。
c = mMediaProvider.query(mAudioUri, AUDIO_PROJECTION, where,
selectionArgs,null);
if (c != null) {
try {
while (c.moveToNext()) {
long rowId =c.getLong(ID_AUDIO_COLUMN_INDEX);
//音頻文件的路徑
String path =c.getString(PATH_AUDIO_COLUMN_INDEX);
long lastModified =
c.getLong(DATE_MODIFIED_AUDIO_COLUMN_INDEX);
if(path.startsWith("/")) {
String key = path;
if(mCaseInsensitivePaths) {
key =path.toLowerCase();
}
//把文件信息存到mFileCache中
mFileCache.put(key,
new FileCacheEntry(mAudioUri, rowId, path,
lastModified));
}
}
} finally {
c.close();
c = null;
}
}
......//查詢其他表,取出數據中關于視頻,圖像等文件的信息并存入到mFileCache中。
finally {
if (c != null) {
c.close();
}
}
}
~~~
懂了前面的例子,在閱讀prescan函數時可能就比較輕松了。prescan函數執行完后,mFileCache保存了掃描前所有媒體文件的信息,這些信息是從數據庫中查詢得來的,也就是舊有的信息。
接下來,看最后兩個關鍵函數。
(3)processDirectory和postscan的分析
processDirectory是一個native函數,其具體功能放到JNI層再分析,這里先簡單介紹,它在解決上一節那個例子中提出的問題時,所做的工作。答案是:processDirectory將掃描SD卡,每掃描一個文件,都會設置mFileCache中對應文件的一個叫mSeenInFileSystem的變量為true。這個值表示這個文件目前還存在于SD卡上。這樣,待整個SD卡掃描完后,mFileCache的那100個文件中就會有50個文件的mSeenInFileSystem為true,而剩下的另50個文件則為初始值false。
看到上面的內容,可以知道postscan的作用了吧?就是它把不存在于SD卡的文件信息從數據庫中刪除,而使數據庫得以徹底更新的。來看postscan函數是否是這樣處理的:
**MediaScanner.java**
~~~
private void postscan(String[] directories)throws RemoteException {
Iterator<FileCacheEntry> iterator =mFileCache.values().iterator();
while(iterator.hasNext()) {
FileCacheEntry entry = iterator.next();
String path = entry.mPath;
boolean fileMissing = false;
if (!entry.mSeenInFileSystem) {
if (inScanDirectory(path, directories)) {
fileMissing = true; //這個文件確實丟失了
} else {
File testFile = newFile(path);
if (!testFile.exists()) {
fileMissing = true;
}
}
}
//如果文件確實丟失,則需要把數據庫中和它相關的信息刪除。
if(fileMissing) {
MediaFile.MediaFileType mediaFileType = MediaFile.getFileType(path);
int fileType = (mediaFileType == null ? 0 : mediaFileType.fileType);
if(MediaFile.isPlayListFileType(fileType)) {
......//處理丟失文件是播放列表的情況
} else {
/*由于文件信息中還攜帶了它在數據庫中的相關信息,所以從數據庫中刪除對應的信息會非常快。
*/
mMediaProvider.delete(ContentUris.withAppendedId(
entry.mTableUri, entry.mRowId), null, null);
iterator.remove();
}
}
}
......//刪除縮略圖文件等工作
}
~~~
Java層中的四個關鍵點,至此已介紹了三個,另外一個processDirectory是媒體掃描的關鍵函數,由于它是一個native函數,所以下面將轉戰到JNI層來進行分析。
- 前言
- 第1章 閱讀前的準備工作
- 1.1 系統架構
- 1.1.1 Android系統架構
- 1.1.2 本書的架構
- 1.2 搭建開發環境
- 1.2.1 下載源碼
- 1.2.2 編譯源碼
- 1.3 工具介紹
- 1.3.1 Source Insight介紹
- 1.3.2 Busybox的使用
- 1.4 本章小結
- 第2章 深入理解JNI
- 2.1 JNI概述
- 2.2 學習JNI的實例:MediaScanner
- 2.3 Java層的MediaScanner分析
- 2.3.1 加載JNI庫
- 2.3.2 Java的native函數和總結
- 2.4 JNI層MediaScanner的分析
- 2.4.1 注冊JNI函數
- 2.4.2 數據類型轉換
- 2.4.3 JNIEnv介紹
- 2.4.4 通過JNIEnv操作jobject
- 2.4.5 jstring介紹
- 2.4.6 JNI類型簽名介紹
- 2.4.7 垃圾回收
- 2.4.8 JNI中的異常處理
- 2.5 本章小結
- 第3章 深入理解init
- 3.1 概述
- 3.2 init分析
- 3.2.1 解析配置文件
- 3.2.2 解析service
- 3.2.3 init控制service
- 3.2.4 屬性服務
- 3.3 本章小結
- 第4章 深入理解zygote
- 4.1 概述
- 4.2 zygote分析
- 4.2.1 AppRuntime分析
- 4.2.2 Welcome to Java World
- 4.2.3 關于zygote的總結
- 4.3 SystemServer分析
- 4.3.1 SystemServer的誕生
- 4.3.2 SystemServer的重要使命
- 4.3.3 關于 SystemServer的總結
- 4.4 zygote的分裂
- 4.4.1 ActivityManagerService發送請求
- 4.4.2 有求必應之響應請求
- 4.4.3 關于zygote分裂的總結
- 4.5 拓展思考
- 4.5.1 虛擬機heapsize的限制
- 4.5.2 開機速度優化
- 4.5.3 Watchdog分析
- 4.6 本章小結
- 第5章 深入理解常見類
- 5.1 概述
- 5.2 以“三板斧”揭秘RefBase、sp和wp
- 5.2.1 第一板斧--初識影子對象
- 5.2.2 第二板斧--由弱生強
- 5.2.3 第三板斧--破解生死魔咒
- 5.2.4 輕量級的引用計數控制類LightRefBase
- 5.2.5 題外話-三板斧的來歷
- 5.3 Thread類及常用同步類分析
- 5.3.1 一個變量引發的思考
- 5.3.2 常用同步類
- 5.4 Looper和Handler類分析
- 5.4.1 Looper類分析
- 5.4.2 Handler分析
- 5.4.3 Looper和Handler的同步關系
- 5.4.4 HandlerThread介紹
- 5.5 本章小結
- 第6章 深入理解Binder
- 6.1 概述
- 6.2 庖丁解MediaServer
- 6.2.1 MediaServer的入口函數
- 6.2.2 獨一無二的ProcessState
- 6.2.3 時空穿越魔術-defaultServiceManager
- 6.2.4 注冊MediaPlayerService
- 6.2.5 秋風掃落葉-StartThread Pool和join Thread Pool分析
- 6.2.6 你徹底明白了嗎
- 6.3 服務總管ServiceManager
- 6.3.1 ServiceManager的原理
- 6.3.2 服務的注冊
- 6.3.3 ServiceManager存在的意義
- 6.4 MediaPlayerService和它的Client
- 6.4.1 查詢ServiceManager
- 6.4.2 子承父業
- 6.5 拓展思考
- 6.5.1 Binder和線程的關系
- 6.5.2 有人情味的訃告
- 6.5.3 匿名Service
- 6.6 學以致用
- 6.6.1 純Native的Service
- 6.6.2 扶得起的“阿斗”(aidl)
- 6.7 本章小結
- 第7章 深入理解Audio系統
- 7.1 概述
- 7.2 AudioTrack的破解
- 7.2.1 用例介紹
- 7.2.2 AudioTrack(Java空間)分析
- 7.2.3 AudioTrack(Native空間)分析
- 7.2.4 關于AudioTrack的總結
- 7.3 AudioFlinger的破解
- 7.3.1 AudioFlinger的誕生
- 7.3.2 通過流程分析AudioFlinger
- 7.3.3 audio_track_cblk_t分析
- 7.3.4 關于AudioFlinger的總結
- 7.4 AudioPolicyService的破解
- 7.4.1 AudioPolicyService的創建
- 7.4.2 重回AudioTrack
- 7.4.3 聲音路由切換實例分析
- 7.4.4 關于AudioPolicy的總結
- 7.5 拓展思考
- 7.5.1 DuplicatingThread破解
- 7.5.2 題外話
- 7.6 本章小結
- 第8章 深入理解Surface系統
- 8.1 概述
- 8.2 一個Activity的顯示
- 8.2.1 Activity的創建
- 8.2.2 Activity的UI繪制
- 8.2.3 關于Activity的總結
- 8.3 初識Surface
- 8.3.1 和Surface有關的流程總結
- 8.3.2 Surface之乾坤大挪移
- 8.3.3 乾坤大挪移的JNI層分析
- 8.3.4 Surface和畫圖
- 8.3.5 初識Surface小結
- 8.4 深入分析Surface
- 8.4.1 與Surface相關的基礎知識介紹
- 8.4.2 SurfaceComposerClient分析
- 8.4.3 SurfaceControl分析
- 8.4.4 writeToParcel和Surface對象的創建
- 8.4.5 lockCanvas和unlockCanvasAndPost分析
- 8.4.6 GraphicBuffer介紹
- 8.4.7 深入分析Surface的總結
- 8.5 SurfaceFlinger分析
- 8.5.1 SurfaceFlinger的誕生
- 8.5.2 SF工作線程分析
- 8.5.3 Transaction分析
- 8.5.4 關于SurfaceFlinger的總結
- 8.6 拓展思考
- 8.6.1 Surface系統的CB對象分析
- 8.6.2 ViewRoot的你問我答
- 8.6.3 LayerBuffer分析
- 8.7 本章小結
- 第9章 深入理解Vold和Rild
- 9.1 概述
- 9.2 Vold的原理與機制分析
- 9.2.1 Netlink和Uevent介紹
- 9.2.2 初識Vold
- 9.2.3 NetlinkManager模塊分析
- 9.2.4 VolumeManager模塊分析
- 9.2.5 CommandListener模塊分析
- 9.2.6 Vold實例分析
- 9.2.7 關于Vold的總結
- 9.3 Rild的原理與機制分析
- 9.3.1 初識Rild
- 9.3.2 RIL_startEventLoop分析
- 9.3.3 RIL_Init分析
- 9.3.4 RIL_register分析
- 9.3.5 關于Rild main函數的總結
- 9.3.6 Rild實例分析
- 9.3.7 關于Rild的總結
- 9.4 拓展思考
- 9.4.1 嵌入式系統的存儲知識介紹
- 9.4.2 Rild和Phone的改進探討
- 9.5 本章小結
- 第10章 深入理解MediaScanner
- 10.1 概述
- 10.2 android.process.media分析
- 10.2.1 MSR模塊分析
- 10.2.2 MSS模塊分析
- 10.2.3 android.process.media媒體掃描工作的流程總結
- 10.3 MediaScanner分析
- 10.3.1 Java層分析
- 10.3.2 JNI層分析
- 10.3.3 PVMediaScanner分析
- 10.3.4 關于MediaScanner的總結
- 10.4 拓展思考
- 10.4.1 MediaScannerConnection介紹
- 10.4.2 我問你答
- 10.5 本章小結