android数据绑定的优缺点是啥？

Posted 2023-02-22

【中文标题】android数据绑定的优缺点是啥？

【英文标题】：What are the pros and cons of android data-binding?android数据绑定的优缺点是什么？

【发布时间】：2017-05-18 15:47:49

【问题描述】：

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

我的论点：

减少样板代码，从而带来 减少耦合 可读性更强 功能强大，易于实现自定义属性和自定义视图 甚至比 findViewById (details) 还要快

他的论点：

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

我进行了一些调查，但没有太多关于它的讨论。现在我想收集一下android数据绑定的优缺点。

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

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

【问题讨论】：

我发现这种讨论真的很好学，为什么没有标记为表达意见的讨论，所以不值得SO？这篇文章确实很好的学习机会

请阅读这篇解释使用数据绑定库的缺点的文章。需要注意要在 xml 文件中放入多少逻辑。文章链接medium.com/@hellotimmutton/…

确实是个好问题。

【参考方案1】：

数据绑定，概念方面对我来说很有希望，但我不喜欢实现部分。

我希望有更简单和直接的方法。 因此，我觉得保持老派更舒服。

模型类、可变对象、观察者对我来说太过分了，如果某些用于绑定的数据变量在类中直接作为可变和可观察的对象接收，那么这将使过程更加清晰，简洁明了。

【参考方案2】：

我正在开发一个庞大的 Android 项目，团队已决定逐步淘汰 Data Binding 库。为什么？主要原因是在构建过程中生成了大量类，从而增加了构建时间（10 分钟以上）。

【讨论】：

如果您的团队无法优化构建过程和导出库，那么您可能会遇到另一个问题，然后使用数据绑定 .. :-)

【参考方案3】：

我会先评论你的论点，然后我会陈述我的观点：

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

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

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

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

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

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

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

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

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

更新 - 2018 年 8 月 8 日

首先我仍然坚持我最初的结论，在这种情况下平衡是关键，但在我的情况下，数据绑定加速了一点开发过程，也改进了它。以下是一些大家都应该思考的新观点。

测试 UI -- 使用数据绑定更容易测试 UI，但数据绑定还不够，您还需要一个好的架构，使用 Google 建议的架构将显示实际数据绑定的力量。

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

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

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

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

【讨论】：

现在有一个巨大的缺点 - 当前的实现（Mac 上的库 + Android Studio 2.2.3）是不稳定的。我仍然遇到一些问题，例如 IDE 错误（在代码中显示错误但项目编译，错误一直存在，直到您重新打开 IDE），XML 布局文件中的自动完成问题，偶尔无法生成类等。这很烦人。

感谢您的评论！正如你所说，试图平衡一切总比走极端要好。我之所以问利弊，是想从对android数据绑定有更多经验的开发者那里得到更多的见解，我希望我能自己平衡一下：）谢谢你的建议，我会的仔细查看文档，了解它可以做什么和不能做什么。

我完全同意这个答案。关键是平衡一切。当然，这比走极端要难得多。正如有人所说，工程是一门权衡取舍的艺术。同样的道理也适用于生活中的许多事情：初学者只看到黑白，聪明人看到灰度。

使用数据绑定时。我面临的问题是生成视图绑定资源需要花费大量时间，这是为什么呢？如何固定视图绑定生成或更新？

@Ramesh_D 到目前为止我还没有遇到这个问题，有时我会打错字并且没有生成绑定。但请耐心等待，这是一项持续的功能，并且会随着时间的推移而改进。

【参考方案4】：

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

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

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

app:myCoolAdaptersData="@model.mydata"

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

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

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

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

2.更强的可读性 - 用于学习数据绑定的额外时间并不重要。由于布局并没有真正的不同，只是您将它们包装到布局标签中并将命名空间放在那里，因此它与“常规”布局并没有真正的不同。使用 bindingadapter 和访问布局中的模型可能需要一些时间，但通常您可以从简单易用的基础开始。学习新东西总是需要时间，但一段时间后使用数据绑定时，您会轻松地检查时间。

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

我同意 4. 和 5.

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

7.单元测试 如果您不使用数据绑定，则可能使用 executePendingBindings。

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

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

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