QMobile大会Qunar Cocoapods依赖管理的集成和扩展--支付iOS本地工程集成方案分享

Posted 2021-04-30 Qunar技术沙龙

去哪儿技术嘉年华

去哪儿工程师内部学习交流平台。秉承务实、创新的宗旨，致力于促进公司内部各开发团队之间技术业务交流，促进个人以及团队能力提升，营造技术学习文化氛围。

2016年技术嘉年华分三个场次：Qmobile-移动端开发方向、Qdata-数据相关方向、Qarch-业务系统架构方向，分别在8月三个周六进行；我们也邀请了携程、艺龙的小伙伴共同分享交流。

本文根据Qmobile上主题演讲内容编辑整理，方便更多小伙伴一起来交流学习。

 

王昆鹏

毕业于大连理工大学，获得计算机系统结构专业硕士学位。 2015年毕业后加入Qunar，担任金融事业部ios开发工程师，负责支付及用户中心iOS客户端的开发和维护。期间主导并完成了支付模块的重构和架构优化，同时自主设计和开发了本地工程的集成工具，有效的提高了团队的开发效率。

我今天分享的题目是Cocoapods依赖管理的集成和扩展，主要是我们支付iOS团队对本地工程集成方案的一个分享，这种集成方案在实际中有效的提高了团队的开发效率和开发质量。

希望通过这个分享，能把这种思路带给大家，大家可以针对自己团队的实际情况，参考和使用这种方案。

我今天分享的主要内容呢包括这样几个部分，首先概述一下本地工程集成方案，接下来我们针对3个集成部分，分别列举一些日常开发中遇到的问题，并给出我们的解决方案，最后是总结和展望。

1 

概述

首先简单介绍下Cocoapods，Cocoapods是iOS的依赖管理工具，我们只需要配置Podfile文件，执行pod命令，就可以管理所有的依赖信息，在工程中，我们的各项依赖就是不同的业务模块。

我们的集成方案可以分为三个部分，分别是依赖管理集成，测试工程集成和团队管理集成。我们做这些集成的目的，最根本上就是为了提高开发效率和开发质量。

所谓磨刀不误砍柴功，在我们开发中，可能遇到一些很细小的问题，但是久而久之，这些问题逐渐累积，就会暴露出来，整个集成方案就是为了解决这样的问题。

通过分析Cocoapods可以了解其内部的处理流程如下，其实在图中标出的几个节点中，我们都可以做一些Hook，来完成自定义的功能。这样本地工程不再是代码和依赖的集合，还可以添加一些个性化的配置。

这些集成和扩展可以归结为持续集成的一个方面，这里的持续集成，更加强调的是在本地工程上的，不同的开发团队可以针对自己的开发特点，开发风格来集成不同的功能。

2

使用Cocoapods遇到的问题

下面介绍依赖管理的集成，这一部分主要为了解决在使用Cocoapods中遇到的一些问题。

我们一起来看下面几个case，第一个是debug问题，我们开发同学build一个本地工程之后，发现所有的环境都是线上，没有办法去切换，debug开关不见了，或者运行时直接崩溃，isOpenBetaDebug方法找不到……

这些问题呢大家多少都会遇到，问题的原因呢，就是我们依赖的公共组件或者cofigure组件依赖到了一个rtag，也就是线上版本。

下面还有一个类似的问题，业务联调问题。有些业务线在依赖我们收银台联调时，会发现原来期望的流程走不通，支付失败，或者是和自己预期的结果不太一样，于是他们把问题报给我们。

但是在检查代码的时候并没有复现这些问题，最后定位到业务依赖支付模块的版本是一个beta版，这样排查问题的过程消耗开发人员很大的精力。

第三个问题是，当我们开发过程中需要依赖业务的源码时候，通常使用指定git分支的形式，而此时必须要在配置的多个target中同时修改，不需要的时候又要都改回来，这样这个Podfile文件的修改变得很繁琐。

针对这样几个问题呢，我们对cocoapods依赖管理的部分进行了一个优化，集成到了本地工程中。

这里先来解释一下前面两个问题，为什么会导致依赖版本错误。首先，我们业务线模块的版本主要有三种：beta版，rc版，和prod版，当我们使用pod update命令时呢，得到的结果有时候会依赖到prod，有时候会依赖到beta，有时候会依赖到正确的rc，这其实和cocoapods内部的版本比较方式有关。

