Android应用架构的发展和实践

• VM层，专门负责执行业务逻辑和数据的处理，与数据层有交互

• UI层，负责显示每个界面，弹窗等，与VM层有交互

如下图示：

单Module到多Module演变

---

这个演变非常像后台应用的单体架构到微服务架构的演变，适用于公司内部有多个产品需要同时迭代的场景。随着单体应用向多Module的演变，原先的各个组件都独立到不同的Module中去了。

大概有两个阶段：

1. 单一入口Module + 公共类库Module

2. 多入口Module + 多公共业务Module + 公共类库Module

第一个阶段很好理解，也是一个自然而然的演变。因为项目中很多公共的模块，比如日志模块，网络模块，数据模块。这些模块与逻辑无关，可以给任何项目使用，所以单独开一个Module或者传到maven库。如果要开发新的项目，那也只是将公共类库Module移植过去即可。

所以，第一阶段的项目Module结构大概是这样：

• App Module，负责提供项目入口，完成各个业务逻辑功能

• Library Module，负责提供项目公共组件，比如日志组件，网络组件，存储组件

• 其他三方库Module

以抖音App为例：

上面的阶段能做到功能模块的重用，但是没有涉及到业务逻辑的重用。新项目也有登录注册功能，难道要重新写一遍么？

你可能担心两个项目的登录注册逻辑能一样么，界面也不可能一样啊。界面肯定是不一样的，但是登录注册逻辑大部分是一样的。这就说明我们其实可以对一些公共业务划分Module，对于不一样的地方，完全可以动态化。但是公共业务不能划入类库Module中，因为通用性不够；还要注意业务Module的抽离本着只抽业务，不抽UI的原则。

当业务Module和类库Module抽离之后，不同的项目我们可以添加不同的入口Module，入口Module更多是完成入口功能，和UI定制化功能，以及完成一部分差异化的实在不能共用的业务逻辑。

所以，第二阶段的项目Module结构大概是这样：

• App1 Module，负责提供App1的入口，完成App1的所有UI逻辑和部分不能共用的业务逻辑

• App2 Module，负责提供App2的入口，完成App1的所有UI逻辑和部分不能共用的业务逻辑

• Login Module，负责提供登录注册功能

• Video Module，负责提供视频相关功能

• Library Module，负责提供公共模块功能

• 其他三方Module

客户端开发中，UI的变数最大，上面的Module划分尽量将变化少的东西复用，将变化大的东西剥离出来。

他们之间的调用关系应该符合这样的规则：

• App入口Module可以调用业务Module和Library Module；

• 业务Module可以调用Library Module，业务Module之间不能相互调用，也但不能调用App入口Module，目的是保持单向调用流程

• Library Module只能被调用。

以抖音App为例：

如果你发现业务Module需要调用App入口Module，或者其他情况，可能你的Module架构设计有问题。

Module间通信

---

其实上面的架构不存在Module之间的通信，也不需要。

假设这样一个场景： 在App1中的登录界面，调用的Login模块的登录逻辑，登录完成后需要跳转用户信息界面。

上面的场景只需直接调用Login模块的逻辑即可，即便发生了不同UI跳转，也不需要Module通信，因为所有的UI都写在App1中了。

如果当初将登录相关的UI也抽到Login模块中，看起来封装度更高，其实有很多不方便。在上面的场景中，需要从Login模块的UI调用其他模块的UI，这样调用流程变得复杂，而且必须要ARouter这样的通信工具；问题是Login的UI在各个App中不太可能一样，如果一样，那么则可以抽进去。

插件化和热修复

---

很多大厂的App功能实在是太多，如果一开始就将所有功能都纳入App中，体积下不来，问题是有一些功能很多人从来也不用。

所以从使用程度和重要性程度可以划分等级，对于那些次要的功能和模块进行动态化。一开始App只提供部分重要和必须的功能，并且提供一个class运行容器。当用户需要哪些功能是就进行下载，下载下来的无非是一些class和资源，通过定制的类加载器来加载，并做好生命周期管理和资源与Context的统一，这就是大部分插件化框架的原理。

插件化对于大部分中小公司是不需要的，可以根据需要采纳。

热修复是指将新功能或者Fixed Bug快速更新到用户的App中，而不用重新下载App。大致原理是先计算出含有新功能的Apk和旧Apk之间的差异，得到一个diff包，一般很小。然后用户直接下载diff包，App中预先内置了class动态替换的框架，将diff包加载进来就实现了动态热修复。目前热修复存在一些兼容性问题。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后

简历首选内推方式，速度快，效率高啊！然后可以在拉钩，boss，脉脉，大街上看看。简历上写道熟悉什么技术就一定要去熟悉它，不然被问到不会很尴尬！做过什么项目，即使项目体量不大，但也一定要熟悉实现原理！不是你负责的部分，也可以看看同事是怎么实现的，换你来做你会怎么做？做过什么，会什么是广度问题，取决于项目内容。但做过什么，达到怎样一个境界，这是深度问题，和个人学习能力和解决问题的态度有关了。大公司看深度，小公司看广度。大公司面试你会的，小公司面试他们用到的你会不会，也就是岗位匹配度。

选定你想去的几家公司后，先去一些小的公司练练，学习下面试技巧，总结下，也算是熟悉下面试氛围，平时和同事或者产品PK时可以讲得头头是道，思路清晰至极，到了现场真的不一样，怎么描述你所做的一切，这绝对是个学术性问题！

面试过程一定要有礼貌！即使你觉得面试官不尊重你，经常打断你的讲解，或者你觉得他不如你，问的问题缺乏专业水平，你也一定要尊重他，谁叫现在是他选择你，等你拿到offer后就是你选择他了。

金九银十面试季，跳槽季，整理面试题已经成了我多年的习惯！在这里我和身边一些朋友特意整理了一份快速进阶为Android高级工程师的系统且全面的学习资料。涵盖了Android初级——Android高级架构师进阶必备的一些学习技能。

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

[外链图片转存中…(img-Vqy98Yrw-1711787344036)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！