看了十几篇MVX架构的文章后，我悟了...

当经过学一遍又一遍，改一遍又一遍，觉得学不懂想哭的时候，我选择了放弃（洗澡），然后我悟了。

适当开摆有益身心健康

当你纠结于文件该放在哪个包下，纠结于什么功能的代码应该放在哪个类中，于是在学习过程中不断修改，不断重构...开始了这样一个循环。

这有很大一部分原因是因为不统一，架构是一种设计思想，而且大部分是由国外公司、大牛提出，首先在语言理解上就会有一定的差异和误解，如果我们能正确理解设计原则，就可以事半功倍。

就比如并发和并行，看过很多对于这两个的解释就是：并发是多个任务交替使用CPU，同一时刻只有一个任务在跑；并行是多个任务同时跑。

其实就是一种误解，【并发】和【并行】描述的是两个频道的事情。并发是一种处理方法，通过拆分代码，各部分代码互不影响，这样可以充分利用多核心。所以如果想让一个事情变得容易【并行】，先得让制定一个【并发】的方法。倘若一个事情压根就没有【并发】的方法，那么无论有多少个可以干活的人，也不能【并行】。

回到MVX架构，对于怎么样分包，怎么样拆分代码，我觉得应该从思想原理入手，因为文章的写法是各个作者理解，他们的理解不一定就是正确的，包括我。

就以谷歌推荐的架构原则来说，它有以下4点：分离关注点、通过数据模型驱动界面、单一数据源、单向数据流；推荐的架构图如下：

按照上面这张图，我们在Activity中写界面和界面的展示的数据，现在回看架构原则第一点”关注分离点”，于是我们把界面和界面的数据拆分开，这个过程是自然而然的，所以我更倾向于发挥自己的想象力去把架构实现好，而不是去进行拙略的模仿，现在回想起来20年时我在写项目的时候会自己思考如何去改进，于是自然而然添加了事件和状态（单向数据流），而在之前我并没有去看关于这方面的文章。

当你学习累了，那就大喊一句“开摆”，什么屁架构文章一边去，不学了。（优秀的文章还是值得我们学习的，这里只是我的情绪宣泄）

也许回过头你就学会了，这并不是什么魔法，而是把你从一个深坑中拉了出来，让你的大脑能换个方向思考问题。

我们需要重点学习的是设计原则，剩下的就是发挥我们的想象力。

相关资料

如何理解：程序、进程、线程、并发、并行、高并发？ - 大宽宽 知乎 (zhihu.com)

应用架构指南  |  Android 开发者  |  Android Developers (google.cn)