likes
comments
collection
share

[Flutter][性能优化]篇八：模块解耦、依赖优化

作者站长头像
站长
· 阅读数 7

什么是模块解耦？

模块解耦是指将软件系统分割成独立的、相互关联但功能上相对独立的模块。每个模块负责特定的功能或业务逻辑，模块之间通过定义清晰的接口进行通信和交互。

模块解耦的目的是降低模块之间的依赖关系，减少耦合度，使得每个模块可以独立开发、测试和维护。

如何将一个大模块拆分成独立的小模块。

举一个简单的例子，以微信为例子，它有四个tabbar选项：微信、通讯录、发现、我，每个tabbar对应的模块就是一个小模块。

微信：负责im通讯，聊天管理等聊天功能。

通讯录：负责添加好友、管理联系人等功能。

发现：负责提供朋友圈、视频号等入口。

我：负责个人资料的设置以及微信相关通用设置。

将大模块拆分为以上小模块，每个小模块都具有特定的功能和职责。

这种模块化的设计可以使得每个小模块独立开发、测试和维护，降低了模块之间的依赖关系，提高了系统的可维护性和灵活性。

同时，通过定义清晰的接口，这些小模块可以方便地进行通信和交互，共同完成整个发布功能的需求。

错误案例

模块之间进行通信和交互

// 定义一个回调函数类型
typedef void ImageUploadCallback(String imageUrl);

class ImageUploadModule {
  // 回调函数作为参数传递给其他模块
  void uploadImage(ImageUploadCallback callback) {

    String imageUrl = 'https://example.com/image.jpg';

    callback(imageUrl);
  }
}

class PublishModule {
  void publish() {
   // 这里为了复用图片上传功能，把整个ImageUploadModule 都引入过来了，耦合严重。
    ImageUploadModule imageUploadModule = ImageUploadModule();
    

    imageUploadModule.uploadImage((imageUrl) {
      // 在回调函数中获取上传后的图片地址，并进行后续处理
      // ...
    });
  }
}

事件总线解耦

// 定义图片上传事件
class ImageUploadEvent {
  // 定义事件属性
  final String imagePath; 
  final int imageQuality;        
  ImageUploadEvent(this.imagePath, this.imageQuality);
}

// 定义 ImageUploadModule 类，负责处理图片上传逻辑
class ImageUploadModule {
  void handleImageUpload(ImageUploadEvent event) {
    // 处理图片上传逻辑
    // ...
  }
}

// 定义事件总线类
class EventBus {
  static final EventBus _instance = EventBus._internal();
  
  factory EventBus() {
    return _instance;
  }
  
  EventBus._internal();
  
  final Map<Type, List<Function>> _eventHandlers = {};
  
  void publish<T>(T event) {
    if (_eventHandlers.containsKey(T)) {
      _eventHandlers[T]?.forEach((handler) => handler(event));
    }
  }
  
  void subscribe<T>(Function handler) {
    if (!_eventHandlers.containsKey(T)) {
      _eventHandlers[T] = [];
    }
    _eventHandlers[T]?.add(handler);
  }
}

// 定义 PublishModule 类
class PublishModule {
  void publishImageUploadEvent() {
    // 创建图片上传事件实例
    ImageUploadEvent event = ImageUploadEvent();
    
    // 发布图片上传事件
    EventBus().publish(event);
  }
}

// 在主函数中使用
void main() {
  PublishModule publishModule = PublishModule();
  
  // 创建 ImageUploadModule 实例
  ImageUploadModule imageUploadModule = ImageUploadModule();
  
  // 订阅（监听）图片上传事件
  EventBus().subscribe<ImageUploadEvent>(imageUploadModule.handleImageUpload);
  
  publishModule.publishImageUploadEvent();
}

事件总线解耦缺点

使用事件总线（Event Bus）的方案也是一种解耦模块之间的常见方式。但是，它也存在一些潜在的问题需要注意。

  1. 难以追踪和调试：由于事件总线是基于事件的异步通信机制，模块之间的交互通过发布和订阅事件来实现。这样会导致代码的执行流程变得不太明确，特别是当多个模块之间存在复杂的事件交互时，很难追踪和调试代码。

  2. 隐式依赖关系：使用事件总线时，模块之间的依赖关系不再显式地体现在代码中，而是通过事件的发布和订阅来实现。这样会增加代码的复杂性，因为开发人员需要在不同的模块中查找和理解事件的发布和订阅关系，难以准确地确定模块之间的依赖关系。

  3. 运行时错误：由于事件总线是在运行时进行事件的分发和处理，所以在编译期间无法捕获事件相关的错误。这可能导致一些潜在的问题在运行时才被发现，增加了调试和排查错误的难度。

  4. 性能影响：使用事件总线可能会对性能产生一定的影响，特别是在事件频繁发布和处理的场景下。事件总线需要进行事件的分发和调用相应的事件处理函数，这会增加一定的开销。在性能敏感的应用中，需要谨慎评估事件总线的性能影响。

