LoaderManager

外部接口initLoader：起始

     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) {
             // 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;
     }

mCreatingLoader代表當前LoaderManager正處於創建Loader的狀態，這個時候進入initLoader屬於衝突。
LoaderInfo爲LoaderManager內部保存Loader信息的一個類，mLoaders保存了此LoaderManager加載過的Loader，需要注意：一個ID對應一個Loader。
info獲取不到，說明這次是一個新的Loader進來，需要通過createAndInstallLoader進行創建和安裝，參數即爲initLoader的參數。
如果獲取到了info，說明這是一個已經存在過的Loader，只需要重新對callback回調進行重新賦值即可。
若獲取到的Loader已經開始，並且產生了有效數據，則執行LoaderInfo的callOnLoadFinished方法上報數據。
最終返回LoaderInfo中的Loader信息。

LoaderInfo聲明瞭Loader.OnLoadCompleteListener接口，並且保存了一個Loader的幾乎所有信息和狀態。

LoaderInfo的構造函數

 public LoaderInfo(int id, Bundle args, LoaderManager.LoaderCallbacks<Object> callbacks) {
     mId = id;
     mArgs = args;
     mCallbacks = callbacks;
 }

createAndInstallLoader

 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;
      }
 }

createLoader

 private LoaderInfo createLoader(int id, Bundle args,
         LoaderManager.LoaderCallbacks<Object> callback) {
     LoaderInfo info = new LoaderInfo(id, args,  (LoaderManager.LoaderCallbacks<Object>)callback);
     Loader<Object> loader = callback.onCreateLoader(id, args);
     info.mLoader = (Loader<Object>)loader;
     return info;
 }

通過調用callback的onCreateLoader接口創建Loader。這樣一個描述Loader的LoaderInfo就被成功創建了。完成了創建後，接下來是安裝。

installLoader

void installLoader(LoaderInfo info) {
    mLoaders.put(info.mId, info);
    if (mStarted) {
        // The activity will start all existing loaders in it's onStart(),
        // so only start them here if we're past that point of the activitiy's
        // life cycle
        info.start();
    }
}

將新的Loader裝進mLoaders保存，凡是通過此LoaderManager管理過的Loader都會有記錄的
即使是在Fragment中使用LoaderManager，其獲取方式也是通過Fragment附屬的Activity獲取，而mStarted狀態量與Activity的生命週期onStart/onStop有關。稍後做詳細分析。
若Activity的生命週期處於onStart和onStop中，則開啓Loader。

LoaderInfo的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.registerListener(mId, this);
                     mListenerRegistered = true;
                 }
                 mLoader.startLoading();
             }
         }

如果Loader還處於上一個的開始狀態中，就不做任何事情
如果已經開始了，不要重啓
若Loader爲null，則調用callback的接口再創建一個
註冊Loader的監聽器，以id爲唯一標識
啓動Loader

Loader的startLoading()

 public final void startLoading() {
     mStarted = true;
     mReset = false;
     mAbandoned = false;
     onStartLoading();
 }

會啓動Loader的onStartLoading，如果是複寫的Loader或者AsyncTaskLoader，就是執行到了這裏，是Loader在構造後執行的第一道工序。

關於結果數據的Loader回調

在LoaderInfo中給Loader註冊了回調，回調就是LoaderInfo本身。下邊以AsyncTaskLoader爲例進行分析。

AsyncTaskLoader繼承於Loader，同時其內部完成了一個AsyncTask。AsyncTaskLoader的抽象接口

public abstract D loadInBackground();

其實就是運行在其內部的AsyncTask中的doInBackground。

PS: 繼承於AsyncTaskLoader的Loader不會在構造後自動啓動，需要覆寫onStartLoading中執行forceLoad，此Loader纔會在onStartLoading的生命週期時正常啓動。

在其內部的AsyncTask完成後會在onPostExecute中調用AsyncTaskLoader的dispatchOnLoadComplete

 void dispatchOnLoadComplete(LoadTask task, D data) {
     if (mTask != task) {
         if (DEBUG) Slog.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) Slog.v(TAG, "Delivering result");
             deliverResult(data);
         }
     }
 }

