CN116774988A - 解除框架包模式符号依赖的方法及装置 - Google Patents

Abstract

本发明提出了解除框架包模式符号依赖的方法及装置，所述方法包括：新建纯净的Project工程，在Project工程的Build Settings中，找到Mach‑O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；使用Xcode打开Project工程，通过Build进行编译，获取不同Swift版本编译出的多个Framework包，将多个Framework包上传至Pod库，替代对应的Swift源码库实体。所述装置使用了所述方法。本发明减轻工作量的同时解决了依赖传递带来的冲突。

Description

解除框架包模式符号依赖的方法及装置

技术领域

本发明涉及软件开发技术领域，具体涉及一种解除框架包模式符号依赖的方法及装置。

背景技术

在iOS平台上，由于苹果公司主力推荐引导，Swift的代码市场份额越大庞大，众多第三方库均是由Swift编写。而第三方库，在iOS开发中，往往通过CocoaPod进行依赖引用。对于Swift编写的第三方库，若有正常引入、编译或使用，首要要求在Podfile声明文件中增加use_frameworks!框架包模式符号，换而言之，Swift的第三方库对于use_frameworks!符号声明是必需的。

但use_frameworks!符号是一个极度不友好的符号。从上世纪80年代已通用至今的Objective-C语言，当前已在市场上占有率较高，因此Objective-C编写的第三方库同样占有率高。use_frameworks!对于Objective-C语言编译好的.a库，会引起依赖传递的问题，而导致工程产生编译冲突。

当前行业内对于以上问题，推荐的方案，往往是更换.a库，找到其他同类的库进行替代。本质上，并未解决use_frameworks!符号会导致存在.a库的工程，在编译时产生冲突的问题。同时找寻同类替代库是一件费时费力的工作，且不一定有合适的替代库。

发明内容

针对现有技术的不足，本发明提出一种解除框架包模式符号依赖的方法，包括：

A、获取基于Swift语言编写的第三方提供的目标源码；

B、使用Xcode新建Project工程，将所述目标源码载入所述Project工程；

C、在Project工程的Build Settings中，找到Mach-O Type选中为DynamicLibrary，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；

D、使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

E、重复执行步骤D，获取不同Swift版本编译出的Framework包；

F、将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。

在其中一个实施例中，上述所述步骤B之前，还包括：

G、根据Swift和Xcode版本的对应关系进行梳理，提炼Swift的关键版本；

所述步骤D，具体为：

D1、使用Swift的关键版本对应的第一Xcode版本打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体。

在其中一个实施例中，上述所述步骤D1之后，还包括：

H、对Framework包进行多级检测，确定Framework包的可靠性；

所述步骤F，具体为：

F1、将可靠的Framework包，使用podspec定义、声明和发布，并上传至Cocoapod平台进行管理。

在其中一个实施例中，上述所述步骤H，包括：

H1、根据各个版本的Xcode中通用的调用逻辑，编辑通用测试代码；

H2、根据第一Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断一级检测通过；

H3、根据第二Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断二级检测通过，所述第二Xcode版本和第一Xcode版本对应同一Swift的关键版本。

在其中一个实施例中，上述所述步骤H3之后，还包括：

I、若检测未通过，使用第二Xcode版本打开Project工程，通过第二Xcode版本的Build进行编译，获得与第二Xcode版本对应的四个架构的Framework包。

在其中一个实施例中，上述所述步骤F1之后，还包括：

J、当检测Xcode版本和Swift版本同时更新时，使用更新后的Xcode版本和Swift版本至少重新执行步骤G、D1、H和F1。

本发明还提供了一种解除框架包模式符号依赖的装置，包括：

第一获取模块，用于获取基于Swift语言编写的第三方提供的目标源码；

载入模块，用于使用Xcode新建Project工程，将所述目标源码载入所述Project工程；

设置模块，用于在Project工程的Build Settings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；

第二获取模块，用于使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

第三获取模块，用于获取不同Swift版本编译出的Framework包；

替换模块，用于将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。

在其中一个实施例中，上述装置还包括第一确定模块和第二确定模块；

第一确定模块，用于根据Swift和Xcode版本的对应关系进行梳理，提炼Swift的关键版本；

所述第二获取模块，具体用于：

使用Swift的关键版本对应的第一Xcode版本打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

第二确定模块，用于对Framework包进行多级检测，确定Framework包的可靠性；

所述替换模块，具体用于：

将可靠的Framework包，使用podspec定义、声明和发布，并上传至Cocoapod平台进行管理；

所述第二确定模块，具体用于：

