我在一些项目中使用了CocoaPods。使用我的依赖项/开源框架来保持更新很酷且很容易。
但我对CocoaPods的内部运作有些怀疑。
在我们的Podfile中，我们只给出了pod的名称，有时也是版本，比如
pod "AFNetworking" , "1.3.2"
然后它正确地找到并克隆AFNetworking回购。这是怎么回事？红宝石如何知道实际的存储库是在Github中。 pod只与Github一起使用吗？ （因为我只看到了Github上可用的框架的pod）。 如果我们可以使用pod作为Github以外的依赖项（例如来自Bitbuket），我们如何将该pod添加到我们的Podfile中？
答案 0 :(得分：10)
CocoaPods在幕后做了很多工作，让你所谈论的一切都在工作。在相对较高的层面上，实际的“Pods”在一个存在于Github上的仓库中进行管理here。这是第三方图书馆供应商提交他们的“Pods”以使用CocoaPods的地方。您会注意到，如果使用带有pod search AFNetworking的命令行工具搜索Pod，您将看到与搜索词匹配的所有可用Pod。
就Github与其他网站而言，尽管CocoaPods规范的存储库仍然存在于Github上，但CocoaPods本身只使用普通的旧Git来从给定的存储库中提取源代码。因此，您可以从任何网站上托管的任何git仓库制作规格。我们也支持svn，mercurial和普通的旧http（s）。如果您对规范的整体工作方式感兴趣，可以查看specs repo中的某些内容，您可以在本地计算机上从~/.cocoapods/repos/master打开它们，也可以直接使用命令pod spec edit AFNetworking编辑一个线。
答案 1 :(得分：0)
CocoaPods是集中式依赖性管理。 Podfile对其进行操作以读取依赖项和版本。 Pod项目将在工作空间中创建。 CocoaPods实现了Implicitly dependency [About]方法：
Source code Closed code [Example] 在客户端，您有一个Podfile。 Podfile的核心是一个pod：
当Podfile读取pod install（在pod update或Cocoapods期间）时，将创建隐式和显式依赖关系图。之后，管理员应将每个源放入.podspec中，该源通常托管在某个主机中。这就是Cocoapods被集中的原因。框架的开发人员负责创建此文件并提供支持。 .podspec描述了有关框架的元信息，例如依赖项，子规范等。它的主要部分是source，它告诉Cocoapods托管源的位置，并将下载此源。到Pod项目中。 Cocoapods使用工作区来自动化构建过程并管理隐式依赖关系。 Cocoapods将所有必要的信息设置到您的消费者项目中（例如Search Pats等）。当构建客户项目Xcode时，请拉动Pod并将其组装在一起。