我們一起來總結一下Network MVC模式的優點：
·提升UI整體性能，通過緩存提升實際性能是該模式的最大優勢。移動編程往往在實現上類似於Web編程，缺乏緩存系統。
·在內存中保存數據不是好的方式，因為你不知道Android何時會從內存中刪除你的數據。該模式強調盡可能快地把數據保存在內容提供者中。
·規避了大部分可能的UI線程安全問題。Android視圖組件在實現上已經動態更新顯示當前的游標內容。如果模型中的數據變少，則ListView會確保其在游標上迭代的次數。熟悉J2SE Swing編程的用戶會知道其他組件系統會把這種任務留給開發人員，這會導致列表組件在數據元素被刪除的情況下執行迭代時，訪問可能會超出模型的邊界。
·該方法充分利用了游標管理系統和用戶接口中天然存在的動態更新能力來實現對內容變化事件的響應。用戶接口開發人員不需要編寫自己的polling和更新系統；他們只需要依賴內容觀察者和內容提供者接口。
·對於任何正確的網絡資源請求，UI線程不可能會掛在網絡上。
·網絡事件的交付不需要用戶界面。即使當網絡事件到達時也不需要特定的活動，內容提供者還是可以處理它。當用戶加載活動時，可以查詢顯示在後台的到達的事件。沒有活躍的UI活動也不會使得事件消失不可見。
·應用元素是封裝的，而且有特殊的目的，因為正如我們前面提到的，內容提供者處理所有的網絡和SQLite的交互。從視圖和控制器的角度來看，提供者是一個數據管理的通用系統。
·編寫應用更簡單，因為使用的API很少會出錯——執行內容提供者調用，系統處理REST（一語雙關，既指其他部分，也指REST請求）。
·最後，在關於移動編程的書籍中，很容易把重點放在設備相關的問題上，但是如果客戶端依賴於其緩存，而且只有當必須的時候其才指向網絡，這會極大減少為設備提供數據服務的系統的網絡負載。該模式為服務器和客戶端都提供了極大的優勢。
這種方式在實際中的一種應用
簡單來說，只要可能，建議應用通過內容提供者來訪問和存儲網絡數據。雖然開始階段看起來可能是一個很繁重的工作，但是Web瀏覽器也是使用異步機制來加載URI所引用的內容的。對於熟悉基礎的Web編程的讀者，默認的Android API可能比AJAX API更靈活，但是AJAX具備很完善的架構。現代瀏覽器使用異步I/O機制加載URI數據（關於異步I/O，參考http://en.wikipedia.org/wiki/Asynchronous_io），在很多情況下可以避免瀏覽器用戶界面掛掉。雖然當某個URI加載失敗時瀏覽器看起來沒執行什麼操作，但UI線程本身不會因為網絡連接沒有響應而造成阻塞。當UI線程要掛掉時，整個瀏覽器就會停止工作。瀏覽器甚至都沒法告訴你它掛掉了——尤其是很多完全單線程的瀏覽器。相反，採用異步方式時，瀏覽器能夠停止對任何給定頁面的請求，然後加載另一個可能響應更好的頁面。此外，所有現代瀏覽器都利用了持久性Web緩存，這裡建議Android應用應該包含類似的結構。
除了前面描述的模式，Google在提高應用的響應能力上還提供了專門的文檔，以及減少「應用不響應」通知的可能性的文檔，這些文檔在http://developer.android.com/guide/practices/design/responsiveness.html。