最近在总结过往工作中的时候，对于曾经使用过的一些架构进行了一些思考，这里把得出的一些心得分享出来，对于其他领域也有一定的参考价值。
架构的选择
在遇到需要实现一个完整的项目时，就不得不考虑该如何整理代码结构，规划模块分层，模块中间如何交互等等问题。在一开始的时间，我会尝试套用各种各样的架构，不过最近回眸的时候，发现这种做法是错误的。天下架构千万种，适合你的却不多。
思考的起点，最好从变与不变这个角度来触发。首先了解哪些是变的，从这一点开始思考，将重心放在变的部分上面，这样的架构才是合理的。
我举一个例子，一个运营型很强的产品，经常开展各种活动，活动样式各不相同，逻辑复杂。变的地方，就在于灵活的活动上面。如果在客户端上埋各种卡片样式，不仅会使得客户端代码复杂，也无法满足活动的动态能力。每当上线一种新活动，就需要更新客户端版本。反之，将变的地方放置在服务端，客户端只做展示，不再需要知晓业务细节，这样就会好很多。客户端提供基础的展示能力，登录、下载等等基础操作，服务端通过双方协定好的协议下发对应的指令，就能灵活地展示卡片。
Android Clean 架构
通常我们开发的APP，变化最大的是业务需求。在这样的产品上面，每个迭代都有可能有新功能的加入，老旧功能的修缮。
Clean Architecture 对于这种业务变化较为频繁的应用而言，就需要在客户端本地做好基础工作，架构上要足够通用，支持新业务加入。满足这样的架构有很多，这里比较推荐[Clean 架构](https://github.com/android10/Android-CleanArchitecture)。
关于 Clean 架构的文章很多，我就不再这里具体展开了，大家有兴趣的，可以看以下的链接。
在这里还是强调下，变化的是新的业务需求和老旧业务的调整，因而需要在这里提供扩展性十足，鲁棒性高的架构。
事件驱动架构
并不是所有情况都能用上面的框架来实现。同样我用例子来说明，我们做一个播放器。播放器的逻辑是非常复杂的，需要考虑很多方面的事情，例如播放状态、用户操作、网络情况等等，如果我们正向思考，那这个代码就很难写了。
变的是播放的各种状态，用户操作等，而我们要做的就是去相应这些变化，而非正向地操作这些变化。这里的架构最好采用事件驱动模型，在实现中维护一个状态机，我们所需要做的事情是切换状态，并相应状态变化，这样写起来就会有条理很多。
State Machine 例如播放的状态，有 Idle、Preparing、Playing、Paused、Stopped 等等，UI界面上响应相应的状态并做出变化，例如播放按钮在接受到 Paused -> Playing 的状态变化后，将按钮由播放变为暂停。
One Model
这种模式一般适用于非常灵活的情形，例如我前面提及的第一个例子，在这种架构下，客户端作为展示平台，并不参与业务逻辑。这种架构有很多种实现方式，简单的方式有 webview，高阶一点的有各种 Web Native Framework。
但在这里介绍另一种方式，纯粹的 Native 方式。客户端自身作为一个渲染平台，指定自身可以支持的组件(Cards, Button, TextView etc.)，和相应支持的功能(Download, Jump to Web, Open File etc.)。客户端此时与服务端定义好协议，当服务器端根据协议下发指令时，客户端需要解析它们，并展示相应的组件，绑定上对应的操作，这样下来，客户端就成了一定程度上的浏览器了。
文档信息
- 版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
- 发表日期：2016年10月30日
- 社交媒体：weibo.com/woaitqs
- Feed订阅：www.woaitqs.cc/feed.xml