根据各个版本的Xcode中通用的调用逻辑，编辑通用测试代码；

根据第一Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断一级检测通过；

根据第二Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断二级检测通过，所述第二Xcode版本和第一Xcode版本对应同一Swift的关键版本。

本发明还提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述所述的解除框架包模式符号依赖的方法。

本发明还提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述所述的解除框架包模式符号依赖的方法。

本发明实施例通过预先获取基于Swift语言编写的第三方提供的目标源码；使用Xcode新建Project工程，将所述目标源码载入所述Project工程；在Project工程的BuildSettings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；并获取不同Swift版本编译出的Framework包；将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。因为本发明实施例不再需要编Swift库，不再需添加use_frameworks!符号声明，工作量减轻。同时，也不需要在Podinstall之前，在Xcode的Build Settings中配置SWIFT_VERSION，工作量进一步减轻。另外Objective-C语言编译好的.a库，在use_frameworks!符号声明下，会引起依赖传递的问题，而本发明实施例可以彻底解决上述依赖传递的问题。开发人员无需另外找寻替代库，并重新替换。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明第一实施例的解除框架包模式符号依赖的方法的流程图；

图2为本发明第二实施例的解除框架包模式符号依赖的方法的流程图；

图3为本发明第二实施例的S207的详细流程图；

图4为本发明第三实施例的解除框架包模式符号依赖的装置的结构框图；

图5为本发明的又一实施方式的计算机内部构造示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例，众所周知的模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。并且，所描述的特征、架构或功能可在一个或一个以上实施方式中以任何方式组合。本领域技术人员应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。还可以容易理解，本文所述和附图所示的各实施方式中的模块或单元或处理方式可以按各种不同配置进行组合和设计。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

第一实施例：请参照图1所示，本发明实施例公开了一种解除框架包模式符号依赖的方法，主要应用于解除Swift源码库对use_frameworks!符号的强依赖，包括：

S11，获取基于Swift语言编写的第三方提供的目标源码。

在本实施例中，为便于后续在不同版本的编译器中切换，需要新建干净无污染的Project工程，作为新建Project工程的前置步骤，需要获取Swift语言编写的第三方提供的源码作为目标源码。

Swift语言为苹果于2014年WWDC（苹果开发者大会）发布的新开发语言，可与Objective-C*共同运行于Mac OS和iOS平台，用于搭建基于苹果平台的应用程序。

S12，使用Xcode新建Project工程，将所述目标源码载入所述Project工程。

本步骤S12通过新建干净无污染的Project工程，便于后续在不同版本的编译器中切换，为编译作准备。一方面保留了第三方库的完整性和纯净性，另一方面可以避免部分无关代码，无关代码在后续步骤中可使不同Xcode版本下无法编译，而影响可行性。作为一种具体方案而非限定，本步骤中可以将目标源码通过直接拖入Project工程的方式完成载入操作。

S13，在Project工程的Build Settings中，找到Mach-O Type选中为DynamicLibrary，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386。

本步骤S13用于配置必要的编译信息，在本实施例中，通过配置为动态库，以及arm64、armv7、x86_64和i386四个架构，使得可以满足大部分用户在各类场景中正常使用。

S14，使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体。

Xcode 是运行在操作系统Mac OS上的集成开发工具（IDE），由Apple Inc开发。可以理解的是，本步骤的四个架构对应上述S13中的arm64、armv7、x86_64和i386四个架构。本步骤用于将目标源码转变为可直接被使用的Framework产物，本实施例通过提前搭建环境，帮用户进行编译，使用户能规避异常，提前帮用户承担风险。

S15，重复执行步骤S14，获取不同Swift版本编译出的Framework包。

S14的步骤需要被重复多次，原因是用户的Swift开发环境不一致，则需要不同的Swift语言编译出的Framework包，以面向全体用户，提升兼容性，加强可行性。

S16，将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。

本步骤通过将多个Framework包上传至Pod库，并替代对应的Swift源码库实体，通过上述方式Swift库不再依赖use_frameworks!符号。

本发明实施例通过预先获取基于Swift语言编写的第三方提供的目标源码；使用Xcode新建Project工程，将所述目标源码载入所述Project工程；在Project工程的BuildSettings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；并获取不同Swift版本编译出的Framework包；将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。因为本发明实施例不再需要编Swift库，不再需添加use_frameworks!符号声明，工作量减轻。同时，也不需要在Podinstall之前，在Xcode的Build Settings中配置SWIFT_VERSION，工作量进一步减轻。另外Objective-C语言编译好的.a库，在use_frameworks!符号声明下，会引起依赖传递的问题，而本发明实施例可以彻底解决上述依赖传递的问题。开发人员无需另外找寻替代库，并重新替换。

