我和我的同事都拥有Web App MVVM的经验，而我们还是原生android开发的新手。现在我们对android数据绑定有相反的看法-我是他的粉丝，而他不是。
我的论点：
他的论点：
我进行了一些调查，但没有太多讨论。现在，我想收集android数据绑定的优缺点。
讨论的方面包括但不限于：
Answers:
我将首先评论您的论点，然后发表我的看法：
1.删除样板代码-它将删除一些代码，只是将其移入，xml或者需要其他类。因此，您必须谨慎并平衡数据绑定的使用。
2.更强的可读性-取决于您是否是新开发人员，那么您可能会发现它很容易学习，但是如果您以前在android上工作，则需要更多时间来学习它。
3.功能强大-代码具有更大的功能，您可以在代码中实现所需的任何功能。这样考虑一下，您使用数据绑定实现的所有内容都具有等效的代码（可能更长，编写的代码也更多），但是反向操作无效。
4.甚至比findViewById-更快地比较这两者之间的速度，在我看来是没有用的，您将永远不会注意到差异，如果看到一些差异，那么其中一种实现是错误的。
5，自动生成的类-的确会增加应用程序的大小，但是仅当您拥有大量的类时，它才会重要。的确，在android dev网站上，他们声明使用创建自动生成的代码或annotations生成额外代码的库有点不好。
6，难以调试-就像可读性一样，取决于您的习惯，对于某些问题，无论哪种方式都很难进行调试，并且通过使用其他库进行调试会变得更好。
因此，这纯粹是我的观点，我使用不同的库和不同的方法开发了许多应用程序，它们都有优点和缺点，但是我所学到的是：平衡一切，不要使用大量的库，不要浪费及时实施已经实施且可以正常工作的事物，不要“解耦一切”，不要“耦合”一切，不要只使用代码，不要试图“生成”一切。
我认为这是完全错误的，如果您要求有关某些库/实现的“利弊”，您会得到一个错误的主意，因为通常它不会公正，因此，使用过库以一种特定的方式工作，它可以工作，其他人则可以给您带来弊端，因为他们使用了不同的方法而没有用。
因此，总而言之，我认为您应该检查该库可以为您做什么和不为您做什么，并确定它是否对您的设置有利。换句话说，您应该决定图书馆是否对您有好处，而不是其他人;）。
更新-2018年8月8日
首先，我仍然坚持我的最初结论，在这种情况下，平衡是关键，但就我而言，数据绑定加快了开发过程并改善了开发过程。这里是您应该考虑的一些新观点。
测试UI-使用数据绑定可以更容易地测试UI，但仅凭数据绑定还不够，您还需要一个良好的体系结构，使用Google建议的体系结构将显示数据绑定的实际功能。
我原来的答案为第2点和第5点提供了最明显的变化。在我们决定使用数据绑定之后，阅读代码会更容易，这里最重要的是：作为一个团队，我们决定使用数据绑定，在那之后，我们有望拥有大部分XML文件中简单而基本的UI设置。
对于调试部分，这有点棘手，Android Studio在数据绑定的错误和自动完成方面有很多改进，但是最常见的错误是在出现前2-3次后会出现。我还了解到，“清洁项目”会不定期地帮助很多。
作为第二个结论（摘自我的原始帖子），如果可以并且项目截止日期/要求/等允许您尝试数据绑定，那么就值得（除非您做一些非常愚蠢的事情:)））。
即使我喜欢danypata的答案，我也想向Android数据绑定添加/编辑他的某些语句。
1.删除样板代码-按照danypatas的回答，它删除了一些代码，并在布局中的其他位置添加了一些代码。这并不意味着不会减少锅炉代码，因为通常会减少它。
例如，您可能想创建一个bindingadapter，它为您的spinner / recyclerview / listview / ..处理几个自定义的arrayadapter，但是只需要一个简单的适配器。您可能希望通过使用例如在布局中使用适配器
app:myCoolAdaptersData="@{model.mydata}"
现在，您可以创建通用适配器，并在所有布局中（重新）使用bindingadapter，而无需使用例如：
ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);
这只是一个简单的示例，在较大的项目中大量引用了该代码。引用代码的另一个示例是将模型绑定到布局。更新模型的字段值通常也会同时更新模型（如果模型至少为BaseObservable / ObservableField）。
这意味着您无需查找所有视图，更新视图，更新模型，...
2.更强的可读性-学习数据绑定所花费的额外时间并不重要。由于布局没有真正的不同，只是将它们包装到一个布局标签中并在其中放置了名称空间，因此它与“常规”布局并没有真正的不同。使用绑定适配器并在布局中访问模型可能会花费一些时间，但是通常您可以从易于使用且美观的基础知识开始。学习新东西总是要花时间，但是过一会儿使用数据绑定后，您将很容易检查时间。
3.功能强大-是的，功能非常强大。它更容易重用现有代码，重用现有的绑定适配器，并可能导致生成更多的代码，但事实并非总是如此。例如，您可以在多个类中创建多个适配器，而不是创建一个bindingadapter，以后可能很难对其进行“优化”。优化Bindingadapter意味着它到处都会更新。由于无论如何都会减少锅炉位置，因此优化可能会减少“代码行”。
我同意4.和5。
6.难以调试由于AS 3.0+在布局（行号和文件）中输出有用的提示（如语法问题），因此易于调试数据绑定生成的代码。如果您在查找问题时遇到问题，则可能还需要检查所生成代码中的错误。一些库，例如dagger 2或android体系结构库，可能会使您感到困惑，因为错误行与真正的“错误”不符。这是由于其他注释处理器生成的代码。如果您知道这些注释处理器可能会遇到数据绑定错误输出的麻烦，则可以轻松地解决该问题。
7.单元测试可能就像您不使用executePendingBindings来使用数据绑定一样。
8.可读性如果没有数据绑定，可读性可能会更好。由于您在布局中放入了一些业务逻辑，在实际代码中加入了一些业务逻辑，因此可能会导致意大利面条式代码。另一个问题是，如果“布局设计者”不知道可以使用哪个参数，那么在布局中使用lambda可能会造成很大的困惑。
另一个非常大的问题是，绑定适配器可能无处不在。使用BindingAdapter批注生成代码。这意味着在布局中使用此代码可能会导致找不到正确代码的问题。如果要更新绑定适配器，则需要“查找”它。
什么时候应该使用什么？对于较大的项目，最好将数据绑定与mvvm或mvp模式一起使用。这是一个非常干净的解决方案，并且非常易于扩展。如果您只想创建一个小的简单应用程序，则可以使用MVC模式而无需数据绑定。如果您已有可以在其他项目中使用的通用绑定适配器，则可能要使用数据绑定，因为它很容易重用此代码。