android数据绑定的优缺点是什么？

Question

我和我的同事都有 Web App MVVM 的经验，而我们是原生 android 开发的新手。 现在我们对 android 数据绑定有相反的看法——我是它的粉丝，而他不是。

我的论点：

• 减少样板代码，这反过来又带来
  • 减少耦合
  • 更强的可读性
• 功能强大，易于实现自定义属性和自定义视图
• 甚至比 findViewById 还要快（ 详情）

他的论点：

• 自动生成的 .class 会增加应用程序的大小。
• 更难调试

我已经进行了一些调查，但关于它的讨论并不多。 现在我想收集android数据绑定的优缺点。

讨论的方面包括但不限于：

• 单元测试
• 应用大小
• 表现
• 学习曲线
• 可读性
• 耦合

Answer 1

我先评论你的论点，然后我再说一下我的观点：

1.删​​除样板代码 - 它将删除一些它只会在xml移动一些或者它需要额外的类。 所以你必须小心和平衡数据绑定的使用。

2.更强的可读性 - 取决于你是否是一个新的开发者，那么你可能会发现它很容易学习，但如果你以前在 android 上工作过，你将需要额外的时间来学习它。

3.强大——代码更强大，你可以在代码中实现你喜欢的任何东西。 像这样想，您使用数据绑定实现的所有内容都有一个等效的代码（可能会更长，需要编写更多代码），但反过来是无效的。

4.甚至比findViewById还要快——比较这两者的速度，在我看来是没用的，你永远不会注意到差异，如果你看到一些差异，那么其中一个实现是错误的。

5.自动生成的类 - 它确实会增加应用程序的大小，但同样只有当你有大量的它才会重要。 确实，在 android 开发网站上，他们声明使用创建自动生成代码的库或将生成额外代码的annotations有点不好。

6.难以调试 - 与可读性一样，取决于您所习惯的，对于某些问题，无论哪种方式都很难调试，并且通过调试而不是使用不同的库，您会变得更好。

所以这纯粹是我的观点，我使用不同的库和不同的方法开发了许多应用程序，它们都有优点和缺点，但我学到了什么：平衡一切，不要使用大量的库，不要浪费花时间实现已经实现并且运行良好的东西，不要“解耦一切”，不要“耦合”一切，不要只使用代码，不要试图“生成”一切。

我认为这是完全错误的，如果你问一些库/实现的“利弊”，你可能会得到一个错误的想法，因为通常它不会是公正的，你会从使用过的人那里得到很多优点图书馆以特定的方式工作并且它起作用，而其他人会给您带来缺点，因为他们使用不同的方法并且不起作用。

因此，总而言之，我认为您应该检查库可以为您做什么以及不能为您做什么，并确定它是否适合您的设置。 换句话说，你应该决定一个图书馆是否适合你而不是其他人;)。

更新 - 2018 年 8 月 8 日

首先，我仍然坚持我最初的结论，在这种情况下平衡是关键，但在我的情况下，数据绑定稍微加快了开发过程，也改进了它。 这里有一些新的观点，你们都应该考虑一下。

1. 测试用户界面——使用数据绑定测试用户界面要容易得多，但是数据绑定还不够，你还需要一个好的架构，使用谷歌建议的架构将显示数据绑定的实际威力。

2. 从我的原始答案中，为第 2 点和第 5 点提供了最明显的变化。 在我们决定使用数据绑定之后，代码更容易阅读，这里最重要的事情是：我们作为一个团队决定我们将使用数据绑定，在那之后，我们有点期望拥有大部分XML 文件中的琐碎和基本 UI 设置。

对于调试部分，这里有点棘手，Android Studio 在数据绑定的错误和自动完成方面有很多改进，但最常见的错误是在前 2-3 次发生后出现。 我还了解到，一个“干净的项目”不时形成，有很多帮助。

3. 您必须考虑的另一点是使用数据绑定的项目配置，现在 AS (3.1) 默认支持 Java 的数据绑定（只需在 graddle 中设置一个标志），但我遇到了一些问题Kotlin，在 SO 上进行了一些搜索后，我设法解决了所有问题。

