2

假设有一个包含 50 个 Swift 模块的 Xcode 项目。一个模块是由7 个文件组成的VIPER模块：

  • 视图控制器
  • 主持人
  • 交互者
  • 网络管理器
  • 路由器
  • 实体

有多个50*7 = 350文件要编译，我真的想将它们分成 50 个框架，每个模块一个，以提高解耦和重新编译速度。

请记住，我不想为所有 , 等创建单个模块Entities，Routers而是一个模块包含实例化和使用该“视图”所需的所有文件（通常为 7 个文件）。

在应用程序中拥有如此多的框架有什么缺点吗？

它可以增长到 70、80、90 甚至 100 个框架。

干杯

4

2 回答 2

1

在应用程序中拥有如此多的框架有什么缺点吗？

是的。使用大量动态框架可以增加应用的启动时间。

此外，从个人经验来看，在一个包含大量类或模块的项目中工作，这些类或模块几乎都做同样的事情，但并不完全相同。您往往会得到很多在过去某个时间点被复制和粘贴的代码，并且弄清楚差异是必要的还是只是随着时间的推移出现小差异的结果是非常痛苦的。尽你所能保持基类中的所有常见行为。例如，我不知道您的 NetworkManager 对象做什么，但我很难相信您需要 50 种不同的实现该想法。

于 2021-04-21T15:10:09.627 回答
1
  • https://github.com/mapbox/mapbox-gl-native/issues/10137带来了潜在的不利因素。在 Apple 的审核过程中，似乎太多的框架可能会导致 Apple AppStore 应用程序中的符号文件过多。
  • 正如https://medium.com/joshtastic-blog/frameworks-and-libraries-in-swift-2359e4274faa解释的那样，您可以选择一些 VIPER 区域（如果它只处理，则可能是演示者、交互者、实体、路由器应用程序域概念/结构）使它们成为静态库而不是动态链接的 dylib 框架，因为它们将是纯代码的，没有 Apple-OS 识别的资产（xib、字体、图像等）。在允许的情况下（由于缺少资产）使用静态库可以大大减少伴随 dylib 的符号文件的数量。
于 2021-04-21T14:42:16.270 回答