博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【工作感悟】Android多进程从头讲到尾,offer拿到手软
阅读量:2063 次
发布时间:2019-04-29

本文共 2721 字,大约阅读时间需要 9 分钟。

开头

互联网时代的到来,让我们获取知识变得更加简单,理论上讲只要你想学,便会有不尽的知识等你,只要方法得当,够努力,任何人都可以都有可能成为大牛。

自己在努力的基础上,还学习了一些高效的学习方法,让我在学习的过程中更加高效,更迅速的掌握,以下是我学习Android的一些套路。

此次手写架构,解决的问题是:

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的一个包里面,当你要移植某一个功能的时候,想想那酸爽…当然如果你口味别致,那当我没说)

理想:

image

理想化的话,参照:理想.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学习方向及思路(详细的内容太多了~),提供给大家:

对于程序员来说,要学习的知识内容、技术有太多太多,这里就先放上一部分,其他的内容有机会在后面的文章向大家呈现出来,不过我自己所有的学习资料都整理成了一个文档,一直在不断学习,如今整理的资料不知不觉居然已经有将近80G了,在这里作为读者福利免费分享给大家,希望能帮助到大家,也节省大家在网上搜索资料的时间来学习,也可以分享动态给身边好友一起学习!

资料获取传送门:

群内有许多技术大牛,有任何问题,欢迎广大网友一起来交流,群内还不定期免费分享高阶Android学习视频资料和面试资料包~

为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!希望读到这的您能点个小赞和关注下我,以后还会更新技术干货,谢谢您的支持!

Android架构师之路很漫长,一起共勉吧!

如果你觉得文章写得不错就给个赞呗?如果你觉得那里值得改进的,请给我留言,一定会认真查询,修正不足,谢谢。

小赞和关注下我,以后还会更新技术干货,谢谢您的支持!**

Android架构师之路很漫长,一起共勉吧!

如果你觉得文章写得不错就给个赞呗?如果你觉得那里值得改进的,请给我留言,一定会认真查询,修正不足,谢谢。

转载地址:http://msqlf.baihongyu.com/

你可能感兴趣的文章
时隔多年。。终于有一款云原生消息系统出仕了!
查看>>
[译]数据包在 Kubernetes 中的一生(1)
查看>>
[译]数据包在 Kubernetes 中的一生(2)
查看>>
[译]数据包在 Kubernetes 中的一生(3)
查看>>
从源头解决 Service Mesh 问题最彻底!
查看>>
一次“不负责任”的 K8s 网络故障排查经验分享
查看>>
一次有趣的 Docker 网络问题排查经历
查看>>
KubeSphere Meetup 北京站火热报名中 | 搭载 CIC 2021 云计算峰会
查看>>
深入理解 Linux Cgroup 系列(一):基本概念
查看>>
深入理解 Linux Cgroup 系列(二):玩转 CPU
查看>>
云原生周报第 1 期 | 2019-06-24~2019-06-28
查看>>
Kubernetes Pod 驱逐详解
查看>>
kubectl 创建 Pod 背后到底发生了什么?
查看>>
[译] Kubernetes 儿童插图指南
查看>>
云原生周报第 2 期 | 2019-07-01~2019-07-05
查看>>
kubectl 创建 Pod 背后到底发生了什么?
查看>>
Kube-scheduler 源码分析(二):调度程序启动前逻辑
查看>>
kubernetes 1.15 有哪些让人眼前一亮的新特性?
查看>>
云原生周报:第 3 期
查看>>
深入理解 Linux Cgroup 系列(三):内存
查看>>