我们一起来总结一下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。