模块作为 Xcode 项目中的独立框架

Question

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

• 视图控制器
• 演讲者
• 交互者
• 网络管理器
• 路由器
• 实体

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

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

在应用中拥有如此多的框架有什么不好的地方吗？

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

干杯

Answer 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 的符号文件的数量。

Answer 2

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

可以。使用大量动态框架可以increase your app's launch time。

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