一个根本性的变化即将改变Android的核心工作方式。但你为什么要关心？而且，为什么这是一件好事？让我们来看看。
Android的新架构组件现已正式并固化。毫无疑问，View Models和LiveData等架构组件将使Android开发世界中新手的生活变得更加轻松。
但是对于经验丰富的开发人员来说，问题将不可避免地出现在新的架构组件如何以及在何处与干净架构的概念一致，正如Bob叔叔所倡导的那样。
你可能会问我们为什么要担心干净的建筑？答案很简单 – 清洁架构基于人类与软件开发周期的关系，这意味着它归结为一个简单而单一的“关注点分离”原则。清洁架构不仅限于特定的平台解决方案，Android Lifecycle的概念及其周围的解决方案也是如此。
考虑到这个问题，我想看看谷歌最近的一个样本，使用他们的架构组件，如何符合清洁架构的基本概念。清晰体系结构的核心概念在图片中进行了总结，对于任何了解这里提出的清洁体系结构的人来说都非常熟悉：
在这里插入图片描述
清洁架构中的核心原则
“内圈中的任何东西都不能知道外圈中的某些东西。特别是，外圈中声明的东西的名称不能被内圈中的代码所提及。这包括函数，类，变量，或任何其他指定的软件实体。“
我拍的样本是Google 代码实验室的“带有视图的房间”样本。
尽管有许多使用方法的清洁架构实现，如MVP，MVVM等，它们为Android空间提供了可行的解决方案，但我的问题是，如果我们能够维护清洁架构的核心概念，那就是：“内部圆圈中的代码不得提及外部圆圈中声明的内容的名称“不带任何框架，只需使用Android体系结构组件即可。
“带有视图的房间”是一个简单的应用程序，它列出了数据库中的单词，并允许您添加新单词。
应用程序中有八个类：
1.MainActivity
- NewWordActivity
3.Word - WordDao
- WordListAdapter
- WordRepository
- WordRoomDatabase
WordViewModel
没有太大困难，我可以实现理想的组织，成功率约为90％：
在这里插入图片描述
一些担忧
在 LiveData 作为一个元素不会在组织的任何地方出现。虽然确实 LiveData 是一个设施/机制，但它不是政策意义上的实体。
干净的架构说，“外圈是机制。内圈是政策。” 在此基础上，它将DB放在最外层。但是，如果不打破核心原则，我无法将DB放在外圈。
我知道这更多地表明当前技术中的数据库如何变得更加广泛，而不是实现细节。
我唯一关注的另一个问题是，当ViewModel 坐在UI控制器中时，关注细节的分离感 ，而 ListAdapter 应该处理显示的数据。适配器能够观察任何变化的视图模型。如果我们这样做，那么我们可以说适配器几乎决定了从存储库端显示的数据。UI负责维护组件的正确UI外观。考虑到这一点，我在适配器中移动了视图模型，它向UI公开了一个额外的方法“insert（..）”。修改后的代码在这里：ViewModel的房间。
通过这样做，我可以更清楚地了解干净的架构圈子，它 LiveData 是存储库使用的内部工具
在这里插入图片描述
结论
Android清洁架构是一个可以在没有大量框架的情况下实现的目标，只要我们专注于关注的认知分离，以及测试设施，它在Kotlin中变得更加语言驱动，而不会打扰关于工具和设施的性质。我们始终坚持这样的原则：“总的来说，你走的越远，软件就越高。” 更高级别仅仅意味着更具包容性，就像现在的数据库实现一样。我们不再关心它是什么类型的DB，只要它保持暴露的接口完好无损。由于开源的能量，我们可以通过认知镜头看到今天的工具，而不是将我们的手和思想联系起来。反过来，这也使得开源移动得更快。
