私有库的使用场景
场景一、在iOS开发的过程中,我们会因开发需要而使用Cocoapods引入各种三方库，但有时为了更切合项目需求，不得不去修改三方库的源码。一旦pod update升级了三方库，原来修改的代码就冲掉了，这就不得不使用git回滚修改的区块或者再改一遍，这就造成升级困难。尤其是在团队里开发的过程中，如果其它队员不知道你改了三方源码，这一升级直接导致你的修改代码丢失而出现bug。
场景二、有一些成熟的三方库，不支持pods导入，这个比较少见。
场景三、项目里成熟的功能模块可以从项目里剥离，通过pods导入。
对于这几种场景，我们可以通过以下几个方法来解决，下面来详细介绍下：
一、pods导入本地库
1.创建Podfile
touch Podfile 或 vim Podfile（可直接编辑）
填写完成输入 :wq 保存并退出
2.创建MyTestKit文件夹，并创建podspec文件
pod spec create MyTestKit
文件目录结构如下：
3.把需要pods引入的文件放到MyTestKit目录下
4.修改podspec文件
这是最重要的一步，需要了解podspec文件的写法，各种字段的涵义。可删除不必要的注释(更多字段请参考http://guides.cocoapods.org/syntax/podspec.html)
修改后的podspec文件
#
# Be sure to run `pod spec lint MyTestKit.podspec' to ensure this is a
# valid spec and to remove all comments including this before submitting the spec.
#
# To learn more about Podspec attributes see http://docs.cocoapods.org/specification.html
# To see working Podspecs in the CocoaPods repo see https://github.com/CocoaPods/Specs/
#
Pod::Spec.new do |s|
# ――― Spec Metadata ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# These will help people to find your library, and whilst it
# can feel like a chore to fill in it's definitely to your advantage. The
# summary should be tweet-length, and the description more in depth.
#
s.name = "MyTestKit"
s.version = "0.0.1"
s.summary = "MyTestKit demo."
# This description is used to generate tags and improve search results.
# * Think: What does it do? Why did you write it? What is the focus?
# * Try to keep it short, snappy and to the point.
# * Write the description between the DESC delimiters below.
# * Finally, don't worry about the indent, CocoaPods strips it!
s.description = "description"
s.homepage = "https://github.com/zhfeng20108"
# s.screenshots = "www.example.com/screenshots_1.gif", "www.example.com/screenshots_2.gif"
# ――― Spec License ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Licensing your code is important. See http://choosealicense.com for more info.
# CocoaPods will detect a license file if there is a named LICENSE*
# Popular ones are 'MIT', 'BSD' and 'Apache License, Version 2.0'.
#
s.license = "MIT"
# s.license = { :type => "MIT", :file => "FILE_LICENSE" }
# ――― Author Metadata ――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Specify the authors of the library, with email addresses. Email addresses
# of the authors are extracted from the SCM log. E.g. $ git log. CocoaPods also
# accepts just a name if you'd rather not provide an email address.
#
# Specify a social_media_url where others can refer to, for example a twitter
# profile URL.
#
s.author = { "feng.zhang" => "hhzhangfeng2008@163.com" }
# Or just: s.author = "feng.zhang"
# s.authors = { "feng.zhang" => "hhzhangfeng2008@163.com" }
# s.social_media_url = "http://twitter.com/feng.zhang"
# ――― Platform Specifics ――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# If this Pod runs only on iOS or OS X, then specify the platform and
# the deployment target. You can optionally include the target after the platform.
#
# s.platform = :ios
s.platform = :ios, "8.0"
# When using multiple platforms
# s.ios.deployment_target = "5.0"
# s.osx.deployment_target = "10.7"
# s.watchos.deployment_target = "2.0"
# s.tvos.deployment_target = "9.0"
# ――― Source Location ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Specify the location from where the source should be retrieved.
# Supports git, hg, bzr, svn and HTTP.
#
s.source = { :git => "", :tag => "#{s.version}" }
# ――― Source Code ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# CocoaPods is smart about how it includes source code. For source files
# giving a folder will include any swift, h, m, mm, c & cpp files.
# For header files it will include any header in the folder.
# Not including the public_header_files will make all headers public.
#
# s.source_files = "Classes", "Classes/**/*.{h,m}"
# s.exclude_files = "Classes/Exclude"
# s.public_header_files = "Classes/**/*.h"
# ――― Resources ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# A list of resources included with the Pod. These are copied into the
# target bundle with a build phase script. Anything else will be cleaned.
# You can preserve files from being cleaned, please don't preserve
# non-essential files like tests, examples and documentation.
#
# s.resource = "icon.png"
# s.resources = "Resources/*.png"
# s.preserve_paths = "FilesToSave", "MoreFilesToSave"
# ――― Project Linking ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Link your library with frameworks, or libraries. Libraries do not include
# the lib prefix of their name.
#
s.vendored_frameworks = 'HeheTest.framework'
# s.framework = "SomeFramework"
# s.frameworks = "SomeFramework", "AnotherFramework"
s.vendored_libraries = 'libHeheTestStatic.a'
# s.library = "iconv"
# s.libraries = "iconv", "xml2"
# ――― Project Settings ――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# If your library depends on compiler flags you can set them in the xcconfig hash
# where they will only apply to your library. If you depend on other Podspecs
# you can include multiple dependencies to ensure it works.
s.requires_arc = true
# s.xcconfig = { "HEADER_SEARCH_PATHS" => "$(SDKROOT)/usr/include/libxml2" }
# s.dependency "JSONKit", "~> 1.4"
s.subspec "HeaderFiles" do |ss|
ss.public_header_files = "include/**/*.h"
ss.source_files = "include/**/*.h"
ss.requires_arc = true
end
end
5.执行pod install命令
按照提示把podspec文件修改正确，直到pod install执行成功
最后工程结构如下图所示：
二、pods导入网络上的库并解决冲突问题
1.导入GitHub上的三方库
这个是我们用的最多的情况，不再赘述。
2.导入私有仓库里的库
随着项目开发的迭代，工程越来越大，很有必要把一些自定义控件、功能模块从工程里剥离出来，移植给更多的项目使用。要导入库，需要具备两个条件：（1）源码仓库（2）对应的podspec.json文件的仓库
对于源码仓库和podspec.json文件的仓库，可以是github上的，也可以是自己公司的私有仓库。解决多个三方库冲突的方法就是在这里做文章。咱们就先来讲讲如何导入私有库。如下是一个示例：
platform :ios, '8.0'
source 'https://github.com/zhfeng20108/podsecRepo.git'
source 'https://github.com/CocoaPods/Specs.git'
target 'TestDemo' do
pod 'MyTestKit', :path => 'MyTestKit'
pod 'gRPC-Core'
end
可以看出 gRPC-Core 下载的版本是1.3.0, 而GitHub 上的最新版本是1.6.0
从中可以看出，会优先在'https://github.com/zhfeng20108/podsecRepo.git'里查找podspec.json文件。这样我们就可以对gRpc-Core.podspec.json文件做任何更改，上面的例子中，是对依赖做了修改，由BoringSSL改成了OpenSSL。这里的修改是为了避免BoringSSL和OpenSSL同时引入pods造成方法重命名的冲突。
3.冲突解决
（1）上面这个案例只是修改了dependencies字段的值，当然了我们可以根据需要去修改platforms，source，source_files，vendored_frameworks，vendored_libraries等等字段的值来避免与其它三方库的冲突。
（2）碰上源代码方法名重名的情况，这时就需要修改三方的源代码。
方案一：把修改好的源代码存到一个新的仓库里，比如公司的一个仓库里,同时把修改好的podspec文件（这时主要修改的是source字段里的值，git地址指向公司的仓库）存在公司的另一个仓库里。
方案二：fork源代码到自己的github帐号下，然后修改代码，引入时采用 pod 'RSKImageCropper',:git => 'https://github.com/zhfeng20108/RSKImageCropper',即可指向修改后的代码库。复杂的可能就需要在自己帐号下再建一个库存放podspec.json文件，以便精确控制代码。
以上两种方案，无论哪种，都会遇上三方源码升级问题，对于方案一，我们只能把最新代码copy过去，检查下原来修改的代码现在是否需要调整。对于方案二，可通过方法fork后代码和源代码同步来解决。
网友评论