Android模块化开发方案

随着业务的不断发展壮大,移动端所承担的功能也越来越重,特别是代码几易其主之后开始变得杂乱无章,牵一发而动全局的事情时常发生。为了应对团队壮大之后的开发模式,我们必须要对业务进行隔离,同时沉淀出通用组件,完善移动开发的基础设施。

作者:jiashuai

CSDN:http://blog.csdn.net/jiashuai94

github:https://github.com/shuaijia

1

痛点

模块化以前,我们主要面临以下几个痛点:

  • 业务边界不清晰
  • 通用代码与业务代码耦合
  • 代码重复、资源重复
  • 代码散乱、常亮漫天飞
  • 代码臃肿 等

其中业务边界不清晰是最大的痛点,最直接的表现就是处处有雷,经常会引入新的 Bug,而且很多 Bug 往往不能从根本上解决,代码维护成本居高不下。

2

重构原则

模块化并不能一蹴而就,我们在重构的同时也在做新需求,每次看到那一坨旧代码心中就会有无数只”草泥马”奔腾而过,干脆重写的无奈之情难以抑制,结果在红牛的日夜陪伴下写出来的新代码虽然看上去“漂亮”,但是实际上问题更多,得不偿失。总结了重构的三项基本原则:

2.1渐进式重构

如果一段代码已经比较稳定,可以从中抽取一部分功能重写,不要一上来就全部推翻重写,可以慢慢淘汰掉老代码。

2.2清理业务再动手

App 作为业务链的末端,由于角色所限,开发人员对业务的理解比后端要浅,所谓欲速则不达,重构不能急,理清楚业务逻辑之后再动手。(可以找熟悉业务的同学聊一下 — PD、后端、测试)

2.3Android、ios互相参考

业务代码总是惊人的相似,两端互相参考的过程中,不但可以 Review 代码,还能加深对业务的理解,可谓一举两得。 实践证明,如果人手紧张,项目早期可以只让一端的开发人员跟需求,另一端直接“翻译代码”,甚至一个人写两端代码。

3

模块化过程

所谓模块化,是一个分而治之的过程,首先进行垂直拆分,过程中必然会催生出业务共享的 Common 模块,而 Common 又可以继续水平拆分,逐渐变薄,直到 Common 消失。 刚开始模块划分可以简单点:

3.1common抽取

Common 层服务于所有的上层业务,是通用层,不允许引用业务层代码。

  • 首先把 Common 层用到的 Business 层代码下放到各个业务
  • 然后把多个 Business 之间共用的代码提取到 Common 层
  • 资源文件的处理方式与代码一致

但抽取Common不是终点,随着代码结构逐渐变得清晰,在业务隔离的同时,不断丰富 Common 模块,然后在某个节点将其再拆分成一个一个独立模块

3.2业务隔离

业务模块之间不能互相依赖,只能单向依赖 common。

3.2.1 跳转协议

页面解耦可以借鉴 Web 的设计原理,给业务模块中对外的页面定义一个 URI,然后页面之间通过 URI 跳转。

举个栗子,A、B 两个页面分属于不同的业务模块,在页面未解耦之前,A 如果要跳转到 B,必须要依赖 B 的模块,那么跳转代码会写成如下形式:

如果 A、B 之间还需要传递数据,就要共享常量、Model,耦合继续加重。 如果我们为 B 页面定义一个 URI - wsc://home/bbb,然后把共享的 messageModel 拍平序列化成 Json 串,那么 A 只需要拼装一个符合 B 页面 scheme 的跳转协议就可以了。 wsc://home/bbb?message={ “name”:”John”, “age”:31, “city”:”New York” } URL Router 有很多种实现方式,网上资料也是多如牛毛,这里只提供一种思路。

3.2.2 PRC

Android 通过 interface 提供服务,即回调或监听器模式或观察者模式。它的优势在于可以只在业务提供方的 module 中定义interface,解耦更彻底。

3.2.3 主项目module

但我们一般会在各业务模块Module之上,再创建主项目的Module,它依赖于各模块Module,通过它来实现各模块间的交互和页面跳转。

4

代码管理

如果被隔离的业务模块仍然在一个 Project 中,就无法从“物理”上彻底隔绝代码间的相互引用,我们需要从工程上保证业务之间互相独立。

每一个 subProject 可以独立发版,然后通过坐标依赖组装成 App。

5

另外

实现模块化开发,有两种思路:组件化开发和插件化开发: 以上我们介绍到的就是组件化开发,将各功能模块分离成相互独立的组件,最后由主module来集成调度; 插件化开发一般适用于不是必选功能,而是使用时下载插件的功能,例如:皮肤包、银联插件化开发等

原文发布于微信公众号 - Android机动车(JsAndroidClub)

原文发表时间:2017-09-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程一生

架构师之路--谈业务的合理架构

932
来自专栏Seebug漏洞平台

Sebug 大牛支招之我是如何在Sebug中杀入前10的?

大家好我是koshell,ID:k0sh1, 在之前的文章中我分享了在web漏洞挖掘中的一些小技巧,这里要补充一下。 注入其实只是众多web入侵手段中的一种,脱...

3757
来自专栏Flutter入门到实战

开发工具总结(9)之开源项目的README文档的最全最规范写法

版权声明:本文为博主原创文章,未经博主允许不得转载。https://www.jianshu.com/p/813b70d5b0de

1071
来自专栏Java架构师学习

多研究些架构,少谈些框架——一名阿里架构师的笔记

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为...

3758
来自专栏云计算与大数据

Envoy——Service Mesh体系中的私人订制,把你安排得明明白白!

最近因工作原因开始了解Service Mesh与Envoy,为系统性梳理所学内容,因此沉淀了此文档,但由于所知有限,如文档中有描述不当之处,希望不吝赐教。

2422
来自专栏JAVA高级架构

JVM并不是那么重量级

译者注:很多人误认为JVM是一个很重量级的框架,本文作者之前也是这么认为的,但是在这篇文章中,作者从几个层面分析了一下,可以看出JVM并不是我们想象中的那么“重...

2795
来自专栏玉树芝兰

安装 Python 软件包遇错误,怎么办?

本文通过一个命令行转换 pdf 为词云的例子,给你讲讲 Python 软件包安装遇挫折时,怎么处理才更高效?

1472
来自专栏逸鹏说道

.NET技术+25台服务器怎样支撑世界第54大网站

英文原文:StackOverflow Update: 560M Pageviews A Month, 25 Servers, And It's All Abou...

3817
来自专栏社区的朋友们

Amazon Aurora 深度探索(一)

本文对 Aurora 系统的实现从整体架构、存储、事务处理三个方面进行深入探讨,基于其论文和相关资料讨论具体实现细节,又跳出其外、从数据库内核技术实现的角度对 ...

2.1K2
来自专栏程序人生

再谈 API 的撰写 - 总览

背景 去年我写过一篇文章:撰写合格的 REST API。当时 Juniper 裁掉了我们在德州的一支十多人的团队,那支团队有一半的人手在之前的半年里,主要的工作...

4157

扫码关注云+社区

领取腾讯云代金券