Android 非同步載入神器 Loader 全解析
在之前呢，我們經常會有這種需求，比如在某個activity，或者某個fragment裡面，我們需要查詢某個資料來源，並且顯示出來，當資料來源自己更新的時候，介面也要及時響應。
當然咯，查詢資料這個過程可能很短，但是也可能很漫長，為了避免anr，我們都是開啟一個子執行緒去查詢，然後通過handler來更新我們的ui介面。但是，考慮到activity和
fragment 複雜的生命週期，上述的方法 使用起來會很不方便，畢竟你要考慮到儲存現場 還原現場 等等複雜的工作來保證你的app無懈可擊。所以後來呢谷歌就幫我們推出了一個新的東西—Loader。他可以幫我們完成上述所有功能！實在是很強大。
如果你有閱讀英文技術文件的習慣 那麼谷歌官方的文件 也許比我所說的更加完美。具體可以參考如下：
http://developer.android.com/intl/zh-cn/reference/android/app/LoaderManager.html
http://developer.android.com/intl/zh-cn/reference/android/content/AsyncTaskLoader.html
http://developer.android.com/intl/zh-cn/guide/components/loaders.html
我所述的內容也是主要基於上述三篇文件。
首先呢，我們來看第一個例子，這個例子也是官方的推薦了，我給簡化了一下，主要是監聽手機裡 聯絡人這個資料來源。當資料來源改變的時候 自動update 我們的ui。
package com.example.administrator.modifytestview;
import android.app.Activity;
import android.app.FragmentManager;
import android.app.ListFragment;
import android.app.LoaderManager;
import android.content.CursorLoader;
import android.content.Loader;
import android.database.Cursor;
import android.net.Uri;
import android.os.Bundle;
import android.provider.ContactsContract.Contacts;
import android.util.Log;
import android.view.View;
import android.widget.ListView;
import android.widget.SimpleCursorAdapter;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
FragmentManager fm = getFragmentManager();
CursorLoaderListFragment list = new CursorLoaderListFragment();
fm.beginTransaction().replace(R.id.root, list).commit();
}
public static class CursorLoaderListFragment extends ListFragment
implements LoaderManager.LoaderCallbacks<Cursor> {
// This is the Adapter being used to display the list's data.
SimpleCursorAdapter mAdapter;
// If non-null, this is the current filter the user has provided.
String mCurFilter;
@Override
public void onActivityCreated(Bundle savedInstanceState) {
mAdapter = new SimpleCursorAdapter(getActivity(),
android.R.layout.simple_list_item_2, null,
new String[]{Contacts.DISPLAY_NAME, Contacts.CONTACT_STATUS},
new int[]{android.R.id.text1, android.R.id.text2}, 0);
setListAdapter(mAdapter);
//這個地方初始化了我們的loader
getLoaderManager().initLoader(0, null, this);
super.onActivityCreated(savedInstanceState);
}
@Override
public void onListItemClick(ListView l, View v, int position, long id) {
// Insert desired behavior here.
Log.i("FragmentComplexList", "Item clicked: " + id);
}
// These are the Contacts rows that we will retrieve.
static final String[] CONTACTS_SUMMARY_PROJECTION = new String[]{
Contacts._ID,
Contacts.DISPLAY_NAME,
Contacts.CONTACT_STATUS,
Contacts.CONTACT_PRESENCE,
Contacts.PHOTO_ID,
Contacts.LOOKUP_KEY,
};
//只會呼叫一次
public Loader<Cursor> onCreateLoader(int id, Bundle args) {
// This is called when a new Loader needs to be created. This
// sample only has one Loader, so we don't care about the ID.
// First, pick the base URI to use depending on whether we are
// currently filtering.
Uri baseUri;
if (mCurFilter != null) {
baseUri = Uri.withAppendedPath(Contacts.CONTENT_FILTER_URI,
Uri.encode(mCurFilter));
} else {
baseUri = Contacts.CONTENT_URI;
}
// Now create and return a CursorLoader that will take care of
// creating a Cursor for the data being displayed.
String select = "((" + Contacts.DISPLAY_NAME + " NOTNULL) AND ("
+ Contacts.HAS_PHONE_NUMBER + "=1) AND ("
+ Contacts.DISPLAY_NAME + " != '' ))";
//返回的是對這個資料來源的監控
return new CursorLoader(getActivity(), baseUri,
CONTACTS_SUMMARY_PROJECTION, select, null,
Contacts.DISPLAY_NAME + " COLLATE LOCALIZED ASC");
}
//每次資料來源都有更新的時候，就會回撥這個方法，然後update 我們的ui了。
public void onLoadFinished(Loader<Cursor> loader, Cursor data) {
// Swap the new cursor in. (The framework will take care of closing the
// old cursor once we return.)
mAdapter.swapCursor(data);
// The list should now be shown.
if (isResumed()) {
setListShown(true);
} else {
setListShownNoAnimation(true);
}
}
public void onLoaderReset(Loader<Cursor> loader) {
// This is called when the last Cursor provided to onLoadFinished()
// above is about to be closed. We need to make sure we are no
// longer using it.
mAdapter.swapCursor(null);
}
}
}
可以仔細的觀察一下這個程式碼，我們能發現 使用loader所需要的一些步驟：
1.需要一個activity或者是fragment，當然在上述的例子裡 我們使用的是fragment。
2.一個LoaderManger的例項，注意看53行，我們get了一個loadermanager。這個地方就是獲取例項了。
3.需要一個CursorLoader，並且從contentProvider獲取資料來源，90-97行 就是這麼做的。
4.需要實現一個LoaderCallBack的這個介面，然後在幾個回撥方法裡 寫上我們自己業務的邏輯 即可。你看34行就是繼承的介面。
還有3個回撥方法在那，我們都在裡面實現了自己的邏輯。
到這，其實一看，思路還是很清晰的。那到這裡 有人肯定要說了。你這個沒用啊，要實現contentprovider，我們的app不需要做資料共享的，能否直接運算元據庫呢？答案是可以的。在這裡我們也可以構造出一個場景。假設有一張學生表。我們點選add按鈕，就自動往這個表裡面增加一個資料，然後下面有個listview 會自動捕捉到 這個資料來源的變化，然後自動更新列表。
我們可以知道 上面那個demo裡面 CursorLoader的定義是這樣的
public class CursorLoader extends AsyncTaskLoader<Cursor> {
我們現在要實現一個不用contentProvider的Loader 也是基於AsyncTaskLoader來的。
先給出一個抽象類：
package com.example.administrator.activeandroidtest3;
import android.content.AsyncTaskLoader;
import android.content.Context;
import android.database.Cursor;
public abstract class SimpleCursorLoader extends AsyncTaskLoader<Cursor> {
private Cursor mCursor;
public SimpleCursorLoader(Context context) {
super(context);
}
/* 在子執行緒裡運作 */
@Override
public abstract Cursor loadInBackground();
/* 在ui 執行緒裡運作 */
@Override
public void deliverResult(Cursor cursor) {
if (isReset()) {
// An async query came in while the loader is stopped
if (cursor != null) {
cursor.close();
}
return;
}
Cursor oldCursor = mCursor;
mCursor = cursor;
if (isStarted()) {
super.deliverResult(cursor);
}
if (oldCursor != null && oldCursor != cursor && !oldCursor.isClosed()) {
oldCursor.close();
}
}
@Override
protected void onStartLoading() {
if (mCursor != null) {
deliverResult(mCursor);
}
if (takeContentChanged() || mCursor == null) {
forceLoad();
}
}
@Override
protected void onStopLoading() {
cancelLoad();
}
@Override
public void onCanceled(Cursor cursor) {
if (cursor != null && !cursor.isClosed()) {
cursor.close();
}
}
@Override
protected void onReset() {
super.onReset();
onStopLoading();
if (mCursor != null && !mCursor.isClosed()) {
mCursor.close();
}
mCursor = null;
}
}
然後我們再接著定義我們最終的 不需要provider的loader實現類(注意你如果想寫的比較完美的話 cursor記得用抽象類的，抽象類的那個就不要寫成private的了，我這裡為了圖簡單 直接用自己構造的)。
package com.example.administrator.activeandroidtest3;
import android.content.Context;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
/**
* Created by Administrator on 2015/10/7.
*/
public class SpecialLoader extends SimpleCursorLoader {
ForceLoadContentObserver mObserver = new ForceLoadContentObserver();
private Context context;
public SpecialLoader(Context context) {
super(context);
this.context = context;
}
@Override
public Cursor loadInBackground() {
DatabaseHelper dh = new DatabaseHelper(context, "Test.db");
SQLiteDatabase database = dh.getReadableDatabase();
String table = "Student";
String[] columns = new String[]{"Name", "No"};
//這個地方因為我用的是activeandroid 的orm 框架，所以預設的自增長主鍵是Id，但是SimpleCursorAdapter
//需要的是_id 否則會報錯，所以這裡要重新命名一下
Cursor cursor = database.rawQuery("SELECT Id AS _id,Name,No FROM Student", null);
if (database != null) {
if (cursor != null) {
//註冊一下這個觀察者
cursor.registerContentObserver(mObserver);
//這邊也要注意 一定要監聽這個uri的變化。但是如果你這個uri沒有對應的provider的話
//記得在你運算元據庫的時候 通知一下這個uri
cursor.setNotificationUri(context.getContentResolver(), MainActivity.uri);
}
}
return cursor;
}
}
然後我們在簡單看下activity 主類裡的程式碼：
package com.example.administrator.activeandroidtest3;
import android.app.Activity;
import android.app.LoaderManager;
import android.content.Loader;
import android.database.Cursor;
import android.net.Uri;
import android.os.Bundle;
import android.util.Log;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.widget.ListView;
import android.widget.SimpleCursorAdapter;
import android.widget.TextView;
import com.activeandroid.query.Select;
import java.util.List;
import java.util.Random;
public class MainActivity extends Activity implements LoaderManager.LoaderCallbacks {
public static final Uri uri = Uri.parse("content://com.example.student");
private TextView addTv;
private ListView lv;
private SimpleCursorAdapter adapter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
addTv = (TextView) this.findViewById(R.id.add);
addTv.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Student student = new Student();
student.name = getRandomString(5);
student.no = (int) (Math.random() * 1000) + "";
student.sex = (int) (Math.random() * 1);
student.save();
//操作完資料庫要notify 不然loader那邊收不到哦
getContentResolver().notifyChange(uri, null);
}
});
lv = (ListView) this.findViewById(R.id.lv);
adapter = new SimpleCursorAdapter(MainActivity.this,
android.R.layout.simple_list_item_2, null,
new String[]{"Name", "No"},
new int[]{android.R.id.text1, android.R.id.text2}, 0);
lv.setAdapter(adapter);
getLoaderManager().initLoader(0, null, this);
}
@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.menu_main, menu);
return true;
}
@Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
//noinspection SimplifiableIfStatement
if (id == R.id.action_settings) {
return true;
}
return super.onOptionsItemSelected(item);
}
public static String getRandomString(int length) { //length表示生成字串的長度
String base = "abcdefghijklmnopqrstuvwxyz0123456789";
Random random = new Random();
StringBuffer sb = new StringBuffer();
for (int i = 0; i < length; i++) {
int number = random.nextInt(base.length());
sb.append(base.charAt(number));
}
return sb.toString();
}
@Override
public Loader onCreateLoader(int id, Bundle args) {
SpecialLoader loader = new SpecialLoader(MainActivity.this);
return loader;
}
@Override
public void onLoadFinished(Loader loader, Object data) {
adapter.swapCursor((Cursor) data);
}
@Override
public void onLoaderReset(Loader loader) {
}
}
最後我們看下執行的效果：
好，那到這裡 又有人要說了，你這個說來說去 還不是隻能支援provider或者db型別的資料來源嗎？好 接著往下，我們給出另外一個例子，不過這個例子是谷歌官方的例子，我就取其中重要的部分給予註釋講解。
http://developer.android.com/intl/zh-cn/reference/android/content/AsyncTaskLoader.html
首先說一下 這個例子是幹嘛的，他主要是監聽手機裡app list的變化，比如你刪除了一個應用安裝了一個應用，馬上就能捕捉到你的手機裡app list的變化 並顯示在介面，大家都知道 監聽app list是通過監聽系統廣播來完成的。 我就主要講一下 這個官方demo裡 是如何在監聽到系統廣播以後和loader結合起來然後自動回撥方法的。
/**
* Helper class to look for interesting changes to the installed apps
* so that the loader can be updated.
*/
public static class PackageIntentReceiver extends BroadcastReceiver {
final AppListLoader mLoader;
//這個建構函式是很重要的 他接收的 就是自定義的loader
public PackageIntentReceiver(AppListLoader loader) {
mLoader = loader;
IntentFilter filter = new IntentFilter(Intent.ACTION_PACKAGE_ADDED);
filter.addAction(Intent.ACTION_PACKAGE_REMOVED);
filter.addAction(Intent.ACTION_PACKAGE_CHANGED);
filter.addDataScheme("package");
mLoader.getContext().registerReceiver(this, filter);
// Register for events related to sdcard installation.
IntentFilter sdFilter = new IntentFilter();
sdFilter.addAction(Intent.ACTION_EXTERNAL_APPLICATIONS_AVAILABLE);
sdFilter.addAction(Intent.ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE);
//在這個地方 直接用loader來註冊這個廣播接收器
mLoader.getContext().registerReceiver(this, sdFilter);
}
//在收到廣播以後 什麼事情都沒有做，而是呼叫了loader的onContentChanged方法
@Override public void onReceive(Context context, Intent intent) {
// Tell the loader about the change.
mLoader.onContentChanged();
}
}
你看這裡的25-26行 呼叫了 loader的onContentChanged方法。繼續看下面的loader
/**
* A custom Loader that loads all of the installed applications.
*/
public static class AppListLoader extends AsyncTaskLoader<List<AppEntry>> {
final InterestingConfigChanges mLastConfig = new InterestingConfigChanges();
final PackageManager mPm;
List<AppEntry> mApps;
PackageIntentReceiver mPackageObserver;
public AppListLoader(Context context) {
super(context);
// Retrieve the package manager for later use; note we don't
// use 'context' directly but instead the save global application
// context returned by getContext().
mPm = getContext().getPackageManager();
}
//實際上最重要的就是這個方法了，每當這個回撥方法被呼叫的時候 就去取applist 然後將結果返回到
//onLoadFinished 這個回撥方法裡面！
@Override public List<AppEntry> loadInBackground() {
// Retrieve all known applications.
List<ApplicationInfo> apps = mPm.getInstalledApplications(
PackageManager.GET_UNINSTALLED_PACKAGES |
PackageManager.GET_DISABLED_COMPONENTS);
if (apps == null) {
apps = new ArrayList<ApplicationInfo>();
}
final Context context = getContext();
// Create corresponding array of entries and load their labels.
List<AppEntry> entries = new ArrayList<AppEntry>(apps.size());
for (int i=0; i<apps.size(); i++) {
AppEntry entry = new AppEntry(this, apps.get(i));
entry.loadLabel(context);
entries.add(entry);
}
// Sort the list.
Collections.sort(entries, ALPHA_COMPARATOR);
// Done!
return entries;
}
/**
* Called when there is new data to deliver to the client. The
* super class will take care of delivering it; the implementation
* here just adds a little more logic.
*/
@Override public void deliverResult(List<AppEntry> apps) {
if (isReset()) {
// An async query came in while the loader is stopped. We
// don't need the result.
if (apps != null) {
onReleaseResources(apps);
}
}
List<AppEntry> oldApps = mApps;
mApps = apps;
if (isStarted()) {
// If the Loader is currently started, we can immediately
// deliver its results.
super.deliverResult(apps);
}
// At this point we can release the resources associated with
// 'oldApps' if needed; now that the new result is delivered we
// know that it is no longer in use.
if (oldApps != null) {
onReleaseResources(oldApps);
}
}
/**
* Handles a request to start the Loader.
*/
@Override protected void onStartLoading() {
if (mApps != null) {
// If we currently have a result available, deliver it
// immediately.
deliverResult(mApps);
}
// Start watching for changes in the app data.
if (mPackageObserver == null) {
mPackageObserver = new PackageIntentReceiver(this);
}
// Has something interesting in the configuration changed since we
// last built the app list?
boolean configChange = mLastConfig.applyNewConfig(getContext().getResources());
if (takeContentChanged() || mApps == null || configChange) {
// If the data has changed since the last time it was loaded
// or is not currently available, start a load.
forceLoad();
}
}
/**
* Handles a request to stop the Loader.
*/
@Override protected void onStopLoading() {
// Attempt to cancel the current load task if possible.
cancelLoad();
}
/**
* Handles a request to cancel a load.
*/
@Override public void onCanceled(List<AppEntry> apps) {
super.onCanceled(apps);
// At this point we can release the resources associated with 'apps'
// if needed.
onReleaseResources(apps);
}
/**
* Handles a request to completely reset the Loader.
*/
@Override protected void onReset() {
super.onReset();
// Ensure the loader is stopped
onStopLoading();
// At this point we can release the resources associated with 'apps'
// if needed.
if (mApps != null) {
onReleaseResources(mApps);
mApps = null;
}
// Stop monitoring for changes.
if (mPackageObserver != null) {
getContext().unregisterReceiver(mPackageObserver);
mPackageObserver = null;
}
}
/**
* Helper function to take care of releasing resources associated
* with an actively loaded data set.
*/
protected void onReleaseResources(List<AppEntry> apps) {
// For a simple List<> there is nothing to do. For something
// like a Cursor, we would close it here.
}
}
好，到這裡流程就很明顯了，在loader裡 註冊廣播接收器，當廣播接收器 收到廣播以後 就呼叫loader的onContentChanged方法，這個方法一呼叫 AppListLoader裡的loadInBackGround就會被呼叫，然後當loadInBackGround執行完畢以後 就會把結果傳遞給onLoadFinished方法了。 搞清楚這個流程 你就真正學會了使用loader這個大殺器了。當然了，我們並不滿足於此，loader還有一個特性就是可以自動管理他自己的生命週期 等等。我們現在就去看看他的原始碼，是如何完成這一點的。 並且上述幾個方法之間是如何相互呼叫的，順序如何。
首先 我們要搞清楚幾個類之間的關係：
public class CursorLoader extends AsyncTaskLoader<Cursor> {
public abstract class AsyncTaskLoader<D> extends Loader<D> {
public class Loader<D> {
這樣就很清晰。首先由一個實體類作為最基礎的基類，Loader 注意他可以接受一個泛型為引數，然後有一個抽象類：AsyncTaskLoader 也是泛型作為引數。
最後實際呼叫運作的類就是CursorLoader類了，這裡就可以看出來 傳進去的泛型是一個Cursor。你在自定義Loader的時候，這個泛型引數 當然是可以自己決定的，
比如官方demo裡 傳的就是一個List。
搞清楚 他們三者之間的關係，剩下的就簡單多了。可以逐步分析了。
在前面的3個demo裡，我們分別演示了在fragment和activity裡 呼叫loader的方法。 那我們就看看 這兩者之間有什麼異同點。先來看fragment。
fragment裡 我們是這樣呼叫的：
//這個地方初始化了我們的loader getLoaderManager().initLoader(0, null, this);
直接get了一個manager 然後init他。我們進去看fragment的原始碼：
//這邊就能看出來一個fragment只能有一個loadermanager了。
public LoaderManager getLoaderManager() {
if (mLoaderManager != null) {
return mLoaderManager;
}
//mHost很好理解 就是fragment的宿主，也就是跟fragment 相關聯的activity。
if (mHost == null) {
throw new IllegalStateException("Fragment " + this + " not attached to Activity");
}
mCheckedForLoaderManager = true;
mLoaderManager = mHost.getLoaderManager(mWho, mLoadersStarted, true);
return mLoaderManager;
}
既然 我們知道 fragment的getLoaderManager也是通過activity的getLoader去呼叫的，那我們就去activity裡的原始碼看看 ：
//在activty中最終實際上呼叫的就是他了 是這個方法
LoaderManagerImpl getLoaderManagerImpl() {
if (mLoaderManager != null) {
return mLoaderManager;
}
mCheckedForLoaderManager = true;
mLoaderManager = getLoaderManager("(root)", mLoadersStarted, true /*create*/);
return mLoaderManager;
}
//這個地方就能看到 主要的第一個引數 who，你到這就能發現 如果是activity自己呼叫的話，傳進去的who的值就是root
//也就是說一個actvity 只能有一個loadermanger 但是我們可以發現在fragment裡 傳進去的值是下面這個：
// Internal unique name for this fragment;
//String mWho;
//也就是說每一個fragment的mWho的值都是唯一的，而在activty中，是維護了一個map，一個key 對應一個loadermanager
//key就是fragment的那個唯一的標示，或者是activity自己，activity自己的標示就是（root)了
LoaderManagerImpl getLoaderManager(String who, boolean started, boolean create) {
if (mAllLoaderManagers == null) {
mAllLoaderManagers = new ArrayMap<String, LoaderManager>();
}
LoaderManagerImpl lm = (LoaderManagerImpl) mAllLoaderManagers.get(who);
if (lm == null) {
if (create) {
lm = new LoaderManagerImpl(who, this, started);
mAllLoaderManagers.put(who, lm);
}
} else {
lm.updateHostController(this);
}
return lm;
}
好 一直到這裡 ，我們就可以下一個結論了，真正的loadermanager都是儲存在activity中的，包括fragment的loadermanager也是，通過一個map來保證 get的時候取的manager是自己對應的，並且全域性唯一。繼續往下看：
public abstract class LoaderManager {
/**
* Callback interface for a client to interact with the manager.
*/
public interface LoaderCallbacks<D> {
/**
* Instantiate and return a new Loader for the given ID.
*
* @param id The ID whose loader is to be created.
* @param args Any arguments supplied by the caller.
* @return Return a new Loader instance that is ready to start loading.
*/
public Loader<D> onCreateLoader(int id, Bundle args);
/**
* Called when a previously created loader has finished its load. Note
* that normally an application is <em>not</em> allowed to commit fragment
* transactions while in this call, since it can happen after an
* activity's state is saved. See {@link FragmentManager#beginTransaction()
* FragmentManager.openTransaction()} for further discussion on this.
*
* <p>This function is guaranteed to be called prior to the release of
* the last data that was supplied for this Loader. At this point
* you should remove all use of the old data (since it will be released
* soon), but should not do your own release of the data since its Loader
* owns it and will take care of that. The Loader will take care of
* management of its data so you don't have to. In particular:
*
* <ul>
* <li> <p>The Loader will monitor for changes to the data, and report
* them to you through new calls here. You should not monitor the
* data yourself. For example, if the data is a {@link android.database.Cursor}
* and you place it in a {@link android.widget.CursorAdapter}, use
* the {@link android.widget.CursorAdapter#CursorAdapter(android.content.Context,
* android.database.Cursor, int)} constructor <em>without</em> passing
* in either {@link android.widget.CursorAdapter#FLAG_AUTO_REQUERY}
* or {@link android.widget.CursorAdapter#FLAG_REGISTER_CONTENT_OBSERVER}
* (that is, use 0 for the flags argument). This prevents the CursorAdapter
* from doing its own observing of the Cursor, which is not needed since
* when a change happens you will get a new Cursor throw another call
* here.
* <li> The Loader will release the data once it knows the application
* is no longer using it. For example, if the data is
* a {@link android.database.Cursor} from a {@link android.content.CursorLoader},
* you should not call close() on it yourself. If the Cursor is being placed in a
* {@link android.widget.CursorAdapter}, you should use the
* {@link android.widget.CursorAdapter#swapCursor(android.database.Cursor)}
* method so that the old Cursor is not closed.
* </ul>
*
* @param loader The Loader that has finished.
* @param data The data generated by the Loader.
*/
public void onLoadFinished(Loader<D> loader, D data);
/**
* Called when a previously created loader is being reset, and thus
* making its data unavailable. The application should at this point
* remove any references it has to the Loader's data.
*
* @param loader The Loader that is being reset.
*/
public void onLoaderReset(Loader<D> loader);
}
一看就知道 loadermanger 其實是一個抽象類。就是定義了一些 我們需要的介面而已，這些介面方法的含義和用法 在那3個demo裡 相信大家都有了解，不多說。
我們去看看這個抽象類的實現類，為什麼要看他，因為你在get到這個maganger以後 馬上就去呼叫了他的init方法 我們就看看這部分的邏輯是怎麼樣的：
public <D> Loader<D> initLoader(int id, Bundle args, LoaderManager.LoaderCallbacks<D> callback) {
if (mCreatingLoader) {
throw new IllegalStateException("Called while creating a loader");
}
//這個就是先看看是否有活動的loader 有的話就取出來 沒有的話 就建立一個
LoaderInfo info = mLoaders.get(id);
if (DEBUG) Log.v(TAG, "initLoader in " + this + ": args=" + args);
if (info == null) {
// Loader doesn't already exist; create.
info = createAndInstallLoader(id, args, (LoaderManager.LoaderCallbacks<Object>)callback);
if (DEBUG) Log.v(TAG, " Created new loader " + info);
} else {
if (DEBUG) Log.v(TAG, " Re-using existing loader " + info);
info.mCallbacks = (LoaderManager.LoaderCallbacks<Object>)callback;
}
if (info.mHaveData && mStarted) {
// If the loader has already generated its data, report it now.
info.callOnLoadFinished(info.mLoader, info.mData);
}
return (Loader<D>)info.mLoader;
}
//這個就是現在存活的loader
final SparseArray<LoaderInfo> mLoaders = new SparseArray<LoaderInfo>(0);
//這個是已經執行結束的loader
final SparseArray<LoaderInfo> mInactiveLoaders = new SparseArray<LoaderInfo>(0);
//其實這個建立loader的過程特別簡單，我們主要看第三個引數，callback 這個引數
//一想就明白，在前面3個demo裡我們是直接在fragemet和activity裡實現的callback
//所以傳進去的就是this，也就是說 回撥就是在這個函式裡 真正的和loader 發生了關聯了
private LoaderInfo createAndInstallLoader(int id, Bundle args,
LoaderManager.LoaderCallbacks<Object> callback) {
try {
mCreatingLoader = true;
LoaderInfo info = createLoader(id, args, callback);
installLoader(info);
return info;
} finally {
mCreatingLoader = false;
}
}
你看 一直到這裡，我們就明白了 callback是怎麼和loadermageer本身發生關聯的。 我們繼續往下看。這次我們要搞明白當資料來源發生變化的時候 是怎麼一步步回撥我們子類loader的方法的。
我們先看Loader這個基類的主要方法：
//這個是一個觀察者 當發生變化的時候 他呼叫了onContentChanged方法
public final class ForceLoadContentObserver extends ContentObserver {
public ForceLoadContentObserver() {
super(new Handler());
}
@Override
public boolean deliverSelfNotifications() {
return true;
}
@Override
public void onChange(boolean selfChange) {
onContentChanged();
}
}
//下面這2個方法一看就明白 最終當資料來源發生變化的時候 會通知這個觀察者，然後這個觀察者會最終呼叫
//onForceLoad這個方法 而onForceLoad是交給子類去實現的 也就是AsyncTaskLoader的onForceLoad方法了
public void onContentChanged() {
if (mStarted) {
forceLoad();
} else {
// This loader has been stopped, so we don't want to load
// new data right now... but keep track of it changing to
// refresh later if we start again.
mContentChanged = true;
}
}
public void forceLoad() {
onForceLoad();
}
/**
* Subclasses must implement this to take care of requests to {@link #forceLoad()}.
* This will always be called from the process's main thread.
*/
protected void onForceLoad() {
}
然後看看AsyncTaskLoader的幾個主要方法：
//這邊一目瞭然 asynacTaskLoader 裡面 正好是有一個AsyncTask物件的！實現了runnabele介面
//注意著引數d 這個d是幹嘛的，這個d就是用來傳遞引數的一個泛型，可以是系統實現的loader裡的cursor
//也可以是我們自己實現的loader裡的list型別
final class LoadTask extends AsyncTask<Void, Void, D> implements Runnable {
private final CountDownLatch mDone = new CountDownLatch(1);
// Set to true to indicate that the task has been posted to a handler for
// execution at a later time. Used to throttle updates.
boolean waiting;
/* Runs on a worker thread */
@Override
protected D doInBackground(Void... params) {
if (DEBUG) Log.v(TAG, this + " >>> doInBackground");
try {
//這個地方就很明顯了，他呼叫了自己的onLoadInBackGround方法
D data = AsyncTaskLoader.this.onLoadInBackground();
if (DEBUG) Log.v(TAG, this + " <<< doInBackground");
return data;
} catch (OperationCanceledException ex) {
if (!isCancelled()) {
// onLoadInBackground threw a canceled exception spuriously.
// This is problematic because it means that the LoaderManager did not
// cancel the Loader itself and still expects to receive a result.
// Additionally, the Loader's own state will not have been updated to
// reflect the fact that the task was being canceled.
// So we treat this case as an unhandled exception.
throw ex;
}
if (DEBUG) Log.v(TAG, this + " <<< doInBackground (was canceled)", ex);
return null;
}
}
//後面還有很多程式碼 略過
}
//你看這裡下面的2個函式 一看就明白了 最終task裡呼叫的是這個抽象方法，那這個抽象方法
//就是留給我們子類自己去實現的，我們在自定義loader的時候最重要的就是重寫這個方法。
protected D onLoadInBackground() {
return loadInBackground();
}
public abstract D loadInBackground();
//你看這個地方 就是當資料來源發生變化的時候 就會呼叫這個方法了，啟動了我們的laodtask
//也是最終呼叫子類 也就是CursorLoader這樣的子類的loadInBackground方法了
@Override
protected void onForceLoad() {
super.onForceLoad();
cancelLoad();
mTask = new LoadTask();
if (DEBUG) Log.v(TAG, "Preparing load: mTask=" + mTask);
executePendingTask();
}
相信到這裡 大家一定能搞明白資料來源變化的時候 是怎麼一步步呼叫我們的loader裡的回撥方法的，那有人肯定要繼續問當你這個方法呼叫完畢的時候 是怎麼通知最後updateUI呢，也就是當你background方法結束以後是怎麼呼叫的onLoadFinished方法的呢？
我們繼續看AsyncTaskLoader這個類
//在那個asynctask裡面 走完是肯定要走這個方法的 相信大家都能理解。
@Override
protected void onPostExecute(D data) {
if (DEBUG) Log.v(TAG, this + " onPostExecute");
try {
AsyncTaskLoader.this.dispatchOnLoadComplete(this, data);
} finally {
mDone.countDown();
}
}
//實際上走的就是這個方法。看26行-
void dispatchOnLoadComplete(LoadTask task, D data) {
if (mTask != task) {
if (DEBUG) Log.v(TAG, "Load complete of old task, trying to cancel");
dispatchOnCancelled(task, data);
} else {
if (isAbandoned()) {
// This cursor has been abandoned; just cancel the new data.
onCanceled(data);
} else {
commitContentChanged();
mLastLoadCompleteTime = SystemClock.uptimeMillis();
mTask = null;
if (DEBUG) Log.v(TAG, "Delivering result");
deliverResult(data);
}
}
}
//這邊一下就看出來是呼叫的mListtenr的回撥方法
public void deliverResult(D data) {
if (mListener != null) {
mListener.onLoadComplete(this, data);
}
}
實際上這個Listener就是在Loader這個基類裡：
OnLoadCompleteListener<D> mListener;
public interface OnLoadCompleteListener<D> {
/**
* Called on the thread that created the Loader when the load is complete.
*
* @param loader the loader that completed the load
* @param data the result of the load
*/
public void onLoadComplete(Loader<D> loader, D data);
}
//並且通過這個註冊
public void registerListener(int id, OnLoadCompleteListener<D> listener) {
if (mListener != null) {
throw new IllegalStateException("There is already a listener registered");
}
mListener = listener;
mId = id;
}
那就好了 我們就是要看一下 是在哪個地方呼叫的registerlistener這個方法 註冊他的
//回到initLoader的這個方法 注意這個方法是在LoaderManger裡面
public <D> Loader<D> initLoader(int id, Bundle args, LoaderManager.LoaderCallbacks<D> callback) {
if (mCreatingLoader) {
throw new IllegalStateException("Called while creating a loader");
}
LoaderInfo info = mLoaders.get(id);
if (DEBUG) Log.v(TAG, "initLoader in " + this + ": args=" + args);
if (info == null) {
//下面的程式碼跳轉到30行
info = createAndInstallLoader(id, args, (LoaderManager.LoaderCallbacks<Object>)callback);
if (DEBUG) Log.v(TAG, " Created new loader " + info);
} else {
if (DEBUG) Log.v(TAG, " Re-using existing loader " + info);
info.mCallbacks = (LoaderManager.LoaderCallbacks<Object>)callback;
}
if (info.mHaveData && mStarted) {
// If the loader has already generated its data, report it now.
info.callOnLoadFinished(info.mLoader, info.mData);
}
return (Loader<D>)info.mLoader;
}
private LoaderInfo createAndInstallLoader(int id, Bundle args,
LoaderManager.LoaderCallbacks<Object> callback) {
try {
mCreatingLoader = true;
LoaderInfo info = createLoader(id, args, callback);
//這裡跳轉到43行
installLoader(info);
return info;
} finally {
mCreatingLoader = false;
}
}
void installLoader(LoaderInfo info) {
mLoaders.put(info.mId, info);
if (mStarted) {
//跳轉到51行
info.start();
}
}
void start() {
if (mRetaining && mRetainingStarted) {
// Our owner is started, but we were being retained from a
// previous instance in the started state... so there is really
// nothing to do here, since the loaders are still started.
mStarted = true;
return;
}
if (mStarted) {
// If loader already started, don't restart.
return;
}
mStarted = true;
if (DEBUG) Log.v(TAG, " Starting: " + this);
if (mLoader == null && mCallbacks != null) {
mLoader = mCallbacks.onCreateLoader(mId, mArgs);
}
if (mLoader != null) {
if (mLoader.getClass().isMemberClass()
&& !Modifier.isStatic(mLoader.getClass().getModifiers())) {
throw new IllegalArgumentException(
"Object returned from onCreateLoader must not be a non-static inner member class: "
+ mLoader);
}
if (!mListenerRegistered) {
//就是在這裡註冊的mloader裡的回撥了，注意這裡的引數是this 也就是loaderInfo這個類 注意這個類就是loadermanger裡的內部類了 再繼續往下看
//我們前面說到 在asynctask裡面最終呼叫的是mLoader裡的onLoadComplete方法 所以我們就看看loaderInfo這個類裡的這個方法做了什麼看91行
mLoader.registerListener(mId, this);
mLoader.registerOnLoadCanceledListener(this);
mListenerRegistered = true;
}
mLoader.startLoading();
}
}
@Override
public void onLoadComplete(Loader<Object> loader, Object data) {
if (DEBUG) Log.v(TAG, "onLoadComplete: " + this);
if (mDestroyed) {
if (DEBUG) Log.v(TAG, " Ignoring load complete -- destroyed");
return;
}
if (mLoaders.get(mId) != this) {
// This data is not coming from the current active loader.
// We don't care about it.
if (DEBUG) Log.v(TAG, " Ignoring load complete -- not active");
return;
}
LoaderInfo pending = mPendingLoader;
if (pending != null) {
// There is a new request pending and we were just
// waiting for the old one to complete before starting
// it. So now it is time, switch over to the new loader.
if (DEBUG) Log.v(TAG, " Switching to pending loader: " + pending);
mPendingLoader = null;
mLoaders.put(mId, null);
destroy();
installLoader(pending);
return;
}
// Notify of the new data so the app can switch out the old data before
// we try to destroy it.
if (mData != data || !mHaveData) {
mData = data;
mHaveData = true;
if (mStarted) {
//繼續往下 看第149行
callOnLoadFinished(loader, data);
}
}
//if (DEBUG) Log.v(TAG, " onLoadFinished returned: " + this);
// We have now given the application the new loader with its
// loaded data, so it should have stopped using the previous
// loader. If there is a previous loader on the inactive list,
// clean it up.
LoaderInfo info = mInactiveLoaders.get(mId);
if (info != null && info != this) {
info.mDeliveredData = false;
info.destroy();
mInactiveLoaders.remove(mId);
}
if (mHost != null && !hasRunningLoaders()) {
mHost.mFragmentManager.startPendingDeferredFragments();
}
}
void callOnLoadFinished(Loader<Object> loader, Object data) {
if (mCallbacks != null) {
String lastBecause = null;
if (mHost != null) {
lastBecause = mHost.mFragmentManager.mNoTransactionsBecause;
mHost.mFragmentManager.mNoTransactionsBecause = "onLoadFinished";
}
try {
if (DEBUG) Log.v(TAG, " onLoadFinished in " + loader + ": "
+ loader.dataToString(data));
//到這裡就真相大白了，最終callback是在這裡呼叫的onLoadFinished方法也就是我們經常重寫的方法
mCallbacks.onLoadFinished(loader, data);
} finally {
if (mHost != null) {
mHost.mFragmentManager.mNoTransactionsBecause = lastBecause;
}
}
mDeliveredData = true;
}
}
好，到這裡 我們就把Loader框架中的 資料傳遞 整個流程給摸清楚了。最後我們再來看看 他的生命週期是如何管理的吧。
我們可以先看看activity的：
//看activity的onStart方法
protected void onStart() {
if (DEBUG_LIFECYCLE) Slog.v(TAG, "onStart " + this);
mCalled = true;
//繼續看12行 這個地方mFragements 你就理解成activity本身即可，不多做解釋 這個地方要搞清楚 又是另外一塊了 有興趣的可以自行谷歌activity和fragment如何建立關係
mFragments.doLoaderStart();
getApplication().dispatchActivityStarted(this);
}
//這個函式就很明顯了 呼叫了manager的dostart函式
void doLoaderStart() {
if (mLoadersStarted) {
return;
}
mLoadersStarted = true;
if (mLoaderManager != null) {
//跳轉到30行
mLoaderManager.doStart();
} else if (!mCheckedForLoaderManager) {
mLoaderManager = getLoaderManager("(root)", mLoadersStarted, false);
}
mCheckedForLoaderManager = true;
}
//------------------注意上面的程式碼都在activity裡，下面的開始 都在LoaderManger類裡了
void doStart() {
if (DEBUG) Log.v(TAG, "Starting in " + this);
if (mStarted) {
RuntimeException e = new RuntimeException("here");
e.fillInStackTrace();
Log.w(TAG, "Called doStart when already started: " + this, e);
return;
}
mStarted = true;
// Call out to sub classes so they can start their loaders
// Let the existing loaders know that we want to be notified when a load is complete
for (int i = mLoaders.size()-1; i >= 0; i--) {
//跳轉到50行
mLoaders.valueAt(i).start();
}
}
void start() {
if (mRetaining && mRetainingStarted) {
// Our owner is started, but we were being retained from a
// previous instance in the started state... so there is really
// nothing to do here, since the loaders are still started.
mStarted = true;
return;
}
if (mStarted) {
// If loader already started, don't restart.
return;
}
mStarted = true;
if (DEBUG) Log.v(TAG, " Starting: " + this);
if (mLoader == null && mCallbacks != null) {
//原來onCreateLoader這個回撥方法 是在這裡呼叫的 怪不得谷歌說這個方法是必定會被執行並且只會被執行一次的方法！
mLoader = mCallbacks.onCreateLoader(mId, mArgs);
}
if (mLoader != null) {
if (mLoader.getClass().isMemberClass()
&& !Modifier.isStatic(mLoader.getClass().getModifiers())) {
throw new IllegalArgumentException(
"Object returned from onCreateLoader must not be a non-static inner member class: "
+ mLoader);
}
if (!mListenerRegistered) {
mLoader.registerListener(mId, this);
mLoader.registerOnLoadCanceledListener(this);
mListenerRegistered = true;
}
//你看這裡呼叫了startLoading方法 這個方法是屬於mLoader的 跳轉到88行
mLoader.startLoading();
}
}
//88- 98行是loader這個類裡的
public final void startLoading() {
mStarted = true;
mReset = false;
mAbandoned = false;
onStartLoading();
}
//你看最終是呼叫的這個方法，注意他是空方法 是交給子類去實現的，我們去看看cursorloader這個子類是怎麼實現的吧。
protected void onStartLoading() {
}
//99- 112行 是cursorLoader這個類的程式碼
//你看這個地方 直接呼叫了forceload方法 這個方法大家前面肯定有印象 他最終會啟動那個asynctask 去執行background方法
//這也就解釋了 第一次我們的資料是怎麼來的，比如說 假設我們的資料來源還沒有被更新的時候，為什麼會自動去查詢資料來源 並返回資料
//到這裡就明白了，原來是activity的onStart函式為開端 一步步走到Loader的子類的onStartLoading方法裡的，當然你如果覺得
//Loader不需要初始載入 只要在有變化的時候再載入 那這個方法你就可以保持為空了。
protected void onStartLoading() {
if (mCursor != null) {
deliverResult(mCursor);
}
if (takeContentChanged() || mCursor == null) {
forceLoad();
}
}
//114-139行 為 http://developer.android.com/intl/zh-cn/reference/android/content/AsyncTaskLoader.html 這個裡面 AppListLoader 的一段原始碼
//你看138行 也是直接呼叫的forceLoad 這樣當我們的applist沒有變化的時候 第一次也能顯示出列表
/**
* Handles a request to start the Loader.
*/
@Override protected void onStartLoading() {
if (mApps != null) {
// If we currently have a result available, deliver it
// immediately.
deliverResult(mApps);
}
// Start watching for changes in the app data.
if (mPackageObserver == null) {
mPackageObserver = new PackageIntentReceiver(this);
}
// Has something interesting in the configuration changed since we
// last built the app list?
boolean configChange = mLastConfig.applyNewConfig(getContext().getResources());
if (takeContentChanged() || mApps == null || configChange) {
// If the data has changed since the last time it was loaded
// or is not currently available, start a load.
forceLoad();
}
}
start流程 我們分析完畢了 最後我們再看看stop流程吧 看完這個 其他生命週期 我們就不分析了留給讀者自己感興趣的話自己分析試試看。
//我們來看看fragment的onDestroy方法 都做了什麼
public void onDestroy() {
mCalled = true;
//Log.v("foo", "onDestroy: mCheckedForLoaderManager=" + mCheckedForLoaderManager
// + " mLoaderManager=" + mLoaderManager);
if (!mCheckedForLoaderManager) {
mCheckedForLoaderManager = true;
mLoaderManager = mHost.getLoaderManager(mWho, mLoadersStarted, false);
}
if (mLoaderManager != null) {
//跳轉到16行
mLoaderManager.doDestroy();
}
}
//上面的程式碼 是在fragment裡 下面的程式碼在loadermanger裡
void doDestroy() {
if (!mRetaining) {
if (DEBUG) Log.v(TAG, "Destroying Active in " + this);
for (int i = mLoaders.size()-1; i >= 0; i--) {
mLoaders.valueAt(i).destroy();
}
mLoaders.clear();
}
if (DEBUG) Log.v(TAG, "Destroying Inactive in " + this);
for (int i = mInactiveLoaders.size()-1; i >= 0; i--) {
mInactiveLoaders.valueAt(i).destroy();
}
mInactiveLoaders.clear();
}
//下面這個destroy流程 可以清晰的看到很多東西 包括clear所有回撥等
void destroy() {
if (DEBUG) Log.v(TAG, " Destroying: " + this);
mDestroyed = true;
boolean needReset = mDeliveredData;
mDeliveredData = false;
if (mCallbacks != null && mLoader != null && mHaveData && needReset) {
if (DEBUG) Log.v(TAG, " Reseting: " + this);
String lastBecause = null;
if (mHost != null) {
lastBecause = mHost.mFragmentManager.mNoTransactionsBecause;
mHost.mFragmentManager.mNoTransactionsBecause = "onLoaderReset";
}
try {
mCallbacks.onLoaderReset(mLoader);
} finally {
if (mHost != null) {
mHost.mFragmentManager.mNoTransactionsBecause = lastBecause;
}
}
}
mCallbacks = null;
mData = null;
mHaveData = false;
if (mLoader != null) {
if (mListenerRegistered) {
mListenerRegistered = false;
mLoader.unregisterListener(this);
mLoader.unregisterOnLoadCanceledListener(this);
}
//在這呼叫了rest
mLoader.reset();
}
if (mPendingLoader != null) {
mPendingLoader.destroy();
}
}
//最後我們來看看loader裡的程式碼 就能明白了 當fragement destroy的時候最終的呼叫來到了子類的onReset方法
public void reset() {
onReset();
mReset = true;
mStarted = false;
mAbandoned = false;
mContentChanged = false;
mProcessingChange = false;
}
/**
* Subclasses must implement this to take care of resetting their loader,
* as per {@link #reset()}. This is not called by clients directly,
* but as a result of a call to {@link #reset()}.
* This will always be called from the process's main thread.
*/
protected void onReset() {
}
//這裡是cURSORLOADER的程式碼了 你看這裡關閉了cursor
@Override
protected void onReset() {
super.onReset();
// Ensure the loader is stopped
onStopLoading();
if (mCursor != null && !mCursor.isClosed()) {
mCursor.close();
}
mCursor = null;
}
//同樣的 我們也能看到applistloader原始碼裡面 也是在這個函式裡清除了廣播接收器。
//所以讀到這裡 我們就知道 loader的強大了。你只需要搞清楚這些生命週期的函式的意義
//就可以重寫他們，至於什麼時候呼叫 loader都幫你做好了 你只需要在裡面實現你自己的邏輯即可！非常強大 非常好用
@Override protected void onReset() {
super.onReset();
// Ensure the loader is stopped
onStopLoading();
// At this point we can release the resources associated with 'apps'
// if needed.
if (mApps != null) {
onReleaseResources(mApps);
mApps = null;
}
// Stop monitoring for changes.
if (mPackageObserver != null) {
getContext().unregisterReceiver(mPackageObserver);
mPackageObserver = null;
}
}
相關文章
- Android 非同步載入神器Loader全解析Android非同步
- Android中-Loader載入器Android
- webpack3–loader全解析Web
- webpack3--loader全解析Web
- 使用bundle-loader非同步載入react-router非同步React
- webpack模組非同步載入原理解析Web非同步
- react非同步載入元件實現解析React非同步元件
- Android 非同步載入——AsyncTask詳談Android非同步
- webpack配置常用loader載入器Web
- Android Loader 機制，讓你的資料載入更加輕鬆Android
- Android實現圖片非同步載入操作Android非同步
- 用SQL*Loader載入外部資料SQL
- android ListView非同步載入圖片（雙快取）AndroidView非同步快取
- [原]Android官方圖片載入利器BitmapFun解析Android
- Android 動態載入資源例項解析Android
- 非阻塞載入指令碼指令碼
- Android動畫機制全解析Android動畫
- Android fragment原始碼全解析AndroidFragment原始碼
- Android ViewDragHelper完全解析 自定義ViewGroup神器AndroidView
- echarts非同步載入Echarts非同步
- dhtmlXTree非同步載入HTML非同步
- Android八門神器（一）：OkHttp框架原始碼解析AndroidHTTP框架原始碼
- Android基礎之Activity全解析Android
- RxJava 從入門到全解析RxJava
- 分享一款全網頁視訊下載神器網頁
- webpack 非同步載入原理Web非同步
- 同步非同步，阻塞非阻塞非同步
- 非同步、同步、阻塞、非阻塞非同步
- 同步、非同步、阻塞、非阻塞非同步
- webpack loader—自己寫一個按需載入外掛Web
- Viper解析&載入配置
- AssetBoundle載入非預設資源
- Android記憶體優化全解析Android記憶體優化
- 深入原始碼解析Android中Loader、AsyncTaskLoader、CursorLoader、LoaderManager原始碼Android
- （課程學習）Android必學-非同步載入 —— 監聽 ListViewAndroid非同步View
- android listview 滾動時非同步載入圖片的問題AndroidView非同步
- webpack loader配置全流程詳解Web
- Google Android 真機展示視訊,非全鍵盤GoAndroid