标签：代码 内含 安卓 业务 module gradle 面试 模块 app
开篇
说一下我大概的情况。渣本毕业，工作已经有快3年了，从高中就开始玩小破站。无论是学习还是日常放松都是在b站。大学主学的软件技术专业，所以，入职bilibili是我大学时期给自己定的小目标。
在学校，专业学的算中上的水平，课本知识和老师讲的东西基本消化的八九不离十，也自己动手写过属于自己APP，参与过一些社团协会共同开发的项目。
刚毕业时候，b站也有校招，满腔热血的参加了，准备了好久，结果还是没有被录用。当时，挺失落的吧，但是也并没有放弃我进B站工作的梦想。
7月份的时候一位学长知道我非常想进bilibili，特意告诉我B站有内推名额，问我要不要来试一下，我一口直接答应，然后把手里的工作辞掉了，破釜沉舟一把，宅家里半个月复习。将学校所学知识点，以及工作3年的积累经验都系统的归纳整理了起来。再过一篇，然后就是刷面经，面试场景练习等等等。
世间所有的付出终是有回报的，努力的耕耘，也没有被辜负。从离职到入职，一个月时间，顺利的入职了哔哩哔哩，也是要感谢网友们提供的宝贵经验，所以整理了一下，把我的面经整理一下也分享出来给大家。
此次手写架构，解决的问题是：
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，免除人为创建的麻烦.
最后
给大家送上我成功跳槽复习中所整理的资料，由于文章篇幅有限，所以只是把题目列出来了，我自己手头上整理的资料均和上面的答案可免费分享，需要这些资料和答案的朋友，可以点击这里免费领取。
6%AA%EF%BC%81.md)。**
[外链图片转存中…(img-SOclLT7Z-1618318474155)]
[外链图片转存中…(img-nTr9DgiT-1618318474156)]
标签：代码,内含,安卓,业务,module,gradle,面试,模块,app 来源： https://blog.csdn.net/m0_56252652/article/details/115678548
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。