Android应用架构的发展和实践，androidsdk环境配置

浅沫记忆

所以，第一阶段的项目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包加载进来就实现了动态热修复。目前热修复存在一些兼容性问题。
无论是插件化还是热修复，不建议自研，大厂有过丰富的经验和实践，可直接使用目前成熟的类库。
[]( )App Bundle
一般来说，我们开发的App，里面包含了各种dpi的资源，兼容各种CPU架构的so库，这大大增加了Apk的体积。可用户事实上只需要匹配他手机的一种dpi和一种so库就足够，其他的对于用户来说都是冗余，上面讲的插件化解决了在功能方面的冗余问题。
能不能将所有的资源，so库等也按需下载安装呢？谷歌在AS3.2中提供的App Bundle功能就是干这个的。之前用户需要下载所有的资源，下载只会下载和自己设备匹配的资源，大大提高了产品的交付速度和交付质量，可是目前只支持Google Play。

App Bundle会将我们Apk的所有东西打为压缩包上传到Google Play。而Google Play会在用户下载的时候，根据设备特性生成优化过的Apk给用户安装。
App Bundle也支持动态apk，支持将暂时不需要的功能配置为动态功能，在用户需要的时候下载，也就是上面的插件化的功能。
App Bundle应该是插件化和动态化的未来，从工程建设的角度帮开发者完成了产品的动态交付。也许，在不久的将来国内商店也会支持这种功能。
文末
不管怎么样，不论是什么样的大小面试，要想不被面试官虐的不要不要的，只有刷爆面试题题做好全面的准备，当然除了这个还需要在平时把自己的基础打扎实，这样不论面试官怎么样一个知识点里往死里凿，你也能应付如流啊~
小编将自己6年以来的面试经验和学习笔记都整理成了一个937页的PDF，以及我学习进阶过程中看过的一些优质视频教程。上传在我的GitHub中：Android架构视频+BATJ面试专题PDF+学习笔记请君自取，无偿分享！

其实看到身边很多朋友抱怨自己的工资很低，包括笔者也是一样的，其原因是在面试过程中没有给面试官一个很好的答案。所以笔者会持续更新面试过程中遇到的问题，也希望大家和笔者一起进步，一起学习。