Android知识笔记：对于Jetpack Compose的一次尝试，超强Android进阶路线知识图谱

在布局文件中我们给每个控件起一个名字（ID），而在程序中我们需要根据这个 ID 查找我们需要的具体控件，如TextView nameTextView = (TextView) rootView.findViewById(R.id.tv_name);页面中的每个控件都需要这样的操作获取，还要重新再起一个符合源码规范的新名字，对于几十甚至几百个控件的页面来说，完成这样的操作是相当繁琐相当痛苦的。

耦合严重

随着应用迭代，XML布局文件和源码都要同步地进行更改，也就是说每加一个控件，XML文件和源码都要相应地进行更改，如果XML中移除了某个控件而源码没有更改就会出现运行时异常，所以它们实际上是强耦合的。

方式不统一

一个页面布局既可以通过XML文件的方式静态指定，也可以通过编写源码的方式动态创建，这两种截然不同的方式虽然都可以实现页面布局，但毕竟是不同的语言，不同的系统，很难统一管理和维护。

架构缺陷

数据驱动视图思想的实现需要视图可以方便的与数据进行单向或者双向的绑定，只有Data Binding技术可以实现XML里插入代码，完成和数据的绑定，但是这样的操作就像JSP在HTML文件中插入Java代码一样，虽然简单直接，但是代码逻辑的连贯性、一致性以及可维护性会面临前所未有的挑战。

那什么样的UI构建方式才能避免上述的问题呢？什么样的构建方式才是简单有效的呢？我相信大多数人的回答都是 “声明式（declarative）”，在源码中声明式的构建UI既直观又不会损失源码的能力。但是这个愿景在实现上却又困难重重，怎么让Java或Kotlin拥有声明式语法的能力，怎么让排版布局更加的简洁直观，怎么避免 UI 逻辑和业务逻辑的耦合等等都是需要重点解决的问题，而我觉得Jetpack Compose是个很不错的尝试。

架构思想

---

关注点分离

关注点分离（separation of concerns）是最常见最出名的软件设计原则，也是每个开发者都应该了解并遵循的，其实关注点分离最初是对另外两个词的概括：耦合（coupling）和内聚（cohesion）。理论上，当我们写代码时，我们会把应用看成多个模块，而且还可能把每个模块看成多个单元，这些模块或单元之间的依赖关系就是耦合，也就是说，如果我在某处对一些代码进行了更改，那么我还必须对其他文件进行多少更改？

所以我们一般的想法就是尽可能的减少耦合。有时耦合是隐式的，那些我们依赖的依赖或者其他我们依赖的东西实际上是不确定的，