第二实施例：请参照图2和图3所示，本发明实施例公开了另一种解除框架包模式符号依赖的方法，主要应用于解除Swift源码库对use_frameworks!符号的强依赖，包括：

S201，获取基于Swift语言编写的第三方提供的目标源码。

本步骤与第一实施例的对应步骤相同，这里不再赘述。

S202，根据Swift和Xcode版本的对应关系进行梳理，提炼Swift的关键版本。

作为相对第一实施例对所有Swift语言编译出的Framework包方案的一种改进，经过长期实践，发现可以采用单一版本的Swift对应多个Xcode版本。基于这样的认知，需要先对Swift和Xcode版本的对应关系进行梳理，提炼可以兼容多个Xcode版本的Swift版本作为关键版本。根据调查，Swift和Xcode版本对应关系为：Swift 4.0.3对应Xcode 9.2，Swift4.1.2对应Xcode 9.4，Swift 4.2对应Xcode 10，Swift 4.2.1对应Xcode 10.1，Swift 5.0对应Xcode 10.2，Swift 5.0.1对应Xcode 10.2.1，Swift 5.1对应Xcode 11，Swift 5.1.2对应Xcode 11.2，Swift 5.1.3对应Xcode 11.3。

通过上述Swift和Xcode版本的对应关系，优先确定Swift的大版本为关键版本，示例性的，关键版本可以是Swift 4.0/4.1/4.2/5.0/5.1等等。

S203，使用Xcode新建Project工程，将所述目标源码载入所述Project工程。

S204，在Project工程的Build Settings中，找到Mach-O Type选中为DynamicLibrary，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386。

S203-S204与第一实施例的对应步骤相同，这里不再赘述。

S205，使用Swift的关键版本对应的第一Xcode版本打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体。

本步骤与第一实施例的S14对应，不同的是，提取关键版本的Swift通常对应多个Xcode版本，本实施例以第一Xcode版本/第二Xcode版本进行区分，同一关键版本的Swift只需要采用第一Xcode版本/第二Xcode版本之一即可获得对应多个Xcode版本的四个架构的Framework包，节省了人力物力，提升了效率。

S206，重复执行步骤S205，获取不同Swift版本编译出的Framework包。

本步骤通过对所有的Swift的关键版本编译出的Framework包，使得可以面向全体用户，提升兼容性，加强可行性。

S207，对Framework包进行多级检测，确定Framework包的可靠性。

为了保证每个Framework包均是可用的、正常的、并且兼容对应的多个Xcode版本。本实施例的步骤S207需要对Framework包进行自检，自检的方式可以是多级检测。作为一种具体方案而非限定，请参照图3所示，本步骤S207，包括步骤S2071-S2073，其中：

S2071，根据各个版本的Xcode中通用的调用逻辑，编辑通用测试代码。

S2072，根据第一Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断一级检测通过。

S2073，根据第二Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断二级检测通过，所述第二Xcode版本和第一Xcode版本对应同一Swift的关键版本。

作为一种解释而非限定，上述步骤S2071-S2073以Swift 4.2为例，其对应的第一Xcode版本为Xcode 10.1，第二Xcode版本为Xcode 10.2，假定Framework包是在Xcode 10.1下编译的，此时在多级检测中，不仅需要检测Framework包是否支持 Xcode 10.1环境下的Swift版本，还需要检测Framework包是否支持 Xcode 10.2环境下的Swift版本。

若在检测过程中，程序发生崩溃或测试代码不能正常打印出 Swift代码中定义的类对象，则执行步骤S208。

S208，若检测未通过，使用第二Xcode版本打开Project工程，通过第二Xcode版本的Build进行编译，获得与第二Xcode版本对应的四个架构的Framework包。

上述步骤S202-S208可有效保证编译出的Framework包的可靠性，在提高效率的前提下尽可能实现Framework包的通用性，保证一个Framework包能支持多个Swift环境。

S209，将可靠的Framework包，使用podspec定义、声明和发布，并上传至Cocoapod平台进行管理。

Cocoapod为用于帮助iOS开发人员管理第三方依赖库的工具，使用subspec来进行子组件的声明的关键代码如下：

s.subspec 'ForSwift5.0' do |ss|

ss.vendored_frameworks = 'PolyvSocket/ForSwift5.0/*.framework'

end

s.subspec 'ForSwift4.1.2' do |ss|

ss.vendored_frameworks = 'PolyvSocket/ForSwift4.1.2/*.framework'