综上所述，虽然事件总线是一种常见的解耦模块之间通信的方式，但也存在一些问题需要注意。在使用事件总线时，需要权衡其带来的便利性和对代码可读性、调试性和性能的影响，并根据具体的应用场景进行选择。

依赖注入解耦

对应插件 getIt

可以将 ImageUploadModule 注册为一个服务，然后在需要使用它的地方通过依赖注入的方式获取该服务的实例。这样，PublishModule 就不需要直接依赖于 ImageUploadModule，而是通过依赖注入来获取它的实例。

// 定义 ImageUploader 接口
abstract class ImageUploader {
  void uploadImage(Function(String) callback);
}

// 定义 ImageUploadModule 类，实现 ImageUploader 接口
class ImageUploadModule implements ImageUploader {
  @override
  void uploadImage(Function(String) callback) {
    // 实现图片上传功能，并在上传完成后调用回调函数
    // ...
    String imageUrl = "https://example.com/image.jpg";
    callback(imageUrl);
  }
}

// 定义 ServiceLocator 类，用于注册和获取服务
class ServiceLocator {
  static final Map<Type, dynamic> _services = {};

  static void register<T>(T service) {
    _services[T] = service;
  }

  static T get<T>() {
    return _services[T];
  }
}

// 注册 ImageUploader 服务
ServiceLocator.register(ImageUploadModule());

// 定义 PublishModule 类
class PublishModule {
  void publish() {
    // 通过依赖注入获取 ImageUploader 服务的实例
    ImageUploader imageUploader = ServiceLocator.get<ImageUploader>();
    
    // 调用图片上传模块，并传递一个回调函数
    imageUploader.uploadImage((imageUrl) {
      // 在回调函数中获取上传后的图片地址，并进行后续处理
      // ...
    });
  }
}

// 使用 PublishModule 类
void main() {
  PublishModule publishModule = PublishModule();
  publishModule.publish();
}

在代码中，ServiceLocator.get<ImageUploader>() 是通过服务定位器模式（Service Locator Pattern）来获取 ImageUploader 服务的实例。

服务定位器模式是一种用于管理和提供各种服务实例的设计模式。它的核心思想是将服务的实例化和获取过程封装到一个中心化的服务定位器中，客户端通过服务定位器来获取需要的服务实例，而不需要直接依赖具体的服务提供者。

具体到您的代码中，ServiceLocator 类是一个服务定位器，它负责管理各种服务的实例。通过调用 ServiceLocator.get<ImageUploader>() 方法，您可以从服务定位器中获取 ImageUploader 服务的实例。

在 ServiceLocator 类内部，可能会有一些注册逻辑，用于将具体的服务实例与其对应的类型关联起来。当调用 get 方法时，服务定位器根据传入的类型，在注册表中查找对应的实例，并返回给客户端。

这种方式的好处是，客户端不需要关心具体的服务实现细节，只需要通过服务定位器获取所需的服务实例即可。这样可以实现解耦，提高代码的灵活性和可维护性。同时，服务定位器还可以支持服务的生命周期管理、缓存等功能，进一步增强了服务定位器的灵活性和可扩展性。

需要注意的是，服务定位器模式也有一些潜在的问题，比如可能会导致代码的可测试性下降，增加了代码的复杂性等。因此，在使用服务定位器模式时，需要根据具体情况权衡利弊，并结合实际需求进行设计和使用。

什么是依赖关系

依赖关系是指一个对象或模块依赖于其他对象或模块的情况。在软件开发中，依赖关系描述了一个模块、类或函数使用其他模块、类或函数的功能或资源。

依赖关系是软件系统中常见的概念，它反映了模块之间的交互和依赖。通过依赖关系，模块可以共享和重用其他模块的功能，提高代码的可维护性、可扩展性和可测试性。

然而，过多或不合理的依赖关系可能会导致一些问题，这时候就需要进行依赖优化。

