-
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之间的通信,也不需要。
假设这样一个场景: 在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,里面包含了各种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应该是插件化和动态化的未来,从工程建设的角度帮开发者完成了产品的动态交付。也许,在不久的将来国内商店也会支持这种功能。
每种架构都用自己的优缺点,不能盲目采用多体的架构,也不能偷懒就永远不升级架构;最终采用什么样的架构要根据自己项目体量和发展来判断。
根据我的经验,对于大部分公司来说,多体架构的初级阶段就完全够用了。对于同一个团队需要同时迭代多个项目的场景,可能需要发展到多体架构的第二阶段。对于海量功能的App,可能需要插件化。
这些只是我个人的见解和经验,希望大家踊跃讨论,交流一下你们的宝贵经验,互相提高下!
作者:dance
链接:https://juejin.im/post/5c6656c9e51d451b08296d43
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
结尾
如何才能让我们在面试中对答如流呢?
答案当然是平时在工作或者学习中多提升自身实力的啦,那如何才能正确的学习,有方向的学习呢?为此我整理了一份Android学习资料路线:
这里是一份BAT大厂面试资料专题包:
好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划。来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划。来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!