android 热修复基本原理，15 分钟的字节跳动视频面试，满满干货指导

前言

从去年底到前几天，不断被各路跳槽的朋友刺激着，他们都跟我说着同一件事：跳槽了，薪资翻倍了，去一家叫做字节跳动的公司了。

让我更加讶异的是一个在微博做移动开发的朋友跟我说他舍弃了年终奖，在春节之前就投入到这家公司的怀抱，这让我一度以为这个朋友是被传销了。

说实话，我内心早就被这些个朋友成功跳槽的消息撩拨的春心荡漾了，在这春色融融的夜晚我的代码也开始字节跳动了，今晚就跟大家分享下这些朋友们跳槽的故事。

此次手写架构，解决的问题是：

1、让 App 内 各个功能模块能够独立开发单元测试，也可以 所有模块集成打包，统一测试

独立开发更改 gradle.properties 的配置，使得每个功能模块都成为 application， 可以独立打包成 apk，单独运行。单个模块，独立测试。

集成打包更改 gradle.properties 的配置，使得原先每个单独模块，都变成 library，被 主模块引用，这时候只有主模块能够打包 apk，所有功能都集成在这个 apk 内。

2、实现 功能模块的整体移植，灵活拔插

故事背景当你们公司有多个安卓开发人员，开发出核心业务相同，但是 UI 不同，其他业务不同的一系列 App 时（如果核心业务是 X，你们有 5 个开发人员，做出了 A,B,C,D,E 5 个 app，都包含核心业务 X，但是除了 X 之外，其他的业务模块各不相同）这时候，如果领导要把 A 里面的一个非核心功能，挪到 B 里面...

现状开发 B 的程序猿可能要骂娘，因为他在从移植 A 的代码中剥离代码 遇到了很多高耦合，低内聚 的类结构，挪过来之后，牵一发而动全身，动一点小地方，整个代码满江红。

理想如果这个时候，我们通过代码框架的配置，能够把 A 里面的一个模块，作为一个 module 移植到 工程内部，然后主 module 来引用这个 module，略微写一些代码来使得这个功能模块在 app 中生效。那么无论是多少个功能模块，都可以作为整体来 给其他 app 复用。这样开发人员也不用相互骂娘了，如果挪过来的模块存在 bug 或者其他问题，也不用甩锅，模块原本是谁开发的，找谁就好了。

3、保证 App 内 业务模块的相互隔离，但是又不妨碍业务模块之间的数据交互

我们开发 app 的功能模块，一个业务，可能是通过一个 Activity 或者 一个 Fragment 作为对外的窗口,也可能是。***所谓窗口，就是这个业务，相对于其他模块，"有且只有"一个入口，没有任何其他可以触达到这个业务的途径。***业务代码之间相互隔离，绝对不可以有相互引用。那么，既然相互不会引用，那 A 模块一定要用到 B 模块的数据，怎么办呢？下文提供解决方案。

正文大纲

1、代码结构现状以及理想状态一览

2、功能组件化的实现思路，实现组件移植拔插

3、参考 ARouter 源码，写出自己的 Router 框架，统一通过 Router 来进行模块的切换 以及 组件之间数据的交互

4、使用组件 api 化，在模块很多的情况下优化公共模块的结构

正文

1、代码结构现状以及理想状态一览

现状；

代码有模块化的迹象，但是没有对业务模块进行非常明显的模块化（不明白啥意思是吧？不明白就对了，app 这个 module 里面其实还有很多东西没有展示出来，请看下图：试想，把所有的模块集中到一个 module 的一个包里面，当你要移植某一个功能的时候，想想那酸爽....当然如果你口味别致，那当我没说）

理想：

理想化的话，参照：理想.png; 项目结构层次分明，脉络清晰

按照图中的分层，详细解释一下：

外壳层：app module

内部代码只写 app 的骨骼框架，比如说，你的 app 是这个样子的结构：

下方有 N 个 TAB，通过 Fragment 来进行切换模块。这种架构肯定不少见。

这个时候，外壳层 app module，就只需要写上 上面这种 UI 架构的框架代码就行了，至于有多少个模块，需要代码去读取配置进行显示。你问我怎么写这种 UI 框架吗？网上一大把的，如果实在找不到，来我的 github

业务层

我们的业务模块，对外接口可能是一个Activity* *（**比如说，登录模块，只对外提供一个LoginActivity,有且仅有这一个窗口）或者 是一个Fragment，就像上图（典型的 app 架构.png）, 如果 app 的 UI 框架是通过切换Fragment来却换业务模块的话。用business**这个目录，将所有的业务模块包含进去，每个模块又是独立的module，这样既实现了业务代码隔离，又能一眼看到所有的业务模块，正所谓，一目了然。

功能组件层

每一个业务模块，不可避免的需要用到一些公用工具类，有的是第三方 SDK 的再次封装，有的是自己的工具类，或者自己写的自定义控件，还有可能是 所有业务模块都需要的 辅助模块，都放在这里。

路由框架层

设计这一层，是想让 app 内的所有 Activity，业务模块 Fragment，以及模块之间的数据交互，都由 这一层开放出去的接口来负责

gradle 统一配置文件

工程内部的一些全局 gradle 变量，放在这里，整个工程都有效

module 编译设置

setting.gradle 配置要编译的 module; 也可以做更复杂的操作，比如，写 gradle 代码去自动生成一些 module，免除人为创建的麻烦.

尾声

如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。

对于很多初中级 Android 工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对 Android 开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

这里，笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家梳理了多年的架构经验，筹备近 6 个月最新录制的，相信这份视频能给你带来不一样的启发、收获。

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

架构篇

《Jetpack 全家桶打造全新 Google 标准架构模式》

点击【蓝色字体】即可免费获得！