wulong756273的博客

Kotlin扩展函数configure通过带接收者的函数类型实现优雅配置模式。该方法接收一个EventConfig类的扩展函数作为参数，通过apply在新对象上执行配置代码块，使配置过程更直观。相比传统方式，这种设计支持链式调用，将配置逻辑封装在EventConfig作用域内，可直接访问其属性和方法。典型应用场景包括事件处理器配置，通过addValidator和addHandler等函数实现验证逻辑和事件绑定，最终返回配置管理器以支持后续操作。该模式结合建造者模式和扩展函数特性，显著提升代码可读性和维护性。

本文介绍了基于注解的ServiceLibrary系统设计方案，包含核心注解定义、使用示例和处理系统。系统通过@Service、@Route、@Module等注解实现服务、路由和模块的自动注册，配套的处理器完成扫描和注册工作。在Application中统一初始化后，即可通过简洁的方式使用服务。相比传统手动注册方式，注解方案具有代码简洁、维护性好、扩展性强等优势，实现了声明式编程和自动化管理，提升了系统的模块化和可维护性。

kotlin// 传统方式：模块间直接依赖// 直接依赖具体Activity，编译时耦合// 问题：// 1. 模块间编译时耦合// 2. 难以进行单元测试// 3. 多应用构建困难// 4. 团队协作冲突kotlin// 1. 模块解耦// 传统：LoginActivity → UserActivity (编译时依赖)// 现在：LoginActivity → UserService → UserActivity (运行时解耦)// 2. 统一管理。

将“依赖注入+服务定位器+自定义路由”模式封装为通用库，帮助多模块/多应用Android项目实现模块解耦、灵活服务管理和页面跳转统一化。

kotlin// 如果库的页面跳转逻辑相对固定// 库内部处理跳转逻辑结论：不需要路由，在库内部处理即可kotlin// 如果库需要支持使用方自定义页面// 通过路由获取目标页面结论：需要路由，让使用方可以自定义页面。

本文介绍了一个轻量级Android组件化路由方案，采用模块化设计实现各组件独立路由管理。系统核心包括：路由接口(IRouter)、路由实现(Router)、路由拦截器(RouteInterceptor)和回调机制(RouteCallback)，通过反射机制实现Activity跳转。项目结构采用主app模块+公共库(lib_common)+功能模块(mod_home/mod_user/mod_product)的方式，各模块自行注册路由路径。方案优势在于实现简单、性能优异、模块解耦，支持参数传递和拦截器机制，适

本文提出了一种基于服务定位器模式的模块化解耦架构方案。该方案通过接口隔离、服务定位和依赖注入三大机制，有效解决了多应用构建中的模块依赖、服务共享等挑战。核心组件包括全局服务定位器、基础服务接口层和模块化注册机制，实现了编译时解耦和运行时绑定。相比传统DI框架，该方案具有学习成本低、调试简单等优势；相比路由框架，则提供了更完整的业务逻辑处理能力。实践表明，该架构在多应用支持、模块独立开发和渐进式迁移等方面表现优异，特别适合大型模块化项目和多应用构建场景，是平衡简洁性与解耦性的优秀实践。

LiveData → StateFlow：状态管理现代化MutableLiveData → StateFlow：数据流现代化Event Bus → SharedFlow：事件处理现代化。

特性建造者模式装饰器模式类型创建型模式结构型模式目的创建复杂对象动态扩展功能时机对象创建时对象创建后关注点对象构建过程对象功能扩展建造者模式专注于对象创建，提供流畅的API和参数验证装饰器模式专注于功能扩展，提供动态的功能组合能力两者解决不同的问题，可以单独使用或结合使用选择哪种模式取决于具体的使用场景和需求。

装饰器模式是一种动态扩展对象功能的结构型设计模式。它通过包装对象在不修改原结构的前提下添加新功能，保持接口一致性。该模式包含抽象组件、具体组件、抽象装饰器和具体装饰器等核心元素，典型应用场景包括Java IO流处理和GUI组件扩展。相比继承，装饰器模式更加灵活，能避免子类爆炸问题，支持运行时功能组合。其优势在于遵守开闭原则、实现单一职责和透明扩展，但需注意避免过度使用导致的类膨胀和调试困难。该模式特别适用于需要动态添加职责、组合多种功能的场景。

Builder模式是一种创建型设计模式，用于分步构建复杂对象。它通过分离对象构建和表示，提供流畅的API接口，支持链式调用，确保对象创建的一致性和完整性。该模式包含产品类、抽象建造者、具体建造者和指挥者四个核心组件，现代Java更常用链式调用的实现方式。Builder模式的优势包括参数可选性、顺序无关性、不可变性、可读性和类型安全，特别适用于创建具有多个可选参数的复杂对象、需要参数验证的场景以及配置对象的创建。相比Factory模式，Builder更关注复杂对象的逐步构建过程。

摘要：本文介绍了一个完整的Android共享ViewModel实现方案，用于Service与Activity间的数据通信。通过创建共享ViewModel、ViewModelStoreOwner管理器，并在Application中统一管理生命周期，实现了：1) Service向多个Activity发送数据；2) 响应式LiveData通信；3) 手动/自动内存回收机制；4) 防止内存泄漏。方案包含ViewModel创建、数据更新、状态观察、UI绑定等完整实现代码，适用于需要持久化数据状态或服务-UI通信的场景

在编程中，适配器模式使不兼容的接口能够协同工作。

虽然引入会带来一定的构建复杂度和学习成本，但对于需要处理日志、权限、埋点、性能监控等通用逻辑的项目来说，收益是巨大的。这些是散布在应用多个模块中的功能（如日志、权限检查、性能监控、事务管理等），与核心业务逻辑无关，但又是必需的。轻松实现一些难以通过传统 OOP 实现的功能，如无痕埋点、全局性能监控、自动重试等。将分散在各处的通用逻辑（如日志、权限）集中到切面中，避免代码重复和侵入性修改。：程序执行过程中的特定点（例如方法调用、方法执行、构造器调用、字段访问）。学习曲线陡峭，开发复杂，容易出错，调试困难。

摘要：IoC（控制反转）是一种设计原则，强调将控制权交给外部容器以实现解耦；DI（依赖注入）是实现IoC的主要技术手段，具体通过容器将依赖对象注入到需要它们的对象中。IoC关注控制权的转移，而DI则解决依赖关系的提供方式，如构造函数注入或Setter方法注入。简单来说，IoC是目标（解耦），DI是达成该目标的具体方法（注入依赖）。现代框架如Spring通过DI技术实现了IoC原则。

组件只依赖于抽象（接口），不依赖于具体实现。可以轻松地用 Mock 对象或 Stub 对象（实现相同接口）替换真实的依赖进行单元测试。代码更清晰、更模块化。修改一个组件的实现或其依赖项变得更容易，影响范围更小。解耦后的组件更容易被复用在不同的上下文中。容器集中管理对象创建和依赖关系，配置更清晰。鼓励面向接口编程和单一职责原则。依赖注入是一种通过将对象的依赖关系交由外部容器管理和注入来实现解耦的设计模式。

装饰器实现修饰对象（conpoment）的接口，所有请求都转发给它处理。在转发请求之前/之后，增加额外功能。装饰器模式 ： 动态的给一个对象 添加一些额外的职责。就增加功能来说，装饰器模式比生成子类更加灵活。

有人把观察者模式等同于发布订阅模式，也有人认为这两种模式存在差异，本质上就是调度的方法不同。相比较，发布订阅将发布者和观察者之间解耦。（发布订阅有调度中心处理）