如果完成的是舊任務，則取消掉
isAbandoned是Loader的方法，通過主動調用Loader的abandon()方法可以放棄這個Loader的執行結果，如果此Loader已經被放棄，那麼調用
```
  public void onCanceled(D data)
```
處理被去掉的數據，AsyncTaskLoader中沒有做任何處理，留給繼承者自行決定是否處理

排除以上兩種異常情況，正常時會調用Loader的deliverResult處理數據結果。

public void deliverResult(D data) {
        if (mListener != null) {
             mListener.onLoadComplete(this, data);
         }
}

之前分析過的LoaderInfo爲自己的Loader註冊了監聽器，實現是自己，這下子數據就傳遞回去了：

  @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) {
             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 (mActivity != null && !hasRunningLoaders()) {
         mActivity.mFragments.startPendingDeferredFragments();
     }
 }

若LoaderInfo已經通過destroy()進行過銷燬，則不處理任何事情
若回傳的Loader與LoaderInfo描述的並不是一個，也不做任何處理
mPendingLoader在LoaderManager的restartLoader中被賦值。若之前LoaderInfo中的Loader已經開始了，那麼會新建一個Loader給LoaderInfo作爲等待，在這裏，如果有等待着的Loader則直接廢棄之前的Loader，把等待的Loader扶正。同樣的，返回的數據也就不進行任何處理了。
如果是新數據，且Loader生命週期正常，則調用callOnLoadFinished對數據進行處理，這裏調用了回調函數callback中的onLoadFinished
mInactiveLoaders用來保存不活躍的Loader，如果Loader不活躍了，LoaderManager並不會馬上刪除它，而是將其保存在mInactiveLoaders中，直到此Loader的新數據來了，就將其銷燬掉。

LoaderManager與生命週期

Activity和Fragment都擁有getLoaderManager的方法，其實Fragment的getLoaderManager去獲取的就是Activity所管理的衆多LoaderManager之一。

Who標籤

先來看一下Activity的getLoaderManager方法：

     LoaderManagerImpl getLoaderManager(String who, boolean started, boolean create) {
         if (mAllLoaderManagers == null) {
             mAllLoaderManagers = new ArrayMap<String, LoaderManagerImpl>();
         }
         LoaderManagerImpl lm = mAllLoaderManagers.get(who);
         if (lm == null) {
             if (create) {
                 lm = new LoaderManagerImpl(who, this, started);
                 mAllLoaderManagers.put(who, lm);
             }
         } else {
             lm.updateActivity(this);
         }
         return lm;
     }

mAllLoaderManagers保存着一個Activity所擁有的所有LoaderManager，其key爲String類型的who變量。若從Activity調用getLoaderManager，那麼所得LoaderManager的who標籤爲(root):

     public LoaderManager getLoaderManager() {
         if (mLoaderManager != null) {
             return mLoaderManager;
         }
         mCheckedForLoaderManager = true;
         mLoaderManager = getLoaderManager("(root)", mLoadersStarted, true);
         return mLoaderManager;
     }

若從Fragment中使用getLoaderManager，則所得LoaderManager的who標籤會根據Fragment的層級不同而不同，在Activity中處於最頂級的Fragment的who標籤爲：

android:fragment:X

X爲序號。

而屬於Fragment的Fragment所活的的LoaderManager who標籤就成爲了：

android:fragment:X:Y

甚至更大的深度。

LoaderManager狀態量mLoadersStarted

在開篇分析的時候分析過LoaderManager內部保存了一個mStarted狀態，很多操作會根據這個狀態做不同處理。通過上邊的分析也能看出，Fragment中獲取LoaderManager最終是通過Activity獲取的，在LoaderManager構造時，就將一個狀態量mLoadersStarted傳遞了進去，這個狀態量交給LoaderManager自行管理。

而無論是Fragment還是Activity，都有mLoadersStarted這樣一個狀態量，在onStart生命週期後爲true，onStop後爲false。所以在onStart生命週期後做initLoader操作就會使Loader一經初始化就開始運行了。

Fragment和Activity的生命週期

Fragment和Activity能夠對LoaderManager產生影響的生命週期是一樣的。

onStart

系統在onStart階段會獲取LoaderManager，如果成功獲取，則調用LoaderManager的doStart()，這裏需要特別說明的是，雖然所有LoaderManager都是保存在Activity中，但是在Activity的onStart生命週期其也只是會獲取屬於自己的(root)標籤LoaderManager，而並不是將所有保存在mAllLoaderManagers裏的Manager全部遍歷一遍。

