美文网首页Android开发Android开发经验谈Android开发
关于 Android 架构选择的一点思考

关于 Android 架构选择的一点思考

作者: 迷途小码农h | 来源:发表于2019-04-20 12:01 被阅读5次

    架构的选择

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

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

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

    Android Clean 架构

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

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

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

    1. 一种更清晰的Android架构

    2. Architecting Android…The clean way?

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

    事件驱动架构

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

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

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

    相关文章

      网友评论

        本文标题:关于 Android 架构选择的一点思考

        本文链接:https://www.haomeiwen.com/subject/pwvkgqtx.html