深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上鸿蒙开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
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
文件,对于复合构建之间进行了依赖描述,比如说业务依赖了common,common依赖了framework,framework依赖了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还有agp,kgp等等编译工具链都完成一次统一的迭代升级操作。更多的是升级带来的风险,所以我们因此开发了一套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代码,从而更简单的支持双端网络协议请求。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
ps://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!