开源项目讲解-2-tivi-未完待续

项目源码：https://github.com/chrisbanes/tivi

这个项目用一篇硕士论文讲都不为过。

tivi用到了MVVM架构，模块化编程和KMP(Kotlin Multi-platform)，组件用的jetpack等最新的UI实现，网络用的kotlin协程。

模块化编程

首先是模块化编程，模块化编程是市场和企业的需要，既能让企业细化分工，测试，迭代，解耦，又能让市场更细地选择产品。微服务、依赖注入、反转控制、接口、解耦，全都是为了做到模块化编程的最佳实践。

依赖注入指的是，将工具的实现托管给依赖注入库，不直接使用工具的实现，而是由依赖注入库来完成工具实现的注入，从而实现了与工具的解耦

项目分了从build-logic到ui这么多模块，分得很细，从api调用到数据层到业务层到视图层，再到依赖于的工具层，第三方层。这些模块都靠依赖注入的Component相连接，实现了较为彻底的解耦合，每个模块所依赖的其他模块都来自于依赖注入组件，因此单独编译每个模块也是能够通过的。但在运行时仍然需要组合在一起,并由依赖注入框架提供相互之间的依赖关系。

对比没有使用依赖注入的MVP和使用了的MVVM

有一个MVP架构的项目，分为了order，dinner，home这些模块，没有采用依赖注入的模式，比如order模块采用gradle依赖了dinner和home等其他模块，有一个壳工程，用gradle来集成order，dinner，home这些模块为一个整体可运行的安卓app，order模块单独编译的时候，对于依赖的其他模块，也在gradle更新对应的包，才能编译通过。模块与模块之间是单向或者双向强耦合的。

MVVM进行模块化编程时采用依赖注入，而非直接import接口的实例，但要import component对应的模块，但对于component这个模块，它的gradle则要依赖大量的业务，可以理解为component实现了业务模块于业务模块之间的解耦，它像大坝一样，拦住了所有的水流，让下游找大坝取水而不是直接到水流里拿水。这样主component的维护麻烦吗？答案是不麻烦，kotlin接口支持多重继承，每个父component维护好自己的实现类，主component不关心具体的实现。

外部库由libs.version.toml统一管理，内部库定义在了settings.gradle里