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

Question

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

androidmvvmdata-bindingandroid-databinding

87

我的同事和我都有Web App的MVVM经验，但是我们刚开始学习原生安卓开发。现在我们对于安卓数据绑定有不同观点--我很喜欢它，而他则不太喜欢。

我的观点：

- 减少样板代码从而带来

- 更少的耦合 - 更强的可读性

- 强大、易于实现自定义属性和自定义视图 - 比findViewById查询速度更快 (详情请见这里)

他的观点：

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

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

讨论方面包括但不限于：

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

- lzl124631x

4

我发现这种讨论非常适合学习，为什么它没有被标记为表达观点的讨论，所以对Stack Overflow没有价值？这篇帖子确实是一个很好的学习机会。 - Drocchio

1

请阅读这篇文章，它解释了使用数据绑定库的缺点。人们需要小心在XML文件中放置多少逻辑。文章链接：https://medium.com/@hellotimmutton/an-argument-against-data-binding-13e2aaf7a9b1 - Hitesh Bisht

确实是个好问题。 - Malwinder Singh

4个回答

13

我正在参与一个庞大的Android项目，团队决定逐步淘汰Data Binding库。为什么？主要原因是它会在构建过程中生成大量类，从而导致构建时间加长（超过10分钟）。

- DYS

11

尽管我喜欢danypata的答案，但我想添加/编辑他的一些语句以适用于Android数据绑定。

1.移除样板代码 - 如danypata的答案所述，它会删除一些代码并将其添加到其他位置，比如布局中。这并不意味着模板代码没有减少，因为通常情况下是减少了的。

例如，您可能希望创建一个bindingadapter，用于处理Spinner/RecyclerView/ListView等的多个自定义ArrayAdapter，但仅需要一个简单的适配器。您可以通过使用以下内容在布局中使用适配器：

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

现在，您可以创建通用适配器并在所有布局中重用bindingadapter，而无需例如使用：

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

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

这意味着您不需要找到所有视图、更新视图、更新模型等等。

2.更好的可读性 - 学习数据绑定所花费的额外时间并不重要。由于布局实际上没有什么不同，除了将它们包装在布局标记中并将命名空间放置在那里，因此它与“普通”布局并没有真正的区别。使用bindingadapters并在布局中访问模型可能需要一些时间，但通常您可以从基础知识开始，这些基础知识易于使用和美观。学习新东西总是需要时间的，但使用数据绑定一段时间后，您将轻松地超越这段时间。

3.强大 - 是的，它非常强大。它更容易重用现有的代码、重用现有的bindingadapters，并且可能导致更多生成的代码，但并非总是如此。例如，您可以在多个类中创建多个适配器，而不是创建一个bindingadapter，这可能很难以后“优化”。优化Bindingadapter意味着它将在所有地方得到更新。优化可以减少“代码行数”，因为无论如何都减少了锅炉板。

我同意第4点和第5点。

6.难于调试 由于AS 3.0+会输出有用的提示，例如您布局中的语法问题（行号和文件），因此很容易调试数据绑定生成的代码。如果您找不到问题，也可以检查生成的代码中是否有错误。某些库（如dagger 2或android架构库）可能会导致混淆，因为错误行与实际“错误”不匹配。这是由其他注解处理器生成的代码造成的。如果您知道这些注解处理器可能会与databindings错误输出产生冲突，那么您可以轻松修复。

7.单元测试 使用executePendingBindings就像不使用数据绑定一样。

8.可读性 没有使用数据绑定可能会更好阅读。由于您在布局中放置了一些业务逻辑，一些放在实际代码中，这可能会导致代码混乱。另一个问题是，在布局中使用lambda表达式可能会非常混乱，如果“布局设计师”不知道哪个参数可能会被使用。

另一个非常大的问题是bindingadapter可以出现在任何地方。使用BindingAdapter注释生成代码。这意味着在布局中使用它可能会导致找到适当的代码存在问题。如果要更新bindingadapter，您需要“找到”它。

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

- Emanuel

0

数据绑定在概念上看起来很有前途，但我不喜欢它的实现部分。

我希望它能更简单、更直接一些。因此，我感觉保持老派的方式会更加舒适。

模型类、可变对象、观察者对我来说都太多了，如果绑定使用的数据变量以可变和可观察的对象形式直接在类中接收，那么这将使过程更加清洁、简洁。

- viv

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- danypata · Accepted Answer

我将先评论您的观点，然后陈述我的观点：

1.删除样板代码 - 它会移除一些样板代码，或将其移到xml中，或需要额外的类。因此，您必须谨慎平衡使用数据绑定。

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

3.功能强大 - 代码具有更多的功能，您可以在代码中实现任何您想要的东西。想象一下，使用数据绑定实现的所有内容都有一个代码等效项（可能会更长，需要编写更多代码），但反向不成立。

4.比findViewById还要快 - 在这两个之间比较速度，在我看来没有意义，您永远不会注意到差异，如果您看到差异，则表示其中一个实现是错误的。

5.自动生成的类 - 这是真的，它会增加应用程序的大小，但如果只有大量使用，才会有影响。确实，在Android开发网站上他们声称使用创建自动生成代码或生成额外代码的annotations库不太好。

6.难以调试 - 这取决于可读性，您所习惯的方式，检查问题通常很难，您将通过调试而不是使用其他库来提高技能。

这是我的纯个人观点，我已经使用不同的库和不同的方法开发了许多应用程序，它们都有优缺点，但我学到了：平衡一切，不要使用大量库，不要浪费时间实现已经实现并且运行良好的事物，不要“解耦”一切，也不要“耦合”一切，不要仅使用代码，不要尝试“生成”每件事情。

我认为，如果您询问某个库/实现的“优点和缺点”，则会得出错误的想法，因为通常它不会客观公正，某些人会从他们以特定方式使用该库，并且它有效的角度提供许多优点，而其他人则会提出缺点，因为他们使用了不同的方式，效果并不好。

因此，总之，我认为您应该检查库能为您做什么和不能为您做什么，然后决定它是否适合您的环境。换句话说，您应该决定一个库是否适合您自己，而不是听取别人的意见 ;)。

更新-2018年8月8日

首先，我仍然坚持我的初步结论，平衡是这些情况的关键，但是在我的情况下，数据绑定加速了开发流程并提高了它。以下是一些新观点，您应该考虑到所有这些。

测试UI--使用数据绑定使UI的测试更加容易，但数据绑定并不足够，您还需要一个好的架构，并使用谷歌建议的架构来展示数据绑定的实际强大之处。
最明显的变化出现在我的原始回答的第2和第5点。在我们决定使用数据绑定后，代码阅读起来更加容易，这里最重要的一点是：我们作为团队决定使用数据绑定，之后，我们期望在XML文件中设置大部分琐碎和基本的UI布局。

关于调试部分，这里有一点棘手，Android Studio在数据绑定的错误和自动补全方面有很大的改进空间，但最常见的错误发生在前2-3次。此外，我学到了一个“干净项目”可以帮助解决很多问题。

另一个需要考虑的点是项目配置如何使用数据绑定，目前AS（3.1）默认支持Java的数据绑定（只需在Graddle中设置一个标志），但在Kotlin中我遇到了一些问题，在SO上稍微搜索了一下就解决了。

作为原始帖子的第二个结论，如果您可以使用数据绑定，并且项目的截止日期/要求等允许，请尝试，这将是值得的（除非您做了一些非常愚蠢的事情：））。