我也已经做了好几年开发了,还记得刚出来工作的时候觉得自己很牛逼,现在回想起来也蛮好笑的。懂的越多的时候你才会发现懂的越少。因为如果你的知识是一个圆,当你的圆越大时,圆外面的世界也就越大。
最近看到很多Android新手问Android学习路线,学习方法啊,如何入门啊,所以我从网上找了一些资料,然后以我的工作经验给大家总结一下,让大家少走弯路,提取一些工作中经常用到的技术。当然,说一千道一万,最重要的还是学以致用,把学过的知识融会贯通。
独立开发
更改gradle.properties的配置,使得每个功能模块都成为application, 可以独立打包成apk,单独运行。单个模块,独立测试。
集成打包
更改gradle.properties的配置,使得原先每个单独模块,都变成library,被 主模块引用,这时候只有主模块能够打包apk,所有功能都集成在这个apk内。
故事背景
当你们公司有多个安卓开发人员,开发出核心业务相同,但是UI不同,其他业务不同的一系列App时(如果核心业务是X,你们有5个开发人员,做出了A,B,C,D,E 5个app,都包含核心业务X,但是除了X之外,其他的业务模块各不相同)这时候,如果领导要把A里面的一个非核心功能,挪到B里面…
现状
开发B的程序猿可能要骂娘,因为他在从移植A的代码中剥离代码 遇到了很多高耦合,低内聚 的类结构,挪过来之后,牵一发而动全身,动一点小地方,整个代码满江红。
理想
如果这个时候,我们通过代码框架的配置,能够把A里面的一个模块,作为一个module 移植到 工程内部,然后主module 来引用这个module,略微写一些代码来使得这个功能模块在app中生效。那么无论是多少个功能模块,都可以作为整体来 给其他app复用。这样开发人员也不用相互骂娘了,如果挪过来的模块存在bug或者其他问题,也不用甩锅,模块原本是谁开发的,找谁就好了。
我们开发app的功能模块,一个业务,可能是通过一个Activity或者 一个Fragment 作为对外的窗口,也可能是。***所谓窗口,就是这个业务,相对于其他模块,"有且只有"一个入口,没有任何其他可以触达到这个业务的途径。***业务代码之间相互隔离,绝对不可以有相互引用。那么,既然相互不会引用,那A模块一定要用到B模块的数据,怎么办呢?下文提供解决方案。
1、代码结构现状以及理想状态一览
2、功能组件化的实现思路,实现组件移植拔插
3、参考ARouter源码,写出自己的Router框架,统一通过Router来进行模块的切换 以及 组件之间数据的交互
4、使用组件api化,在模块很多的情况下优化公共模块的结构
现状;
代码有模块化的迹象,但是没有对业务模块进行非常明显的模块化(不明白啥意思是吧?不明白就对了,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热修复框架、插件化框架、组件化框架、图片加载框架、网络访问框架、RxJava响应式编程框架、IOC依赖注入框架、最近架构组件Jetpack等等Android第三方开源框架,**这些都是属于Android开源框架设计思想的。如下图所示:
这位阿里P8大佬针对以上知识点,熬夜整理出了一本长达1042页的完整版如何解读开源框架设计思想PDF文档,内容详细,把Android热修复框架、插件化框架、组件化框架、图片加载框架、网络访问框架、RxJava响应式编程框架、IOC依赖注入框架、最近架构组件Jetpack等等Android第三方开源框架这些知识点从源码分析到实战应用都讲的简单明了。
由于文档内容过多,篇幅受限,只能截图展示部分,更为了不影响阅读,这份文档已经打包在GitHub,有需要的朋友可以直接点此处前往免费下载。
整理不易,觉得有帮助的朋友可以帮忙点赞分享支持一下小编~
.(img-A2vSQI6T-1614945956339)]
[外链图片转存中…(img-YPFqKboC-1614945956340)]
整理不易,觉得有帮助的朋友可以帮忙点赞分享支持一下小编~
你的支持,我的动力;祝各位前程似锦,offer不断!!!