onStop（performStop）

處於onStop生命週期，但是系統內部是通過performStop調用的。在這裏，同樣會獲取屬於自己的LoaderManager，如果Activity是因爲配置改變出發的onStop（旋轉屏幕），則調用LoaderManager的doRetain()接口，如果不是，就調用LoaderManager的doStop()接口。

onDestroy(performDestroy)

調用LoaderManager的doDestroy()接口銷燬LoaderManager。

LoaderManager的生命週期

因爲LoaderManager與Fragment/Activity的生命週期緊密相連，所以想要用好LoaderManager就必須瞭解其自身的生命週期，這樣就能把握數據的完整變化規律了。

正常的從出生到銷燬：

doStart() -> doReportStart() -> doStop() -> doDestroy()

Activity配置發生變化：

doStart() -> doRetain() -> finishRetain() -> doReportStart() -> doStart() -> doStop() -> doDestroy()

Fragment在onDestroyView()之後還會執行LoaderManager的doReportNextStart(), 即：

doStart() -> doRetain() -> doReportNextStart() -> finishRetain() -> doReportStart() -> doStart() -> doStop() -> doDestroy()

doStart()會將LoaderManager中保存的所有Loader都啓動。最終是運行每一個Loader的onStartLoading()方法。只要是通過initLoader使用過的Loader都會記錄在LoaderManager的mLoaders中，那麼問題來了：

怎樣在Fragment/Activity不銷燬的前提下從LoaderManager中移除某個使用過的Loader呢？

答案就是使用LoaderManager的接口去除指定ID的Loader：
```
 public void destroyLoader(int id)
```
這樣就能在mLoaders中移除掉了，下次onStart的時候就沒有這個Loader什麼事了。
doReportStart()。如果Fragment上一次在銷燬並重做，而且數據有效的話會在這裏主動上報數據，最終走到callback的onLoadFinished中。
doStop()會停止mLoaders保存的所有Loader。最終是運行每一個Loader的onStopLoading()方法。
doDestroy()會清空所有有效和無效Loader，LoaderManager中不再存在任何Loader。
doRetain()會將LoaderManager的mRetaining狀態置位true，並且保存retain時LoaderInfo的mStarted狀態
finishRetain()如果之前所保存的mStarted與現在的不一樣而且新的狀態是停止的話，就停止掉這個Loader。否則若有數據並且不是要下次再上報（沒有call doReportNextStart）的話就上報給callback的onLoadFinished。
doReportNextStart()，根據第6條，已經能夠理解了。當Fragment執行到onDestroyView生命週期時，對自己的LoaderManager發出請求：即使現在有數據也不要進行上報，等我重做再到onStart生命週期時再給我。

外部接口：restartLoader

在熟知了LoaderManager的梗概之後最後分析restartLoader就能夠更好理解了：

public <D> Loader<D> restartLoader(int id, Bundle args, LoaderManager.LoaderCallbacks<D> callback)

若此ID對應的Loader之前使用過，則去除這個Loader，如果這個Loader不在運行中，則銷燬它然後重新創建一個Loader；如果在運行中，則創建一個Loader等待在這個Loader後邊
若此ID的Loader是新的，之前並沒有使用過，則創建這個Loader，同initLoader。

Android應用開發：LoaderManager在Activity/Fragment中的使用分析

LoaderManager

外部接口initLoader：起始

關於結果數據的Loader回調

LoaderManager與生命週期

Who標籤

LoaderManager狀態量mLoadersStarted

Fragment和Activity的生命週期

onStart

onStop（performStop）

onDestroy(performDestroy)

LoaderManager的生命週期

外部接口：restartLoader

Python實現大麥網搶票的四大關鍵技術點解析

salesforce零基礎學習（一百三十八）零碎知識點小總結（十）

一款開源的.NET程序集反編譯、編輯和調試神器

關於接口協議，你必須要知道這些！

APT知識整合學習——反射篇

APT知識整合學習——開篇

訪問者設計模式Visitor

常用開源協議BSD/APACHE/GPL/LGPL/CPL/MIT概述

Android應用開發：社會化平臺登錄接入

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結