end

s.subspec 'ForSwift4.0.3' do |ss|

ss.vendored_frameworks = 'PolyvSocket/ForSwift4.0.3/*.framework'

end

s.default_subspec = 'ForSwift5.0'

其中，默认使用 Swift 5.0编译出的Framework包，即选用“ForSwift5.0”，用户的代码为 pod 'PLVSocket/ForSwift5.0’, '~>0.1.0’，示例性的，当用户是Swift 4.1.2时，可选用 “ForSwift4.1.2”，用户的代码为pod 'PLVSocket/ForSwift4.1.2’, '~>0.1.0’。

S210，当检测Xcode版本和Swift版本同时更新时，使用更新后的Xcode版本和Swift版本重新执行步骤S202-S209。

由于本实施例提炼了Swift的关键版本，并基于Swift的关键版本编译出兼容多个Xcode版本的Framework包，当Swift版本更新而Xcode版本未更新时，可以不用理会苹果公司的该次更新，本实施例提供便捷的依赖方案给用户，使得用户只需要关注自己是什么Swift版本，就可以快速依赖到对应Framework包，减轻了用户的使用负担。

本实施例一方面通过提炼Swift的关键版本实现了通过一个Xcode版本生成适应多个Swift的关键版本的Framework包，节省了人力物力，提升了效率，另外，通过提出一种多级检测的自检方式，可以有效验证兼容性强的Framework包，并筛选出不兼容的第二Xcode版本，而后在根据第二Xcode版本编译获得对应的可靠的Framework包，实现在Framework包数量最小化的前提下支持多个Swift环境，最后，由于本实施例的Framework包具有高兼容性，减轻了用户诸如更新和依赖时的使用负担，提升了用户的使用体验。

第三实施例：请参照图4所示，本发明还提供了一种解除框架包模式符号依赖的装置100，包括第一获取模块110、载入模块120、设置模块130、第二获取模块140、第三获取模块150和替换模块160，其中：

第一获取模块110，与载入模块120连接，用于获取基于Swift语言编写的第三方提供的目标源码；

载入模块120，与设置模块130连接，用于使用Xcode新建Project工程，将所述目标源码载入所述Project工程；

设置模块130，与第二获取模块140连接，用于在Project工程的Build Settings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；

第二获取模块140，与第三获取模块150连接，用于使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

第三获取模块150，与替换模块160连接，用于获取不同Swift版本编译出的Framework包；

替换模块160，用于用于将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。

作为一种优选方案而非限定，本实施例的解除框架包模式符号依赖的装置100还包括第一确定模块和第二确定模块，其中：

第一确定模块，用于根据Swift和Xcode版本的对应关系进行梳理，提炼Swift的关键版本；

所述第二获取模块140，具体用于：

使用Swift的关键版本对应的第一Xcode版本打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

第二确定模块，用于对Framework包进行多级检测，确定Framework包的可靠性；

所述替换模块160，具体用于：

将可靠的Framework包，使用podspec定义、声明和发布，并上传至Cocoapod平台进行管理；

所述第二确定模块180，具体用于：

根据各个版本的Xcode中通用的调用逻辑，编辑通用测试代码；

根据第一Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断一级检测通过；

根据第二Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断二级检测通过，所述第二Xcode版本和第一Xcode版本对应同一Swift的关键版本。

本实施例的模块与上述方法实施例的对应步骤相同，这里不再赘述。

本发明实施例通过预先获取基于Swift语言编写的第三方提供的目标源码；使用Xcode新建Project工程，将所述目标源码载入所述Project工程；在Project工程的BuildSettings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；并获取不同Swift版本编译出的Framework包；将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。因为本发明实施例不再需要编Swift库，不再需添加use_frameworks!符号声明，工作量减轻。同时，也不需要在Podinstall之前，在Xcode的Build Settings中配置SWIFT_VERSION，工作量进一步减轻。另外Objective-C语言编译好的.a库，在use_frameworks!符号声明下，会引起依赖传递的问题，而本发明实施例可以彻底解决上述依赖传递的问题。开发人员无需另外找寻替代库，并重新替换。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本发明实施例还提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述各实施例中的解除框架包模式符号依赖的方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各解除框架包模式符号依赖的方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、终端、或者网络设备等）执行本发明各个实施例方法的全部或部分。而前述的存储介质包括：移动存储设备、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

与上述的计算机存储介质对应的是，在一个实施例中还提供一种计算机设备，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行程序时实现如上述各实施例中的解除框架包模式符号依赖的方法。