作为第二个结论（来自我的原始帖子），如果可以并且项目截止日期/要求/等允许您尝试数据绑定，那么去尝试它是值得的（除非您做了一些非常愚蠢的事情:)））。

Answer 2

即使我喜欢 danypata 的回答，我也想将他的一些语句添加/编辑到 android 数据绑定中。

1.删除样板代码- 正如在 danypatas 中写的那样，它删除了一些代码并在其他地方添加了一些代码，比如在布局中。 这并不意味着锅炉代码不会减少，因为通常它会减少。

例如，您可能想要创建一个 bindingadapter，它可以为您的 spinner/recyclerview/listview/.. 处理多个自定义数组适配器，但只需要一个简单的适配器。 您可能希望在布局中使用适配器，例如

app:myCoolAdaptersData="@{model.mydata}"

现在您可以创建通用适配器并（重新）在所有布局中使用您的 bindingadapter 而不是使用例如：

ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);

这只是一个简单的例子，它在较大的项目中减少了大量的代码。 另一个减少代码的示例是，将模型绑定到布局。 更新模型的字段值通常也会更新模型（如果它至少是 BaseObservable/ObservableField）。

这意味着您不需要查找所有视图、更新视图、更新模型……

2.更强的可读性- 学习数据绑定所花费的额外时间并不重要。 由于布局并没有真正不同，只是将它们包装到布局标记中并将命名空间放在那里，因此它与“常规”布局并没有真正的不同。 使用 bindingadapters 和访问布局中的模型可能需要一些时间，但通常您可以从基础知识开始，这些基础知识也易于使用且美观。 学习新东西总是需要时间，但在使用数据绑定一段时间后，你会很容易地调整时间。

3.Powerful - 是的，它非常强大。 重用现有代码、重用现有绑定适配器更容易，并可能导致生成更多代码，但并非总是如此。 例如，您可以在多个类中创建多个适配器而不是创建一个绑定适配器，以后可能很难对其进行“优化”。 优化 Bindingadapter 意味着它会随处更新。 优化可能会减少“代码行数”，因为无论如何都会减少样板间。

我同意 4. 和 5.

6. 难以调试由于 AS 3.0+ 会输出有用的提示，例如布局中的语法问题（行号和文件），因此很容易调试数据绑定生成的代码。 如果您在查找问题时遇到问题，您可能还需要检查生成的代码中是否存在错误。 一些库如 dagger 2 或 android 架构库可能会让你感到困惑，因为错误行与真正的“错误”不匹配。 这是由于其他注释处理器生成的代码。 如果您知道那些注释处理器可能会遇到数据绑定错误输出的问题，那么您可以轻松解决这个问题。

7. 单元测试这可能就像你不使用数据绑定通过使用 executePendingBindings。

8. 可读性没有数据绑定的可读性可能会更好。 由于您将一些业务逻辑放入布局中，将一些放入实际代码中，因此可能会导致意大利面条式代码。 另一个问题是，如果“布局设计师”不知道可以使用哪个参数，则在布局中使用 lambda 可能会非常混乱。

另一个非常大的问题是 bindingadapter 可以无处不在。 使用 BindingAdapter 注释生成代码。 这意味着在您的布局中使用它可能会导致无法找到正确的代码。 如果要更新 bindingadapter，则需要“找到”它。

什么时候应该使用什么？ 对于较大的项目，将数据绑定与 mvvm 或 mvp 模式一起使用是一个非常好的主意。 这是一个非常干净的解决方案，并且非常容易扩展。 如果您只想创建一个简单的小型应用程序，则可以使用没有数据绑定的 MVC 模式。 如果您已有可从其他项目使用的通用绑定适配器，您可能希望使用数据绑定，因为它易于重用此代码。

Answer 3

我正在处理一个巨大的 Android 项目，团队决定逐步淘汰数据绑定库。 为什么？ 主要原因是它在构建过程中生成了大量类，从而加剧了构建时间（10 分钟以上）。