Android应用架构思想分析

算算日子，工作刚好三年了。这篇开始，鄙人就要向着各种以前想起来就头大的方向努力前进了。作为在Android应用层搬砖多年的民工，首篇我想谈谈自己对架构思想的一些看法。如有不妥，还请拍砖。

盖楼的故事（虚构）

有一块地，两个区域，开发商分别让两个包工头负责开发。

包工头A办事干净利落，甩开膀子就开工了。为了省钱雇了一个全能的工人，他既要去采购盖房的材料，又要用这些材料盖房子。起初底层屋子结构简单，还能应付得来，到了后面复杂的设计需求时，忙的不可开交，经常精疲力尽，阻断了盖房子的进程，使得老板很是不开心，偶尔让他改个屋子结构，他要把整层楼都推到才能实现，严重影响了工期。画的图纸都是一次性的，不能重用，耗时又耗钱，开发商整天吹胡子瞪眼的跟在屁股后面催。

包工头B拿到开发商方案后，先召集小弟开了个会，确定了所有楼层的样式，并把它们拆分成独立的模块。按照模块划分给了各个负责人，有制定楼层样式的，有专门负责资源提供的，有负责运送资源的，有按照预定方案实施的等等。花了大半个月将所有任务都分配完毕，开始施工。虽然人雇佣的有点多，前面的时间也耽误了大半个月，但是一开工很快就赶上了隔壁楼。emmm，开发商喜笑颜开，点点头，这个钱花的划算，完事后以后就用包工头B了。

不久后，两块地都完工了。这时质检开始了，令人头疼的A区域，有个小毛病就要拆掉一大片地方去改造，有的地方改好了却又影响了其它地方，而反观B区域，专人负责只要改有问题的地方就好了。

后来，包工头A游走在各个小开发商，工资又低又累，而包工头B已经走上了人生巅峰。（哈哈，终结）

包工头B的巅峰秘籍

我们再来回顾一下包工头B的盖楼经过。

接到项目，没有立即开发，开会整理需求；

按需求、职能划分模块，并由对应的人员负责；

各功能模块的负责人扁平化管理，没有相互掣肘；

同样的，我们App的开发也是一样的道理，不能像包工头A一样把所有的任务都交给Activity去做。我们要像包工头B一样分层去创建App。大家可以了解一下clean Architecture，这里将App应用分为三层，内-中-外，然后由4个管理者分别去管理他们。

分层的准则：

• 由外到内抽象
• 内层不了解层，外层依赖内层
• 分工明确，相互独立

先来解释一下第一条，以往我们开发App都是先从界面开始，然后最终到业务逻辑。现在要反过来，接到需求，要先明确实体是什么

（举个例子，比如登录功能，它所描述的实体就是用户User），然后它有哪些行为（比如登陆，登出userCase）。最后再到具体功能实现。

内层不了解外层，还是拿登录来说，在内层只需要知道用户有登录以及登出的行为就可以了，至于它是如何进行这些行为，内层就不需要知道了，但是反过来外层要实现内层的行为就要知道内层有哪些行为于是便产生了依赖关系。内层能独立存在，而外层必须依赖内层。

分工明确，相互独立，讲的是各模块功能独立存在，就比如登录，和注册功能是相互独立的，各司其职，不能越俎代庖。

4个管理者

• domain：定义抽象实体，核心业务逻辑，以及数据输出接口。此层为纯java代码，建议直接创建java module。
• data：数据管理，分为本地的存储（sqlLite，sharedpreferences），以及服务端Api。
• device：与Android底层相关，如通知，蓝牙，传感器等等。
• app：我们最熟悉的层级，内部可以根据各自的喜好选择MVP，以及MVVM模式来实现UI界面。

App开发的流程

• domain层中定义抽象实体，设定其对应的行为。
• data层中，给予数据支持
• device层，按需开发

app层，这里以MVP为例，首先在presenter中实现domain层定义的所有行为，data层和device层协助。最后实现UI界面，完成功能。

最新评论