架构——android架构演进概述

大鹏一日同风起，扶摇直上九万里。这篇文章主要讲述架构——android架构演进概述相关的知识，希望能为你提供帮助。
随着业务的发展和技术的变更，android开发也经历了以下几个发展阶段：

文章图片

看似高大上的名词，其实遵循着最简单的原则：分而治之（如何划分就是“架构”，简单的事情如何串在一起就是“接口协议”，CS领域太多这样的例子了。）
我的理解是，模块化/组件化/插件化都是一种广义的模块化，只是它们的实现方式不同而已。
模块化系统案例：

智能android设备：Launcher, Lock Screen, Live Wallpaper,AppStore,BatteryManager

Hadoop生态系统：HDFS,YARN,MapReduce等

单体应用业务代码 + 数据存储 + 接口请求 + 日志等各个模块杂糅在一个module中。
这种结构基本上已经不适用任何项目，只能作为个人的测试或者demo。
优点：

编译构建简单

缺点：

无法适用与复杂的业务结构

广义的模块化“Modular hardware lead to modular software”
模块化特点：

模块间耦合小（模块间一般通过接口进行通信/调用）
模块可替换(接口不变底层实现可替换)

模块化代价：

模块间调用复杂
需要拟定接口协议
兼容性问题（不同的module可能依赖不同的版本）

为什么需要模块化：

实现高内聚低耦合的代码
不同module可以并行开发和测试
灵活的集成/部署/升级

模块化的方式：

1. 分包
1. Android studio中分module
1. 应用拆分（一个应用拆分成多个应用）

侠义的模块话
android开发时，狭义的模块话就是在project中建立多个module。比如将数据库的处理建立一个module，业务代码建立一个module（业务很复杂的化也可以根据业务场景进行拆分），日志埋点作为一个module等
组件化
【架构——android架构演进概述】组件化是在狭义模块化思想上的一次演进，一个变种。

组件化的核心是角色的转换。在打包时，是library; 在调试时，是application。

文章图片

A在开发测试业务1时就可以把“业务1”作为一个Application，进行构建测试。当需要构建整个App时，“业务1”又是一个library，构建脚本就能控制这一切。
看似很简单，但是业务场景千奇百怪，还有很多问题需要解决：

业务模块之间的通信：如果时统一进程直接定义接口即可，跨进程可考虑使用AIDL
Main Activity入口问题：脚本控制使用不同的AndroidManifest文件
activity跳转问题：

插件化
待补充
实例：微信客户端架构演进参考：https://www.infoq.cn/article/wechat-android-app-architecture/
参考

https://github.com/MDCC2016/Android-Session-Slides
http://zjutkz.net/2016/10/07/%E5%85%B3%E4%BA%8EAndroid%E4%B8%9A%E5%8A%A1%E7%BB%84%E4%BB%B6%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%80%83/?utm_source=tuicool& utm_medium=referral
https://www.infoq.cn/article/wechat-android-app-architecture/