别人说你和狗屎一样 — databinding

对于开发来说，其实应该遵从两点，对于好的产品和代码就必须承认是好的，对于不认同的就是认为像狗屎一样

一、 一千个人心中可以有一千个哈姆莱特，但技术它不行！

任何事物都不是唯一的，大家都可以有自己的想法，我也是认同的，但是技术方面，不能是这样也不会是这样的

1.1 本文想说点什么？

• Databinding
• Databinding 带给开发的快感
• Databinding 带来的影响
• kotlin 和jetpack 下Databinding 存在的意义

1.1.1 Databinding

Databinding 是谷歌官方发布的一个基于页面数据和业务逻辑分离、直接在页面布局中绑定数据的MVVM框架，可以直接在xml中绑定数据、绑定事件、进行逻辑处理、进行数据双向绑定… 减少findViewById代码等

1.1.2 在实际的开发中那些功能是重要的呢？

• 减少findViewById()
• 直接数据绑定xml 与控制层业务分离
• …

当然 Databinding的出现是具有时代意义的，是google出的对于MVVM 数据分离的官方框架，但是我在之前是没有使用的，后来在去结合kotlin和jetpack以及别人开发中总结出来的Databinding的缺点，我是不建议使用Databinding 的，为什么呢？

1.1.3 Databinding 带给开发的影响

首先；在过去的开发中，总结性的将开发的模式大致分为：

• 开发模式
  • MVC
  • MVP
  • MVVM
  • 混合使用
• 框架使用
  • 模块化
  • 组件化
  • 插件化

为什么说以上两个呢？因为他们和Databinding 的实际应用是密不可分的

对于开发模式来说最终的目的就是为了使业务层和数据层的分离，就是对于耦合度的解耦，使业务更加明确、清晰

对于框架来说决定着以后开发的模式、

• 按部就班的传统项目

之前刚开始的时候是没有使用框架的，直接是在一个项目中一股脑的写，经常会出现代码修改重复、编译超级慢、需求变动影响大，对于新增的需求还好、对于删除的不确定需求来说简直就是噩梦，代码管理中全是各种版本。

• 模块化

后续出现了模块化的开发，将一个项目发展为各种功能独立的模块，然后依赖到主模块中，这样就解决了需求删改等问题，项目也可以由多人开发，每个开发的模块之间的每个人都需要一个host才能运行

把常用的功能、控件、基础类、第三方库、权限、资源等公共的部分全部分离出来，然后让所有的业务组件之间相互依赖

• 组件化

组件化将一个app的代码拆分成独立的几个组件，组件之间低耦合、可以单独编译打包、也可以将多个组件打包到一个apk

• 插件化

将一个apk根据业务功能拆分成不同的子apk，每个子apk独立编译打包，最后发布上线的是集成后的apk 。在使用插件的时候都是动态加载的，插件也可以进行热修复、更新等

⚠️ 为什么要扯这些呢？

因为在多模块开发的使用Databinding 会出现问题

• 子模块使用了DataBinding 那么主模块必须在gradle里面配置databinding
• 主模块和子模块添加上databinding 的配置，在编译的时候子模块xml产生的Binding类除了自己的build里面会有在主模块下也会有一份，
• 主模块和子模块的布局文件名称一样的时候，主模块生成的Binding 类就是子模块文件生成的
• 子模块的某个xml文件使用一些第三方的控件，主模块由于也会生成这个类的Binding类，那猪模块就需要引入同样的引用

说完这些还有吗？

• 首先编译延迟

在编译时我们需要每次进行rebuild 之后才能使用我们本次添加后的Binding类

• 布局文件变得复杂
• 代码的可读性变得比较差

1.1.4 kotlin 和jetpack 下Databinding 存在的意义

那在目前kotlin的大趋势下，再加上google出的开发框架，我们还需要DataBinding吗？

• kotlin xml中的组建的id 直接使用kotlinx 引入，比Databingding更加简单易用
• jetpack 中的ViewModel、Lifecycles、ViewModel 等，在多个角度对耦合度解耦提供了很大的帮助，特别是viewModel数据变化监听，完全能和DataBinding的数据绑定媲美，并且对于数据和生命周期的管理非常智能

当然DataBinding火及一时，之前是有很多项目使用到的，假如需要，我们需要维护，好好学习一下