其他分享
首页 > 其他分享> > 安卓开发面试技能介绍,看懂这些帮你轻松解决就业问题!内含福利

安卓开发面试技能介绍,看懂这些帮你轻松解决就业问题!内含福利

作者:互联网

开篇

说一下我大概的情况。渣本毕业,工作已经有快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的一个包里面,当你要移植某一个功能的时候,想想那酸爽…当然如果你口味别致,那当我没说)

理想:

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,免除人为创建的麻烦.

最后

给大家送上我成功跳槽复习中所整理的资料,由于文章篇幅有限,所以只是把题目列出来了,我自己手头上整理的资料均和上面的答案可免费分享,需要这些资料和答案的朋友,可以点击这里免费领取

image

image

6%AA%EF%BC%81.md)。**

[外链图片转存中…(img-SOclLT7Z-1618318474155)]

[外链图片转存中…(img-nTr9DgiT-1618318474156)]

image

标签:代码,内含,安卓,业务,module,gradle,面试,模块,app
来源: https://blog.csdn.net/m0_56252652/article/details/115678548