为什么装载机不好以及为什么应该避免它们
你会注意到，这不是我说的。我说过加载器是一个失败的抽象。有区别。
当尝试创建一个可重用的框架时，一般建议是设计和创建该框架的三个离散实现。如果您的框架可以支持三种不同的方法，那么设计可能足够灵活，可以处理未来的实现。
The Loader归根结底，框架是围绕一个实现而设计的：CursorLoader。时期。没有其他具体实现Loader在 SDK 中。特别是，Loader框架有一个合同，要求实施Loader能够自动提供更新的结果。虽然从角度来看这是一份可爱的合同users of the Loader框架，这让那些可能创建的人变得困难实施 of the Loader框架。
我尝试创建两个单独的实现Loader框架，用于 SQLite 和SharedPreferences（如果单独计算 Android 版 SQLCipher，则为 3 个）。 SQLite 很糟糕，因为执行自动重新加载的唯一方法是Loader知道什么需要重新加载，这很笨拙。这SharedPreferences曾经有用过，但有人指出现在onLoadFinished()如果代表结果的对象（Cursor for a CursorLoader, SharedPreferences for SharedPreferencesLoader) 与之前是同一个对象。那打破了SharedPreferencesLoader，自从SharedPreferences对象已更新in situ当偏好改变时。
写完我的Loader实现并使用它们一段时间后，我得出的结论是它们不值得。我宁愿使用自己异步加载东西AsyncTask or IntentService并使用消息总线（Otto、greenrobot 的 EventBus 等）来通知感兴趣的各方有关数据的更改。当我could把那个东西包裹在里面Loader，我不相信它能解决足够多的问题，值得付出努力。
现在，如果您正在使用ContentProvider并希望使用CursorLoader， 没关系。它可能有其自身的问题，但至少它应该可以工作。
关于 CWAC-LoaderEx 库，我将停止使用它，因为：
我一天只有这么多时间，因此作为 CWAC 库 AAR 化的一部分，我正在决定哪些库值得努力维护
除了一些书籍示例之外，我个人不使用 CWAC-LoaderEx
CWAC-LoaderEx 依赖于过多的内部实现Loader让我感到放心，我将能够长期保持它的工作（参见SharedPreferencesLoader)
CWAC-LoaderEx 不会去任何地方，但我只是不会投入更多时间。如果有人拥有维护/扩展的分叉与我联系，我将很乐意从项目自述文件中链接到他们的分叉。
我还想知道 Loaders 的其他更好替代品
All a Loader所做的是异步加载内容，在检测到内容更改时重新加载该内容，并在配置更改期间保留所述内容。保留模型（或无头）片段可以做同样的事情，与AsyncTask.