为什么需要进行依赖优化？

  1. 解耦和模块独立性：过多的依赖关系会增加模块之间的耦合度，使得系统变得难以理解和修改。通过优化依赖关系，可以减少模块之间的直接依赖，提高模块的独立性，使得系统更加灵活和可维护。
  2. 可测试性：依赖关系会影响单元测试的编写和执行。当一个模块依赖于其他模块时，测试该模块就需要考虑依赖模块的状态和行为。如果依赖关系复杂或不合理，测试变得困难，可能需要创建大量的模拟对象或进行集成测试。通过优化依赖关系，可以减少测试的复杂性，提高测试的可维护性和可执行性。
  3. 性能和资源管理：过多的依赖关系可能导致性能下降和资源浪费。当一个模块依赖于其他模块时，每次调用都需要经过一系列的依赖传递和资源获取。如果依赖关系过于复杂或存在循环依赖，可能会导致性能瓶颈或资源竞争。通过优化依赖关系，可以减少不必要的依赖传递和资源消耗，提高系统的性能和资源利用率。

请举例说明如何通过接口或抽象类来实现依赖倒置原则，降低模块之间的直接依赖。

在进行依赖优化时，你会采用哪些具体的方法或设计模式？请举例说明。

依赖优化的方法

  • 依赖注入（Dependency Injection） ：通过将依赖关系从代码中移除，而是在外部将依赖对象传递给依赖方。这样可以减少直接依赖，并且使得依赖关系更加清晰和可控。

  • 接口和抽象类：通过定义接口或抽象类，将实现细节与依赖方解耦。依赖方只需要依赖于接口或抽象类，而不需要关心具体的实现。

  • 模块化设计：将系统划分为独立的模块，并通过良好的模块接口设计和模块间的明确依赖关系来管理依赖。

总之，依赖关系是软件开发中常见的概念，通过优化依赖关系可以提高代码的可维护性、可测试性和性能。合理的依赖管理是设计和开发高质量软件的重要一环。

依赖注入法

见上文。

接口和抽象类

当使用接口或抽象类来实现依赖倒置原则时，模块之间的直接依赖将被降低。下面是一个示例，演示了如何在Flutter中使用接口或抽象类来实现依赖倒置：

假设我们有一个简单的计算器应用程序，其中包含一个Calculator类和一个用于执行具体计算操作的Addition类。首先，我们可以定义一个抽象类Operation，它表示了一个计算操作的接口：

abstract class Operation {
  double calculate(double num1, double num2);
}

然后，我们的Addition类将实现这个抽象类，并提供具体的加法计算逻辑：

class Addition implements Operation {
  @override
  double calculate(double num1, double num2) {
    return num1 + num2;
  }
}

现在，我们的Calculator类将不再直接依赖于Addition类，而是依赖于Operation接口。这样，我们可以通过传递不同的实现类来切换不同的计算操作：

class Calculator {
  final Operation operation;

  Calculator(this.operation);

  double performCalculation(double num1, double num2) {
    return operation.calculate(num1, num2);
  }
}

在上面的代码中，Calculator类通过构造函数接收一个实现Operation接口的对象，并使用它来执行计算操作。这样，我们可以轻松地切换不同的计算操作，而不需要直接修改Calculator类的代码。

例如，我们可以创建一个Subtraction类来执行减法计算：

class Subtraction implements Operation {
  @override
  double calculate(double num1, double num2) {
    return num1 - num2;
  }
}

然后，在使用Calculator类时，我们可以选择传递Addition或Subtraction对象：

void main() {
  var addition = Addition();
  var subtraction = Subtraction();

  var calculator = Calculator(addition);
  print(calculator.performCalculation(5, 3)); // 输出：8

  calculator = Calculator(subtraction);
  print(calculator.performCalculation(5, 3)); // 输出：2
}

通过使用抽象类Operation作为依赖关系的接口，我们实现了依赖倒置原则。Calculator类不再直接依赖于具体的实现类（如Addition），而是依赖于抽象的接口。这样，我们可以更灵活地切换不同的实现类，以满足不同的需求，同时保持Calculator类的代码稳定和可扩展性。

总结起来，通过使用接口或抽象类，我们可以降低模块之间的直接依赖，实现依赖倒置原则，并提高代码的可维护性和可扩展性。

模块化设计

见上文。

转载自:https://juejin.cn/post/7294623176222244902
评论
请登录