对于开发来说，其实应该遵从两点，对于好的产品和代码就必须承认是好的，对于不认同的就是认为像狗屎一样
一、 一千个人心中可以有一千个哈姆莱特，但技术它不行！
任何事物都不是唯一的，大家都可以有自己的想法，我也是认同的，但是技术方面，不能是这样也不会是这样的
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火及一时，之前是有很多项目使用到的，假如需要，我们需要维护，好好学习一下
