你的位置:首页 > 操作系统

[操作系统]Android 设计随便说说之简单实践(消息流动)


在上面两篇分别说明了设计中较为简单也是很关键的实践点。

第一模块划分,它是根据每个模块所承载的业务,进行划分,是应用程序一个静态的描述。

第二合理组合,它是是将每个模块调动起来,共同实现业务,是一个准动态的说明。

今天主要说明真个应用程序中消息和数据,以及如何循环,是完全动态的。同时也简单的提到各种设计框架。是终结篇。

我们先拿下载这个业务来说。显示用户点击了界面下载按钮onClick,然后onClicK调用调度层的onStartDownLoadApp(Item), 而调度层又将指令业务单元模块下载模块。调用下载模块的onStartDown(Item)。从这里可以看出,消息是一层一层的向下传递去。此时下载模块开始下载到数据,然后上报下载进度downLaodProgress(id, progress),该方法传递了下载项信息(id)和进度信息(progress),并且调用到调度层的downLoadAppProgress(id,progress),调度层的该方法有经一部的调用onUpdateProgress. 从而实现从下载模块到页面的一个数据的传递。

注意从下载模块向上报进度的时候,是异步的,因为下载是异步的,所以上报进度需要到主线程里,所以相对下载来说该消息是异步的才能到主线程。

 

由上可见,

1  消息的一步步同时下发,而且必然经过调度层。

2  数据的上报也是一层一层上传,而且必然经过调度层。

 

当然,还可以举其他例子,这里就不在举例了。总体来说在设计的时候,务必要理清楚消息和数据是如何流动,才能完整的总结出业务模型并且切合到设计中。

设计模型中有MVC,MVP,MVVM。其中MVC有个特征就是不但C可以更新V而且M也可以更新V(圆形的消息流),那么这样设计过程中V不但要照顾到C还要照顾到M,而M同样不但要照顾到C还要照顾到V。这样显然是体现了复杂度。但是在大型的web项目中是很常用的。而MVP和MVVM的特征是V只和P(或者VM)相互调用,不被M调用。M只和P(或者VM)相互调用,而和V没有直接关系。因此在设计中,V和M不必相互照顾。

上面提到的都是比较成熟的设计模型,但是无论那种设计模型都追求的目标是“低耦合,高内聚”,各个模块相互照应但是有各司其职。照应中需要做到很好的解耦。

设计中常常用的五视图方法,该方法比较全面,即考虑的周围的运行环境和关联模块,也从动态和静态描述了程序内部的接口和联动方式。我用这种方法做过两次设计。还是很不错。以上四篇是结合他的理论以及我的实践一个简单的总结。

突然想到还有一点没有谈到,就是业务的变化与不变的考虑。这个也是非常重要,设计中要充分的考虑到那些业务会发生变化,如何将变化锁定在可控的范围内。这就需要一层接口,通过接口来规范可变的业务实现,及无论业务如何变化,都必须遵守该接口的契约。

完了。