本節將分析ContentProvider中另一個比較復雜的知識點，即query的實現。從ContentResolver的query函數開始，其代碼如下： **ContentResolver.java::query** ~~~ /* 注意query中的參數，它們組合后得到的SQL語句如下（方括號中的語句為筆者添加的注釋） SELECT projection指定的列名[如果projection為null，則使用“*”] FROM 表名[由目標CP根據uri參數設置] WHERE （selection）[如果selection中有通配符，具體參數由selectionArgs指定] ORDERYEDBY sortOrder */ public final Cursor query(Uri uri, String[]projection, String selection, String[] selectionArgs, String sortOrder) { /* 根據前面的分析，下面這個函數返回的provider的真實類型是ContentProviderProxy， 對應的Bn端對象的真實類型是ContentProvider的內部類Transport。本次執行query的 目標CP是MediaProvider */ IContentProvider provider = acquireProvider(uri); //來看下面的代碼 try { long startTime = SystemClock.uptimeMillis(); //①調用遠端進程的query函數 Cursor qCursor = provider.query(uri, projection, selection, selectionArgs, sortOrder); if (qCursor == null) { //如果返回的結果為空，則釋放provider，這個函數的作用在7.2.3節介紹過 releaseProvider(provider); return null; } //②計算查詢結果包含的數據項條數，結果保存在qCursor的內部變量中 qCursor.getCount(); long durationMillis = SystemClock.uptimeMillis() - startTime; //③最終返回給客戶端一個游標對象，其真實數據類型為CursorWrapperInner return new CursorWrapperInner(qCursor, provider); } ~~~ 上面這段代碼揭示了ContentResolver query函數的工作流程： - 調用遠程CP的query函數，返回一個Cursor類型的對象qCursor。 - 該函數最終返給客戶端的是一個CursorWrapperInner類型的對象。 Cursor和CursorWrappperInner這兩個新出現的數據類型嚴重干擾了我們的思考。暫且不管它們，先來分析以上代碼中列出的幾個關鍵點函數。首先要分析的是第一個關鍵點函數query。