目前,CocoaPods正在以iOS为目标的Pod中导入UIKit

CocoaPods无需介绍。 这个流行的依赖性管理器与Carthage以及Swift Package Manager共享舞台。 这篇简短的文章将探讨它对我们导入到项目中的Pod的一种影响。

实际上,看来CocoaPods当前在我们在iOS上使用的每个Pod上都添加了一个UIKit导入。

我们可以举RxSwift Pod为例。 UIKit没有导入到该项目中,它完全独立于此UI框架。 Krunoslav Zaher在评论中证实了这一点。 好吧,我记得我发现一个ViewModels中使用的UIKit类时在MVVM应用程序上工作这很糟糕。 该项目确实进行了编译,但是在此特定文件中没有导入UIKit 。 我们很快就发现,由于RxSwift的导入,它是可以自行编译UIKit的,因此可以进行编译。 还似乎是由于使用CocoaPods导入了框架而发生了此行为,但没有通过Carthage或通过直接构建导入该框架。

从技术上讲,此导入似乎是通过CocoaPods端头文件的生成和使用来完成的。 当Pod以iOS或tvOS平台为目标时,会生成此标头,其中包含谈论导入。

它有什么害处? 老实说,除了最纯粹的主义者以外,它并没有做什么用。 如果我们保留上面的示例,我们都可以看到在ViewModel中执行此UIKit导入并不是最佳方法,因为它引入了与UI的依赖关系。 我们不会显式地完成它,但是会隐式地完成它。

在这里,我们可以开始讨论这种行为,即依赖项管理器干扰其依赖项。 可以吗 如果是,在什么范围内? 如果不是,为什么呢? 更进一步,由于这种添加不会改变其源代码,是否可以将其视为对源材料的干扰?

CocoaPods开发人员已经知道此行为。 真正有趣的是它对系统的重要性。 确实,让我们退后一步。 如果所有实时项目都重新安装了其Pod,而没有自动添加此导入怎么办? 实际上有多少个类确实需要UIKit ? 全世界同时有多少次编译失败? 狗和猫在一起生活,歇斯底里。 规格可能会大量损坏的这种观点有助于我们了解改进的难易程度,以及为什么它仍是热门话题。

遵循这个CocoaPods的故事将是非常有趣的:开发人员将如何继续改变它,如果这样做的话,将会带来什么后果等等……

CocoaPods是一个很棒的工具,由一个很棒的社区构建和维护。 他们极力激发人们的贡献,这使他们变得更加出色!

Interesting Posts