2024年Android最新爱奇艺组件化技术探索与项目实践，2024年最新15个经典面试问题回答思路汇总

本文链接：https://blog.csdn.net/2301_82243828/article/details/138863246

新的开始

改变人生，没有什么捷径可言，这条路需要自己亲自去走一走，只有深入思考，不断反思总结，保持学习的热情，一步一步构建自己完整的知识体系，才是最终的制胜之道，也是程序员应该承担的使命。

《系列学习视频》

《系列学习文档》

《我的大厂面试之旅》

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

组件化对于任何一个业务场景复杂的APP以及经过多次迭代之后的产品来说都是必经之路，组件化是指解耦复杂系统时将多个功能模块拆分、重组的过程。组件化要做的不仅仅是表面上看到的模块拆分解耦，其背后还有很多工作来支撑组件化的进行，例如结合业务特性的模块拆分策略、模块间的交互方式和构建系统等等。

本文主要讲述爱奇艺知识APP如何结合自身的业务特点，探索和实践了一套高效的移动端组件化方案。

一、背景与目标

===================================================================

1.1背景

爱奇艺知识目前有多个业务承载端，包括爱奇艺移动端APP的知识插件、爱奇艺iPad端APP的知识插件、随刻移动端APP的知识插件和爱奇艺知识移动端独立APP。由于各个端上线的时间不同，所承载的业务功能也不完全一致，造成了多端多套代码的情况，维护成本很高。首先当相同或类似的功能需要迭代升级时，开发和测试都需要在多端同步进行，成本成指数级增长；其次随着业务的快速发展，业务模块在不断增加，模块间的依赖关系也变得越来越模糊，代码耦合度和复杂度都在增大；另外在现有人力成本的基础上如果想增加更多的业务端，就会变得非常困难。因此长期看非常不利于业务的高效迭代。下图描述了组件化之前，爱奇艺知识各端的业务模块架构。

从上图我们也能看出其实每个端之间是存在很多公共业务模块的，各个业务模块的底层支撑模块也几乎相同，所以结合爱奇艺知识自身的业务特点，我们提出了适合于爱奇艺知识移动端的组件化方案。

1.2目标

我们将组件化的目标定义为以下几个：

· 解决多端代码维护问题

根据业务特点，横向和纵向划分组件，以组件为单位承接迭代需求，各端进行组件复用；

· 解决跨组件调用和组件间路由的问题

业务划分更加清晰、组件间解耦更加彻底、组件间通信更高效，对原有业务模块进行抽离和整合，明确组件间的业务边界；

· 提升开发效率，方便开发调试

组件可以单独编译和调试，使模块开发者更聚焦本模块业务；

· 提升集成和提测效率

各端项目需要哪个组件，可以直接通过工具快速集成和提测。

基于以上目标，我们设计了适合爱奇艺知识业务的组件划分策略，下图为组件化之后的功能架构图，横向分为基础组件、功能组件和业务组件，纵向对每个层级的组件又进行细分；从划分粒度上看，组件不仅包括功能性的sdk，还可能包括业务UI，宗旨就是业务模块独立，边界清晰，方便扩展和维护。

二、整体技术架构

====================================================================

基于功能架构，知识组件化的技术架构如下图所示。

最下层是基础组件，包括baselib和componentService，我们将网络库、pingback、数据库、日志和工具类等公共底层实现构成基础组件，屏蔽了系统和各端的差异，位于功能和业务组件的下层。所有功能和业务组件都使用同一套基础组件，可以保证公共部分的统一性。基础组件比较稳定，不会频繁迭代。

再往上一层是功能组件，如承载播放能力的播放器和历史记录组件、承载支付能力的支付和营销组件，、承载多端定制化分享能力的分享&海报组件等各个端都有的基础功能，功能组件位于基础组件和业务组件之间，功能组件会根据业务组件的需要而不断迭代升级。

