为什么加载器在Android中不好 [英] Why are Loaders bad in Android

问题描述

我在这里读过一些推文和评论，关于装载机性能不好，使用它们是面对现实"的好方法.另外， commonsguy 宣布他将停止其库中的任何工作: Loaderex . Commonsguy 还说:加载程序是失败的抽象."

I have read a couple of tweets and comments here and there about Loaders being bad and using them is a good way to "shoot yourself in the face". Also commonsguy announced that he will discontinue any work on his library : Loaderex. Commonsguy also said "Loaders are a failed abstraction."

我显然在这里缺少什么，我想学习更多并理解为什么装载机不好，为什么应该避免装载机.

I'm obviously missing something here and I would like to learn more and understand why are Loaders bad and why should one avoid them.

注意:我已经创建了一个Android应用程序(可能是中等复杂性)，在这里我可以使用Loader，并且Loader没遇到任何麻烦.这就是为什么让我感到困惑的原因.

Note: I have created an Android application (perhaps of middle complexity) where I use Loaders and haven't had any troubles with Loaders. That's why it's puzzling me.

我还想了解装载机的其他更好的 替代品 .预先感谢

I would also like to know about other better alternatives to Loaders. Thanks in advance

推荐答案

为什么装载机不好，为什么要避免装载机

why are Loaders bad and why should one avoid them

您会注意到，这不是我所说的.我说加载程序是一个失败的抽象.有区别.

You will note that this is not what I said. I said that loaders are a failed abstraction. There's a difference.

在尝试创建可重用的框架时，通常的建议是设计和创建该框架的三个离散实现.如果您的框架可以支持三种不同的方法，那么该设计可能足够灵活以处理将来的实现.

A general recommendation, when trying to create a framework for significant reuse, is to design and create three discrete implementations of the framework. If your framework can support three different approaches, the design is probably flexible enough to handle future implementations.

最终， Loader 框架是围绕一种实现设计的: CursorLoader .时期.SDK中没有 Loader 的其他具体实现.特别是， Loader 框架具有一项合同，该合同要求 Loader 的实现必须能够自动提供更新的结果.尽管从 Loader 框架的 users 的角度来看这是一个可爱的合同，但对于那些可能创建 implementation 的人来说，这却很困难.code> Loader 框架.

The Loader framework, at the end of the day, is designed around one implementation: CursorLoader. Period. There are no other concrete implementations of Loader in the SDK. In particular, the Loader framework has a contract that requires that implementations of Loader be able to deliver updated results automatically. While this is a lovely contract from the standpoint of users of the Loader framework, it makes things difficult for those who might create implementations of the Loader framework.

我试图为SQLite和 SharedPreferences 创建 Loader 框架的两个单独的实现(如果分别计算Android的SQLCipher，则为三个).SQLite很烂，因为执行自动重新加载的唯一方法是让 Loader 知道需要重新加载的内容，这很麻烦. SharedPreferences 曾经可以工作，但是有人指出，如今如果对象代表结果( Cursor ，则将不会调用 onLoadFinished()>对于 CursorLoader ，对于 SharedPreferencesLoader 的 SharedPreferences )与以前是同一对象.这会破坏 SharedPreferencesLoader ，因为在更改首选项时， SharedPreferences 对象会在原位更新 .

I attempted to create two separate implementations of the Loader framework, for SQLite and SharedPreferences (three if you count SQLCipher for Android separately). The SQLite one sucks, because the only way to do the automatic-reload stuff is for the Loader to know what needs to be reloaded, which is clunky. The SharedPreferences one used to work, but it was pointed out that nowadays onLoadFinished() will not be called if the object representing the results (the Cursor for a CursorLoader, SharedPreferences for SharedPreferencesLoader) is the same object as before. That breaks SharedPreferencesLoader, since the SharedPreferences object is updated in situ when preferences are changed.

在编写了我的 Loader 实现并使用了一段时间后，我得出结论认为它们不值得.我宁愿使用 AsyncTask 或 IntentService 异步加载自己的东西，并使用消息总线(Otto，greenrobot的EventBus等)通知感兴趣的各方有关数据更改的信息.当我可以将这些内容包装在 Loader 内时，我不相信它会解决足够的问题，值得我们付出努力.

After writing my Loader implementations and using them for a bit, I concluded that they weren't worth it. I'd rather load stuff myself asynchronously using AsyncTask or IntentService and use a message bus (Otto, greenrobot's EventBus, etc.) for notifying interested parties about changes in data. While I could wrap that stuff inside of Loader, I am unconvinced that it would solve enough problems to be worth the effort.

现在，如果您使用的是 ContentProvider ，并且希望使用 CursorLoader ，那很好.它可能有自己的问题，但至少应该可以使用.

Now, if you are using a ContentProvider and wish to use CursorLoader, that's fine. It may have its own issues, but at least it's supposed to work.

关于CWAC-LoaderEx库，我将其停产是因为:

With respect to the CWAC-LoaderEx library, I am discontinuing it because:

• 我一天只有几个小时，因此，作为CWAC库AAR伟大化的一部分，我正在决定哪些库值得努力维护

• I only have so many hours in the day, and so as part of the great AAR-ification of the CWAC libraries, I am deciding which libraries are worth the effort to maintain

在一些书籍示例之外，我个人不使用CWAC-LoaderEx

I do not use CWAC-LoaderEx personally, outside of a couple of book examples

CWAC-LoaderEx依赖于 Loader 的太多内部实现，令我感到满意的是，我将能够使其长期运行(请参阅 SharedPreferencesLoader )

CWAC-LoaderEx is dependent upon too much internal implementation of Loader for me to be comfortable that I will be able to keep it working over the long haul (see SharedPreferencesLoader)

CWAC-LoaderEx不会去任何地方，但我不会花更多时间.如果有人用叉子进行维护/扩展，请与我联系，我很乐意从README项目中链接到他们的叉子.

CWAC-LoaderEx isn't going anywhere, but I just will not be putting more time into it. If somebody with a maintained/extended fork contacts me, I'll be happy to link to their fork from the project README.

我还想了解装载机的其他更好的替代方案

I would also like to know about other better alternatives to Loaders

Loader 所做的全部工作是异步加载内容，在检测到内容更改后重新加载该内容，并在配置更改中保留该内容.保留的模型(或无头)片段可以与 AsyncTask 协同工作.

All a Loader does is asynchronously load content, re-load that content upon a detected change in the content, and retain said content across a configuration change. A retained model (or headless) fragment can do the same thing, in concert with an AsyncTask.

这篇关于为什么加载器在Android中不好的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！