网站建设需要具备的能力,域名查询工具,个人网店搭建思路设计,做英文网站违法吗作者#xff1a;究极逮虾户 最近面试了不少的公司#xff0c;行情整体来说还是非常差的#xff0c;如果没有必要不建议大家裸辞#xff0c;另外就不总结面试的题目了。这次打算着重从项目经验上来给大家讨论下#xff0c;我觉得这部分可能才是面试中得分比重比较大的部分究极逮虾户 最近面试了不少的公司行情整体来说还是非常差的如果没有必要不建议大家裸辞另外就不总结面试的题目了。这次打算着重从项目经验上来给大家讨论下我觉得这部分可能才是面试中得分比重比较大的部分如果你真的是要从八股什么的得分估摸现在也很难从池子中脱颖而出。
还有就是个人建议大家都要做好复盘工作每一段时间定期回顾下之前的工作内容。并不是所有的工作内容都是重复劳动要把自己工作内容中的一些难点进行总结无论是解决了一个bug或者是解决了个技术难题这样方便大家以后的面试中进行表述。如果都是在面试前进行回顾的话往往之前做的很多有意思的东西会被自己忘掉也很难很好的表述给面试官。世界上最痛苦的事情不就是你明明做了很多很好玩的事情但是没办法和对方描述出你做的是啥吗
聊项目
面试前一定要对自己的工作重点进行盘点如果觉得口才不好你可以先用文字的形式进行整理面试的时候用最少的语言让面试官能知道你之前做了什么带来了一些什么收益然后你的目标是什么你是如何分析出这些问题的最后你的解决方案是什么。你可以顺便总结下中长期规划是怎么样的当然这个也并不是所有的工作内容都需要说的。
另外再牛逼的技术你也是需要表述给别人能听懂的这个是非常非常重要。在面试过程中不妨多向面试官询问下他想要关注的内容是什么面试就是一个沟通的过程不妨多问问面试官并不会引起反感的。
还有你一定要好好的盘点下你最近的这段时间的工作内容的亮点是啥你想要和面试官聊的是什么内容。最好也提前了解下岗位因为不同的岗位职责你可能要准备的面试重点是不一样的比如我的米哈游面试我要准备的面试重点内容就是支付和推送相关的sdk设计如果我要面的是ci cd 岗位的话我要准备的面试内容就是和编译构建还有工程架构相关的内容。
还有一点就是面试前一定要提早准备下你们最近的数据数据基本很难造假用数据说服别人是一件比较容易的事情。
Gradle同步速度优化
起因就是去年初业务同学反馈Gradle同步一次需要20分钟实在是太慢了影响到他们的开发。我们在做这个技改之前观察了工程半年的MR状况分析之后得出了一个结论85%以上的MR变更的内容都是针对一个模块的。所以如果我们可以提供一个更小更细碎的工作单元给到研发同学让研发更聚焦于业务之内之后通过桥接了整个工程的编译能得到一个编译产物这样就可以形成一个新的工作流。
Gradle同步提速的本质其实就是通过gradle的复合构建加上我们原来的编译提速原理将没有变更的gradle module更换成一个gitsha值相关的aar缓存。因为复合构建的优势每一个gradle工程都是具备通过AS直接打开的能力所以研发同学就可以在这个更小的gradle工程内进行研发工作了。 面试的最后还要以数据对这部分内容进行收尾,这样比较有说服力。 我们原始的大仓同步模式平均一天使用70次平均耗时18分钟。而新的同步模式平均一天使用150次平均耗时3分钟。两者的使用比例大概是1:2由此可证新的同步模式得到了大部分研发同学的肯定。
在我们后续的迭代过程中我们将工程拆分成40个复合构建之后我们发现当我们的复合构建会拆的更细碎之后复合构建工程之间的依赖串联就会变得更复杂所有这里我们通过DAG的模式通过定义了一个yaml dsl文件对于复合构建之间进行了依赖描述比如说业务依赖了commoncommon依赖了frameworkframework依赖了api还有三方库。
编译速度优化
因为我们做了非常多的编译数据的建设所以我们有一个完整的数据指标来支持整个工程的构建速度优化的。编译我们会拆分成两个大的阶段configuration以及task执行阶段。
对于前面的configuration阶段我们会先遍历一遍工程的文件树还有获取模块gitsha相关的操作我们发现这部分的耗时在1分30秒左右的时间然后我们通过了多线程并发的方式将获取gitsha的动作放在子线程中执行之后进行await的操作另外就是我们在文件遍历操作中进行了大量的无效剪枝的操作从而把这部分的性能提升到30s的时间而对于工程的二次编译的情况我们采取了讲这部分数据结构json化之后通过反序列化的形式完成优化到了6s的时间。
另外就是task阶段我之前的那篇编译优化其实也有说明对于一些编译过程中的检查性质task可以采取关闭策略这样也能做到编译提速。另外一些就是常规理论了什么源码转化二进制啊settings的exclude移除模块之类的。
最后因为编译大盘的缘故所以对于后续我们的整体规划就是提供一个模块级别的编译数据支撑然后将大模块的编译耗时拆分成更细碎的子模块。
单仓多App 这应该算是我工作十年以来最满意的作品了我觉得我还是帮公司做到了一点点的降本增效工作的。 一家公司只要维护的app多了就会有这样的一个问题就是工程组件的复用共享。之前我打工过的公司都是采取的是提供aar模块中异化的代码通过条件编译来处理然后提供这样的组件输出给别的app使用。
我们之前设计的一个通过yaml来描述的复合构建能力通过appkey基于上述描述的yaml dsl然后把构建所需的最小单元描述出来。这样就能使不同的app采用不同的复合构建之后编译出他们的apk。
工程的迭代的过程也是逐步演进的一个节奏去年初的时候先是用一个新孵化的app进行试点工作探索中发现了原始的模式的兼容性问题有且仅对主app模块负责我们对这个模式进行了优化。将我们的monorepo转化成了一种pipeline检查阶段不区分appkey而apk打包阶段筛选出最小构建单元的模式。
在这些基建工作完成之后我们后续对于直播姬还有必剪工程进行了一次大刀阔斧的改造包括但不局限于条件编译基础库版本不一致编译打包问题flavor相关不同的代码片段等等的改造工作最后把他们的工作流和整个大仓完全的进行了统一。
这么做的好处其实不言而喻所有工程的工具链都统一了所有基础库的升级都变成一致的了还有就是所有代码的仓库的迭代节奏也是完全一致的。所有apk都是主干研发的模型也是得到了相对应的兼容。
工作流
首先我们把pipeline保障拆开三部分第一部分是mr的准入前检查第二部分是合入阶段的检查最后的是每日任务。
准入前检查应该算是最多的一部分比如说模块的lint模块的unittest代码cherry-pick到master进行打包还有方法签名校验资源文件压缩率二进制缓存生成等等。
第二部分现在相对内容比较少负责的内容是生成一个lock commit还有一个就是我们的changelog周知的能力。
每日检查我们会定义一些代码质量相关的会在一些闲时的时候进行一些耗时任务比如每日全量的代码质量每日全量的unittest分层编译所有的模块资源snoarquebe上传等等。
做这些的目的主要就是让ci侧更加健壮很多事情都还是ci侧要先行一步的毕竟所有代码的合并流程都是从这边开始的。
工具链支持
这部分应该算是投资回报率ROI最低的工作内容了我们需要把工程内所有基础sdk还有agpkgp等等编译工具链都完成一次统一的迭代升级操作。更多的是升级带来的风险所以我们因此开发了一套changelog周知的能力把这部分变更合入到mastr之后主动的告知给所有的研发同学。
你们怎么做合规
为了保障工程的长治久安我们是通过lint去做整个工程的后续增量检查由于我们在mr合入阶段设置了lint的增量卡口所以就能防止后续新增代码调用这些敏感的api相关了。
然后就是方便测试的调试工具我们通过art hook的形式把这部分可调试能力对测试同学进行了支持如果在这个阶段调用了敏感的api就会直接崩溃并把堆栈进行输出。
最后自然就是asm的兜底把所有敏感的api通过字节码框架进行统一的替换守住整个app的下限。
因为合规相关的诉求又和启动链路息息相关所以我们也通过DAG的形式梳理了整个启动链路并对其进行了task化改造。
然后因此我们公司内部还在推动所有基础sdk的二次迭代让他们具备自动编排启动的能力。
sdk设计
不是我自夸其实这部分设计能力我真的遥遥领先。以下内容纯粹个人看法接下来开始我的表演。
首先是针对于接口编程那一套让业务之间的交互都是基于接口而把实现类内聚与当前的模块中这样就能做到里式替换原则。
另外一点很重要的就是依赖最小化使用方会喷sdk的依赖太重导致整个包体积激增所以依赖是要好好控制的除非是一定是要使用否则能不依赖的库就不依赖能写成抽象接口的就写成抽象接口。
入口参数最小化最好不要直接使用基础的数据类型而建议通过构造器模式然后构造一个对象传入sdk的入口函数中方便后续拓展。否则频繁的增加入口参数会让业务唾弃你的sdk。
以支付作为一个栗子将支付渠道打散之后我们可以通过反射或者类查找器的机制获取到代码中的实现类然后将整个sdk组装起来。
更便捷的接入方式如果是一个平台方就需要考虑业务的接入成本因为你真的需要用质疑的眼光来看待你的接入方他真的可能会给你折腾出很多奇奇怪怪的幺蛾子的。
kmp 跨端一直都是面试中的一个比较常见的问题,如果面试官有兴趣你可以用类似这样的课题主动去吸引他。 我在阿逼完成了工程的kmp的安卓端编译支持工作让iOS和安卓工程可以共享一个kmp的工程进行打包从而实现业务的跨端共享。
另外我们内部使用了大量的proto协议为了支持kmp,我们新写了一个proto-kt的生成的插件让工程能使用纯原生的kt代码从而更简单的支持双端网络协议请求。
最后我们也把kmp完全应用到线上相比较于其他的跨端框架kmp的优势在于可以写一些重逻辑的双端统一逻辑比如说类似折扣结算啊什么的这种如果双端不一致就会出问题的业务。但是如果要拿来写一些ui相关的话当前kmp的支持能力还是比较糟糕的。
面试技巧
面试虽然大部分情况下很讲运气但是也还是有非常多的技巧的。
你需要掌握主动权大部分时候自我介绍的环节就是你开始引导面试官的第一步。不要简单的介绍完时间地点人物就结束了。你要勾起面试官的注意力把你想讲给面试官听的内容先说出来这样后面他的提问环节问你擅长问题的概率就会变大。
其次就是如果碰到了自己不太熟悉的问题你要做的是先不要紧张你要先去询问面试官的想法比如说他想问你一个埋点库的设计但是其实你并没有做过这部分的内容但是我之前是写过支付对应的sdk的所以我先会尝试和面试官询问他想要了解的埋点库的内容是什么然后开始引导他说其实这部分监控能力其实同样也存在在支付sdk中。然后把他拉到我擅长的领域这样就可以一定程度的掌控面试的节奏了。
面试的时长基本都是固定的聊项目的时间越多八股文还有算法题的比重自然也就越少。
三面挂
之前和网友聊天有人说不知道为啥老是会三面挂掉三面面试官问了我一个技术深度的问题我不知道咋回答
我其实以前在面试的时候碰到这题我会和面试官聊一些什么特别小的技术细节。这两年经过了一次晋升答辩之后其实我貌似想通了这件事情面试官想要的根本不是你的技术细节是啥毕竟术业有专攻短短的几分钟怎么能聊清楚呢。
三面面试官一般来说他的职级是比较高的对他而言他根本就不关心你的技术细节是什么。他其实关心的是你做事的方法就是你碰到了一个问题之后你是如何定位如何解决这个问题然后为了防止后续继续出现这个问题你的技术手段是啥这个技术手段有没有可能被沿用到别的技术问题上去。
如果解决了一个技术问题你只解决了其中的异常而没有考虑到如何做一些后续的治理工作虽然你可能用的技术很酷但是我建议你换个内容。
最好的面试内容就是给面试官画适当的饼描绘出一幅蓝图愿景。这样我觉得通过三面的概率会大大增加对方会觉得你是一个有长期规划的人。
最后瞎扯两句
最后点题下行情真的非常差的尤其是对大龄开发来说如果不是必要情况下真的不建议大家裸辞找工作的。
面试的过程中建议大家都还是提早准备下模拟下面试环境什么的珍惜每一次的面试机会毕竟用一次少一次的。招人的公司就这么几家如果错过了可能就是错过了(废话文学)。
最后知识梳理了一下前面面试中问的一些技术问题整理了一些的电子书和面试笔记等学习文档进行参考学习这些笔记将各个知识点进行了完美的总结(包含了很多内容Android 基础、Java 基础、Android 源码相关分析、常见的一些原理性问题等等)。
Android 知识点汇总https://qr18.cn/CyxarU面试题笔记https://qr18.cn/CgxrRy