接下来是业务组件，这层是各个端有可能包含也有可能不包含核心业务模块，为了开发和维护方便，我们将核心业务模块抽取为业务组件，如搜索、筛选、发现feed流、评论、评价、作业作品等，业务组件位于基础组件和功能组件的上层，迭代较频繁，但业务本身比较独立，边界清晰。

最上层是壳工程，各端都需要一个主工程负责集成所需要的组件，我们统称为壳工程，壳工程包括了各端的基础框架，比如组件注册和初始化逻辑，平台相关性处理逻辑等，还有各端特有的业务模块，不适合抽离和拆解的部分。

右侧是负责管理组件间交互和跳转的MoudleRouter和UIRouter。这部分是公共基础设施，各端都要集成。

左侧是构建系统，它不在组件化代码中，属于辅助系统，负责组件和各端应用包的构建。

三、核心技术实现

====================================================================

组件化实践中比较核心的两个技术点是，组件间交互和组件间路由。

3.1组件交互

组件间交互的难点是降低组件耦合度，最好能达到完全无侵入式的调用。经过调研，iOS端使用ModuleManager的方式，它被定义为最底层的服务组件，每个组件都需要对外提供被调用的服务接口，接口的定义存在于ModuleManager组件。ModuleManager的代码对其他组件代码来说是无侵入的，只负责对传递过来的数据进行解析，并将调用消息传递给对应组件。

为了解决URL硬编码，以及字典参数类型不明确等问题，iOS端在组件化方案中选用了Protocol方案，在程序开始运行时将自身的Class注册到ModuleManager中，并将Protocol反射为字符串当做key，Class遵守协议并实现协议定义的方法，外界通过Protocol获取的Class并实例化为对象，调用服务方实现的协议方法。独立APP和各个插件的服务注册的时机不同，独立APP是在程序启动时，而插件则是外部调用插件时，在插件退出时去需要解除注册释放资源。Protocol方案描述如下：

在Android端，组件间交互使用的是ZRouter组件，实现思路和iOS端类似，是参考了java中SPI机制（服务提供发现机制），每个组件对外提供一个服务接口service,接口的实现交给对应组件内。在组件初始化注册时候，会同时注册该service接口和对应service实现。业务方使用时，只需要通过service接口调用组件功能。这样组件间就没有了直接依赖关系，实现了组件间解耦隔离。具体调用如下图所示：

3.2组件路由

组件间路由跳转方面，iOS端采用了注册URL的方式，注册的时机分为静态、动态和懒加载三种，懒加载方式即为在调用跳转方法时检查URL与ClassName是否已经注册绑定，如果未绑定则从模块静态信息表中获取并完成注册绑定，Handler可以在动态注册时进行指定，这样跳转逻辑即可实现完全自定义而不走底层的统一跳转逻辑，同样要注意的是插件端需要在退出插件时释放资源并取消注册。

Android端针对组件间UI跳转的实现方面，虽然前面讲到的ZRouter也能做到Activity、Fragment、View之间跳转，但是代码实现过于复杂。所以我们借鉴了业内组件化的优秀思想，专门开发了一个用于组件间UI跳转的UIRouter。在编译期间，通过Activity上添加的@RouterPath注解，生成一张Key为Scheme或页面短码，Value为Activity的路由表。跳转任何一个Activity都交由路由框架，根据路由表决定启动哪个Activity。

为了提升开发效率，减少UIRouter初始化时重复开发的代码，我们开发了一个插入自动注册代码的gradle插件，利用此插件在编译期通过ASM向指定方法中注入初始化代码。

同时，在组件库注册的时候也有用到这个技术；组件初始化类在debug模式下通过反射加入内存，在release模式下则通过ASM插入注册代码。这样在debug模式下可以缩短编译时间提升开发效率，在release正式包中运行时可减少反射带来的消耗。

整个优化流程如下：

最后

针对Android程序员，我这边给大家整理了一些资料，包括不限于高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter等全方面的Android进阶实践技术；希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！