iOS 游戏渠道SDK 抽象工程封装(下)

上一篇讲到，我们将渠道SDK的代码，和我们自己的业务代码分离，一个放在SDKContainer里面，一个放在SDKAccount里面。

这样做的好处，不止在于可以清晰地划分代码之间的界限，更重要的是，这样更加便于管理和维护。

试想一下，我们做抽象工程的目的是什么？是为了游戏可以不用频繁重复地接入渠道SDK嘛。那么怎么才能达到这个目的呢？

抽象工程的目录结构

我们将代码划分成两个部分：

• 第一部分是不用变动的部分，也就是说所有的渠道SDK，都来共用这部分的代码，是一些基础类。我们统一将他们放在文件夹Base里面。这个Base里面，包含了我们所有自己的业务代码：比如SDKAccount，网络请求类，工具类等等。

• 第二部分是需要变动的部分，也就是说所有的渠道SDK都有各自自己的一份。我们统一将他们放在Replace文件夹下。这里面包含了SDKContainer和渠道SDK的一些配置信息。

先给出一张目录截图：

ThirdLib用来存放渠道SDK的依赖库文件。

为什么我们要把目录的职责分得这么细呢？这是为了更好地在开发中起到一个分工明确地作用。

如何使用抽象工程

1.在实际开发过程中，我们先创建一个空的抽象工程。这时候SDKContainer中是还没有没有渠道SDK代码的。

2.这时研发的同学，来把我们的抽象工程拿过去，然后在游戏代码中调用我们的SDKAccount里面的接口。抽象工程算是接好了。但是现在还不能用，不是吗？你得到了我的驱壳，却没得到我的灵魂。。。不过这时研发的同学，可以把SDK的事情放下了，专心地去做研发。

3.负责专门接入SDK的同学，从商务手中拿到渠道SDK。然后他把抽象工程拷贝一份过来。拷贝完之后，把渠道SDK的依赖库，放到ThirdLib里面。然后在SDKContainer中，填入渠道SDK的代码。接着在SDKConfig中，填入渠道SDK的配置信息。最后测试一下，看有没有问题。没有问题再把它交给研发的同学。

4.研发的同学，拿到接好的渠道SDK的抽象工程，只需要动动手指头，把里面的Replace和ThirdLib文件夹拷贝到原来游戏工程中，将原来的两个文件夹替换一下，OK，接入完成。

5.以后再有新的渠道SDK，只需要重复步骤3和步骤4，就可以了。这个过程中，研发的同学，只需要接入一次抽象工程，接下来的事情，就是动动手指头，替换一下文件。接SDK的同学，也不用关心业务逻辑，只需要将SDK的代码，填入相应的位置就行。两个人都感觉工作量瞬间减小了很多，嘿嘿。。

项目管理

有些朋友发现，说了这么多，只不过是替换文件夹一下而已，为什么要分为Base和Replace？我把所有文件统统放在一个文件夹里面不行啊，到时候我把这个文件夹替换一下就好了啊。

先来看看渠道的管理目录

从这张图可以发现，我们把Base单独提出来了。我们知道，Xcode是可以使用引用的方式，引用一个文件夹里面的内容的，而不必一定要拷贝文件到工程里面去。也就是说，渠道和Base之间，是一个多对一的关系，每个渠道共用一个Base。

为什么要这样做？假设有一天，你的老大叫你修改或者添加一些自家的业务逻辑。哈哈，幸好，我把Base单独拿出来了。这样我只要修改一份代码就可以了~

后记

尽管抽象工程还有很多事情要做，例如网络请求，用户信息记录，数据采集等等，但是这些都是属于业务逻辑的范畴了，这边也不一一介绍了。希望抽象工程，对大家有帮助，让接入渠道SDK不再痛苦。。