android布局优缺点,mvvm-android数据绑定的优缺点是什么？

即使我喜欢danypata的答案，我也想向Android数据绑定添加/编辑他的某些语句。

1.删除样板代码-按照danypatas的回答，它删除了一些代码，并在布局中的其他位置添加了一些代码。 这并不意味着不会减少锅炉代码，因为通常会减少它。

例如，您可能想创建一个bindingadapter，它为您的spinner / recyclerview / listview / ..处理几个自定义的arrayadapter，但是仅需要一个简单的适配器。 您可能想通过以下方式在布局中使用适配器：

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

现在，您可以创建通用适配器，并在所有布局中(重新)使用bindingadapter，而不必使用例如：

ListView lv = findViewById(...);

CoolGenericAdapter 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模式而无需数据绑定。 如果您已有可以在其他项目中使用的通用绑定适配器，则可能要使用数据绑定，因为它很容易重用此代码。