我的同事和我都有Web应用程序的MVVM经验，而我们是本机android开发的新手。现在我们对android数据绑定有相反的看法 - 我不喜欢它，但我不喜欢它。
我的论点：
他的论点：
我做了一些调查，但关于它的讨论并不多。现在我想收集android数据绑定的优点和缺点。
讨论的方面包括但不限于：
答案 0 :(得分：31)
我先评论你的论点然后我会说出我的意见：
1.删除样板代码 - 它将删除一些它只会移动xml中的一些或者它将需要额外的类。因此，您必须小心并平衡数据绑定的使用。
2.更强的可读性 - 取决于你是否是一名新开发者，那么你可能会觉得它很容易学习它，但如果你以前在Android上工作过，你需要额外的时间来学习它。
3.Powerful - 代码具有更强大的功能，您可以在代码中实现您喜欢的任何内容。想想这样，使用数据绑定实现的所有内容都具有等效的代码（可能更长，编写更多代码），但反转无效。
4.比findViewById快 - 比较这两者之间的速度，在我看来是无用的，你永远不会注意到差异，如果你看到一些差异，那么其中一个实现是错误的。
5.Auto生成的课程 - 它确实会增加应用程序的大小，但只有当你有大量的时候它才会重要。确实，在Android开发者网站上，他们声明使用创建自动生成代码的库或生成额外代码的annotations是不好的。
6.难以调试 - 与可读性一样，取决于您习惯的内容，对于某些问题，调试很难，并且通过调试而不是使用不同的库，您将会变得更好。
所以这纯粹是我的观点，我已经使用不同的库和不同的方法开发了许多应用程序，它们都有利有弊，但我所学到的：平衡一切，不要使用大量的图书馆，不要浪费时间来实施已经实施并且运作良好的东西，不要将所有东西分离出来，而不是“不要”＃34;不要＆＃34;夫妻＆＃34;一切，不要只使用代码，不要试图＆＃34;生成＆＃34;一切。
我认为这是非常错误的，如果你要求＆amp; amp;＆amp;;缺点＆＃39;关于一些图书馆/实施，因为通常它不会是公正的，你会从一个以特定方式使用图书馆的人那里得到很多专业人士，并且它有效，而其他人会给你利弊，因为他们使用了不同的，它没有＆ ＃39; t work。
总而言之，我认为您应该检查一下图书馆可以为您做些什么，以及为您做些什么，并决定它对您的设置是否有益。换句话说，你应该决定图书馆是否适合你而不是其他人;）。
更新 - 2018年8月8日
首先，我仍然坚持我的初步结论，平衡是这种情况下的关键，但就我而言，数据绑定加快了开发过程的速度，并对其进行了改进。以下是您应该考虑的一些新观点。
测试用户界面 - 通过数据绑定，测试用户界面要容易得多，但对数据进行数据绑定还不够，还需要一个好的架构和使用谷歌建议的架构将显示数据绑定的实际力量。
为第2点和第2点提供了最明显的变化。 5我的原始答案。在决定使用数据绑定之后，更容易阅读代码，最重要的是：我们作为一个团队决定我们将使用数据绑定，之后，我们希望在XML文件中具有大部分简单和基本的UI设置。
对于调试部分，这里有点棘手，Android Studio在数据绑定的错误和自动完成方面有很多改进但是在前2个之后你会得到最常见的错误-3次出现。我也了解到一个清洁项目＆＃34;不时形成，帮助很多。
作为第二个结论（来自我原来的帖子），如果你可以和项目截止日期/要求/等允许你尝试数据绑定，那么它值得（除非你做一些非常愚蠢的东西:)） ）。
答案 1 :(得分：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.强大 - 是的，非常强大。它更容易重用现有代码，重用现有的绑定适配器，并可能导致更多生成的代码，但并非总是如此。例如，您可以在多个类中创建多个适配器，而不是创建一个bindingadapter，以后可能很难“优化”它。优化Bindingadapter意味着它随处可见。优化可能会减少“代码行”，因为无论如何都会减少锅炉。
我同意4.和5.
<强> 6。难以调试由于AS 3.0+输出了有用的提示，例如布局中的语法问题（行号和文件），因此很容易调试数据绑定生成的代码。如果您在查找问题时遇到问题，可能还需要检查生成的代码中的错误。像dagger 2或android架构库这样的一些库可能会让你感到困惑，因为错误行与真正的“错误”不匹配。这是由其他注释处理器生成的代码。如果您知道那些注释处理器可能会遇到数据绑定错误输出问题，您可以轻松解决这个问题。
<强> 7。单元测试如果你不使用executePendingBindings使用数据绑定，它可能就像。
<强> 8。可读性如果没有数据绑定，可读性可能会更好。由于您将一些业务逻辑放入您的布局中，一些放入您的真实代码中，因此可能会导致意大利面条代码。另一个问题是，如果“布局设计者”不知道可以使用哪个参数，那么在布局中使用lambdas可能会非常困惑。
另一个非常大的问题是bindingadapter可以无处不在。使用BindingAdapter注释生成代码。这意味着在布局中使用它可能会导致找到正确代码的问题。如果要更新bindingadapter，则需要“查找”它。
什么时候应该使用什么？对于较大的项目，将数据绑定与mvvm或mvp模式一起使用是一个非常好的主意。这是一个非常干净的解决方案，非常容易扩展。如果你只是想创建一个小的简单应用程序，你可以使用MVC Pattern而不需要数据绑定。如果您有可以在其他项目中使用的现有通用绑定适配器，则可能需要使用数据绑定，因为它很容易重用此代码。
答案 2 :(得分：0)
我正在从事一个庞大的Android项目，该团队已决定逐步淘汰数据绑定库。为什么？主要原因是通过在构建过程中生成大量类来加重构建时间（10分钟以上）。