该计算机设备可以是终端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种解除框架包模式符号依赖的方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本发明实施例通过预先获取基于Swift语言编写的第三方提供的目标源码；使用Xcode新建Project工程，将所述目标源码载入所述Project工程；在Project工程的BuildSettings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；并获取不同Swift版本编译出的Framework包；将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。因为本发明实施例不再需要编Swift库，不再需添加use_frameworks!符号声明，工作量减轻。同时，也不需要在Podinstall之前，在Xcode的Build Settings中配置SWIFT_VERSION，工作量进一步减轻。另外Objective-C语言编译好的.a库，在use_frameworks!符号声明下，会引起依赖传递的问题，而本发明实施例可以彻底解决上述依赖传递的问题。开发人员无需另外找寻替代库，并重新替换。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (10)

1.解除框架包模式符号依赖的方法，其特征在于，包括：

A、获取基于Swift语言编写的第三方提供的目标源码；

B、使用Xcode新建Project工程，将所述目标源码载入所述Project工程；

C、在Project工程的Build Settings中，找到Mach-O Type选中为Dynamic Library，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；

D、使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

E、重复执行步骤D，获取不同Swift版本编译出的Framework包；

F、将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。

2.如权利要求1所述的方法，其特征在于，所述步骤B之前，还包括：

G、根据Swift和Xcode版本的对应关系进行梳理，提炼Swift的关键版本；

所述步骤D，具体为：

D1、使用Swift的关键版本对应的第一Xcode版本打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体。

3.如权利要求2所述的方法，其特征在于，所述步骤D1之后，还包括：

H、对Framework包进行多级检测，确定Framework包的可靠性；

所述步骤F，具体为：

F1、将可靠的Framework包，使用podspec定义、声明和发布，并上传至Cocoapod平台进行管理。

4.如权利要求3所述的方法，其特征在于，所述步骤H，包括：

H1、根据各个版本的Xcode中通用的调用逻辑，编辑通用测试代码；

H2、根据第一Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断一级检测通过；

H3、根据第二Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断二级检测通过，所述第二Xcode版本和第一Xcode版本对应同一Swift的关键版本。

5.如权利要求4所述的方法，其特征在于，所述步骤H3之后，还包括：

I、若检测未通过，使用第二Xcode版本打开Project工程，通过第二Xcode版本的Build进行编译，获得与第二Xcode版本对应的四个架构的Framework包。

6.如权利要求5所述的方法，其特征在于，所述步骤F1之后，还包括：

J、当检测Xcode版本和Swift版本同时更新时，使用更新后的Xcode版本和Swift版本至少重新执行步骤G、D1、H和F1。

7.解除框架包模式符号依赖的装置，其特征在于，包括：

第一获取模块，用于获取基于Swift语言编写的第三方提供的目标源码；

载入模块，用于使用Xcode新建Project工程，将所述目标源码载入所述Project工程；

设置模块，用于在Project工程的Build Settings中，找到Mach-O Type选中为DynamicLibrary，设置Setting值为VALID_ARCHS，Value值为arm64、armv7、x86_64和i386；

第二获取模块，用于使用对应的Xcode打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

第三获取模块，用于获取不同Swift版本编译出的Framework包；

替换模块，用于将所述Framework包上传至Pod库，作为第三方Pod库的实体，替代对应的Swift源码库实体。

8.如权利要求7所述的装置，其特征在于，还包括第一确定模块和第二确定模块；

第一确定模块，用于根据Swift和Xcode版本的对应关系进行梳理，提炼Swift的关键版本；

所述第二获取模块，具体用于：

使用Swift的关键版本对应的第一Xcode版本打开Project工程，通过Xcode的Build进行编译，获得四个架构的Framework包，Framework包内部包含可直接被链接器加载的动态库实体；

第二确定模块，用于对Framework包进行多级检测，确定Framework包的可靠性；

所述替换模块，具体用于：

将可靠的Framework包，使用podspec定义、声明和发布，并上传至Cocoapod平台进行管理；

所述第二确定模块，具体用于：

根据各个版本的Xcode中通用的调用逻辑，编辑通用测试代码；

根据第一Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断一级检测通过；

根据第二Xcode版本新建Project工程，载入已编译好的Framework包，根据通用测试代码使用真机运行程序，当程序正常运行且通用测试代码能正常打印出Swift代码中定义的类对象，判断二级检测通过，所述第二Xcode版本和第一Xcode版本对应同一Swift的关键版本。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任意一项所述的解除框架包模式符号依赖的方法。

10.一种计算机存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至6任意一项所述的解除框架包模式符号依赖的方法。