最近在总结过往工作中的时候,对于曾经使用过的一些架构进行了一些思考,这里把得出的一些心得分享出来,对于其他领域也有一定的参考价值。

架构的选择

在遇到需要实现一个完整的项目时,就不得不考虑该如何整理代码结构,规划模块分层,模块中间如何交互等等问题。在一开始的时间,我会尝试套用各种各样的架构,不过最近回眸的时候,发现这种做法是错误的。天下架构千万种,适合你的却不多。

思考的起点,最好从不变这个角度来触发。首先了解哪些是的,从这一点开始思考,将重心放在的部分上面,这样的架构才是合理的。

我举一个例子,一个运营型很强的产品,经常开展各种活动,活动样式各不相同,逻辑复杂。的地方,就在于灵活的活动上面。如果在客户端上埋各种卡片样式,不仅会使得客户端代码复杂,也无法满足活动的动态能力。每当上线一种新活动,就需要更新客户端版本。反之,将的地方放置在服务端,客户端只做展示,不再需要知晓业务细节,这样就会好很多。客户端提供基础的展示能力,登录、下载等等基础操作,服务端通过双方协定好的协议下发对应的指令,就能灵活地展示卡片。

Android Clean 架构

通常我们开发的APP,变化最大的是业务需求。在这样的产品上面,每个迭代都有可能有新功能的加入,老旧功能的修缮。

Clean Architecture
Clean Architecture

对于这种业务变化较为频繁的应用而言,就需要在客户端本地做好基础工作,架构上要足够通用,支持新业务加入。满足这样的架构有很多,这里比较推荐[Clean 架构](https://github.com/android10/Android-CleanArchitecture)

关于 Clean 架构的文章很多,我就不再这里具体展开了,大家有兴趣的,可以看以下的链接。

  1. 一种更清晰的Android架构
  2. Architecting Android…The clean way?

在这里还是强调下,变化的是新的业务需求和老旧业务的调整,因而需要在这里提供扩展性十足,鲁棒性高的架构。

事件驱动架构

并不是所有情况都能用上面的框架来实现。同样我用例子来说明,我们做一个播放器。播放器的逻辑是非常复杂的,需要考虑很多方面的事情,例如播放状态、用户操作、网络情况等等,如果我们正向思考,那这个代码就很难写了。

的是播放的各种状态,用户操作等,而我们要做的就是去相应这些变化,而非正向地操作这些变化。这里的架构最好采用事件驱动模型,在实现中维护一个状态机,我们所需要做的事情是切换状态,并相应状态变化,这样写起来就会有条理很多。

State Machine
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.)。客户端此时与服务端定义好协议,当服务器端根据协议下发指令时,客户端需要解析它们,并展示相应的组件,绑定上对应的操作,这样下来,客户端就成了一定程度上的浏览器了。


文档信息