Android的加載器（loader）是從Android 3.0開始出來的東西。要理解這裡需要先理解為什麼會出現加載器（也有地方把它說成是裝載器）呢？
首先Activity是我們的前端頁面展現，數據庫是我們的數據持久化地址，那麼正常的邏輯就是在展示頁面的渲染頁面的階段進行數據庫查詢。拿到數據以後才展示頁面。
但是這個邏輯有一些缺點：
首先是查詢數據的邏輯放在了UI生成的同個線程中，這個就意味著在查詢數據的時候，UI頁面生成的工作被阻塞住了。UI一旦被阻塞用戶就會被感知出來了，因此就會出現各種無相應頁面（Application Not Response），或者activity頁面延遲的現象，這對用戶體驗來說是不可接受的。
其次是在渲染頁面的時候需要固定需要進行一次數據查詢，但是這個是很不節省資源的。假如一個Activity從一個停止狀態回到前台，那麼這個時候盡管數據並沒有變化，但是也需要進行一次query操作。在浪費資源的同時也再次增加了頁面渲染失敗的風險。
還有就是當數據變化的時候如何通知頁面進行修改呢？這個時候往往就又要創建一個monitor的角色，來當數據源變化的時候來讓頁面重新調用requery。
因此在Android的越來越提倡用戶體驗的今天，加載器和加載管理器（Loader，LoaderManager）就出現了。
簡單來說，Loader做了下面兩個事情：
而LoaderManager就是加載器的管理器，一個LoaderManager可以管理一個或多個Loader，一個Activity或者Fragment只能有一個LoadManager。LoaderManager管理Loader的初始化，重啟和銷毀操作。
從官網http://developer.android.com/reference/android/app/LoaderManager.html就可以看出它包含的方法有：
對應的就是這幾個操作。
initLoader是初始化一個加載器，它的第三個參數是一個LoaderCallbacks<D>接口，LoaderManager的initLoader是不做任何事情的，它只綁定了一個LoaderCallbacks<D>，具體的創建Loader的事情是由這個callback來做的。
LoaderCallbacks<D>接口需要實現的三個方法：
在loader創建loader的時候會調用onCreateLoader，然後當load數據結束的時候（第一次讀取數據或者數據有改變的時候load數據）會調用onLoadFinished，而onLoaderReset只有在destory一個loader的時候才有可能調用。
所以一般創建數據Cursor（CursorLoader）的工作是在onCreateLoader中做，將CursorLoader返回，這樣就創建了對這個數據源的監控，當數據源有數據變化的時候，就會自動調用了onLoadFinished函數了。
更多詳情見請繼續閱讀下一頁的精彩內容：http://www.linuxidc.com/Linux/2013-09/90127p2.htm