盒子
盒子
文章目录
  1. 引言
  2. 为什么要重视解耦,重视架构
  3. Android module架构
  4. Android project架构
  5. 小结

Android架构

引言

以下的app项目结构,相信大家都写过

|--package
   |--activity
   |--adapter
   |--constants
   |--dao
   |--entity
   |--fragment
   |--utils
   |--view

相同功能的类都放在同一个包中,耦合也特别严重,当工作了一段时间后,随着技术提升,我们知道了高内聚,低耦合,其中解耦是个非常重要的过程。这就涉及到了今天的主题:app架构

为什么要重视解耦,重视架构

这个有一定的Android开发经验的都知道,在开发完成后,我们的工作是维护,版本的升级,功能修改,功能增加,功能废除,如果类似引言中的项目结构,随便小改一下,其他模块随之就要改变,牵一发动全身。维护艰难,成本高昂。

Android module架构

良好的架构无疑会简化app结构,层次分明,降低维护成本,开发起来也得心应手。

  • MVC 最常见的,引言中的项目结构就是一个mvc
  • MVP 近两年Android小伙伴们推崇的架构
  • Flux FaceBook提出的Android架构,没尝试过,基于事件总线通信,个人不太喜欢
  • Clean 关于Clean框架的介绍,网上也有不少,尝试写过,分层明确,在mvp架构基础上更加深入解耦,但同时也带来一些负面的东西,比如逻辑的复杂性,写一般的小型app,没必要使用,因为太麻烦了,直观感受。

以上只是一个Android Moudle中使用的架构。Flux,Clean暂且不说,MVP优化module内部的解耦,可以尝试。

Android project架构

module的架构优化只能提升module内部的解耦工作。当一个app由多人协同开发,内部有多个module的时候,问题就暴露的更多了。

AndroidStudio 引入module概念,其实就是模块化,一个module一个功能。

举个例子:一款简易商城app,我们可以简单分为以下几个模块

  1. 主module,壳工程,依赖以下模块
  2. 搜索模块
  3. 购物车模块
  4. 结算模块
  5. 钱包模块
  6. 商品模块
  7. 升级模块

这样每个人负责一个或多个模块,互不干扰,看起来蛮不错的,结构分明。但是不能高兴太早,这只能算简单的app分块,当app越来越复杂的时候,module与module之间会不可避免的也会存在相互依赖,就像滚雪球一样,会变得越来越不可控,修改了一个模块,要花费心思寻找所有依赖module A的module N是否会出现问题,当需要删除一个模块的时候,所有依赖的module也都会报错。错综复杂。

因此,在app project架构上还要花心思。从去年开始,圈中从插件化流向组件化,因为相比于插件化,组件化不会过多的涉及编译层的问题,开发透明。组件化其中重要的一个概念叫“路由”
关于组件化,我也一直在思考。这两天正好看到了一片说组件化的文章,说的非常好,而且给出了代码,感兴趣的可以去看看,传送门:Android架构思考(模块化、多进程)

github上也有许多人开源出了不同的路由库,但是基本上都只涉及到了Activity之间的跳转。对于通信这块考虑的并不够。上文的方案可以很好的解决这方面问题,而且给出了多进程间通信的问题解决方案,很nice。

小结

关于Android的架构,按照以上所说,基本可以很好的优化,当然适用于大型项目,类似外包这种快速小型项目,那就没必要了。

转载请指明出处RobinBlog:http://robinx.net/2017/03/02/Android架构/