Android APP架构思考

来自:xiaxveliang

关于本文介绍的小架构我做了一个demo,地址如下:
https://github.com/xiaxveliang/Android_APPArchitecture_Demo

正文开始了

从2011年到现在,做了几年的Android应用与Android平台上Opengl es应用开发,下面是关于Android APP开发架构的一些思考:

构建框架的最终目的是增强项目代码的可读性 ,维护性 和方便测试 ,如果背离了这个初衷,为了使用而使用,最终是得不偿失的。

从根本上来讲,要解决上述的三个问题,核心思想无非两种:一个是分层 ,一个是模块化 。两个方法最终要实现的就是解耦,分层讲的是纵向层面上的解耦,模块化则是横向上的解耦。

在写Android APP相关代码时,如果“客户端只做数据展示,不做用户交互逻辑”这样的APP,基本Bug都很少。思考其原因,可能是这样的APP代码逻辑简单。

我们知道 代码越简单、易读,越不易出bug,但APP功能越来越复杂,代码量越来越多,好像随之代码也会越来越复杂。

一、那我们能不能设计一个,只做数据展示,不做用户交互的APP架构呢?

001.png

上边的截图,是关于 只做数据展示,不做用户交互的APP架构思考。

朋友们可能已经注意到,这是典型的MVC。
这里Model层来管理数据,并继承Observable,而每一个controller(Activity)均实现Observer。这样若某一个Activity需要获取某一种类型Model数据时,只要在其对应Model中注册观察者。

二、下边是关于上图的简单介绍:

  • (1)、用户触发登录——>帐号密码请求服务器——>服务端返回登录数据——>登录model(登录model存登录用户数据)——>登录model通知“登录Controller”——>更新登录页面UI
    ——>登录model(登录model存登录用户数据)——>登录model通知“更新用户详情Controller”——>更新用户详情页面UI

  • (2)、这里model为被观察者,controller可根据需要在相应model进行观察者注册,这样model层中对应数据发生变化时,对应的controller便可收到页面更新的通知,完成页面更新。

三、那只做数据展示,不做用户交互又是怎么回事呢?

  • (1)、这里通过Model把用户操作转化为数据更新( 用户操作——>Model——>回调所有的观察者Observer(controller)——>更新UI )

  • (2) 、另一个好处是,可以用这套回调机制,替换Android中的广播来传递消息(单进程中)
    所有数据的变化,均通知对应的数据Model,通过Model回调到对应的Activity,Activity再更新UI

四、目前这种小架构是可以满足一般业务量APP需求的,那随着业务量的增大,该如何设计APP框架呢?

以上的框架图是可以满足一般的Android APP业务需求的。但如果客户端功能越来越复杂,可按业务分为不同的功能模块,模块内部使用以上介绍的框架和通信方式。
模块内部,采用观察者回调进行通信;模块之间采用广播(或者其他进程间通信方式)进行通信:

002.png

这里以广播举例:
1、主模块内部采用事件回调进行通信
2、主模块使用广播将事件传递给子模块
3、每个子模块内部采用事件回调进行通信

五、与MVP MVC的比较

在无用户UI操作介入时小架构MVC之间的关系如下

003.png

正好与MVP的不谋而合,MVP三者的关系如下:

004.png

关于MVP的文章,可参考Android MVC MVP MVVM
在用户UI操作介入后小架构MVC之间的关系如下

005.png

传统的MVC模型如下:

006.png

关于MVC的文章,可参考Android MVC MVP MVVM

http%3A%2F%2Fblog.csdn.net%2Fxiaxl%2Farticle%2Fdetails%2F72593871

PS: 由此可见,小框架与传统的MVC又也有所不同,算是MVC的一个变种,类似于MVP

推荐↓↓↓
安卓开发
上一篇:Android P 网络请求相关总结 下一篇:Android 热修复原理