传统的Podfile中使用波浪线箭头，0.beta的形式来指定依赖的版本，这个符号是一种运算符，它表示大于等于指定的版本，小于下一个主版本，也就是说实际上会在0.0.0和1.0.0这个区间内选择一个最新的版本，所以最终结果就取决于本地仓库中版本的排序。

下面列举了一些典型的版本号进行说明。

Cocoapods中版本比较沿用了Ruby的版本比较方式，其中，版本类型会分为两种：纯数字的版本称为release版本，字母数字混合的称为prerelease版本，所有版本首先去除字母比较前面的release版本，所以0.0.48会排在最前面。

当该版本相同时，如0.0.47和0.0.47rc，则release版本会排在prerelease版本前面，两个prerelease版本比较，就完全按照字母的顺序进行排列了，所以rc会排在beta前面，最终确定的顺序就是这样。所以依赖最新的版本时可能依赖到beta，可能依赖到prod，可能依赖到rc。

针对这些问题，我们的解决方案就是通过外置脚本，默认依赖各模块的rc版本，同时将配置依赖方式分离，同时对应修改Podfile即可，修改后的Podfile如下。

3

如何简化支付模块的测试流程

这一部分讲解的是测试工程的集成，主要针对如何简化我们支付模块的一个测试流程的问题。

由于我们收银台比较特殊，在其它页面没有直接的入口，我们只能够从首页，进入业务的搜索页，再进到列表页，详情页，最后提交订单进入收银台。

这个过程比较冗长，影响我们开发同学的自测效率。

同时呢，我们通过业务线下单，也需要依赖业务线的环境，beta环境很不稳定，通常我们联系一个环境，耗费的时间和精力也比较多。

如果我们使用线上的环境，又涉及到退款的问题，这些问题呢，都会影响我们的自测效率。

另外，在开发新功能时，前后端同时有开发量，客户端的逻辑只能等后端ready才能进行验证。

所以，我们集成了测试工程，来解决这些问题，提高我们的自测效率。

我们通过本地mock数据，来直接调起收银台，简化了测试流程，最终效果如下图页面，不同的入口代表，使用不同的mock数据测试不同的功能，而这些测试的数据和代码才存放在一个私有的仓库中，整个测试工程作为一个依赖，添加到主工程中。

我们使用git管理一个私有仓库，同时将仓库添加到本地，下图可以看到工程的目录结构。

我们的测试工程与主工程无任何依赖，测试代码通过runtime来访问主工程的类，属性和方法。同时，在主工程添加Scheme入口，进行测试工程的切换。

这种集成测试工程是一种本地方案，更加直接，而且纯客户端代码，学习成本很低，团队内部不同同学进行开发时，可以不断扩展这个工程，共同进行维护。

而且，测试的功能还可以做的更加丰富，比如一些单元测试，UI测试，自动化测试等等。

4

团队开发的困扰

最后一部分主要针对在团队开发中遇到的问题，进行的一些扩展集成。

从Xcode7开始，个人免费证书可以真机调试，导致不同开发同学使用不同的开发证书，这样在多人开发过程中，每次pull之后，都需要修改成对应的bundleID和账号，而push的时候又需要解决这些信息的冲突。

第二个问题就是Podfile.lock文件的冲突。这个文件是每次pod命令执行以后，在工程目录下生成的一个文件，内容为本次添加的依赖版本信息，这个文件被放在版本管理中，所以每次提交代码，都要去解决这个文件的一系列冲突。

针对以上问题，我们使用Ruby开发了扩展工具，将证书放在对应目录下管理，使用命令参数来自动安装开发者证书，同时也包括测试工程切换的功能。

最后，我们将Podfile.lock文件移除了版本管理，这主要由于各业务依赖模块的版本都相对稳定，而且更新频率较快，不再需要保持团队使用相同的依赖版本进行开发。

这样一种团队管理的集成方式，让我们避免了很多无谓的工作量，提高了开发的效率。

5

总结和展望

上面我们介绍了，基于Cocoapods的一系列本地工程的集成，主要包括依赖管理的集成，测试工程的集成，团队管理的集成。当然在这些的基础上，还可以扩展更多的功能，比如质量检查集成，常用代码集成等等。

所以，这里希望更多感兴趣的同学能够加入进来，共同参与，使本地工程使用起来更加便捷，功能更加完善。

更多精彩请继续关注【技术嘉年华】

Qmobile主题视频&PPT讲义欢迎登陆【去哪儿大讲堂】观看

 

Qunar技术沙龙

欢迎关注我们