美文网首页
第三方SDK 动态配置解决方案

第三方SDK 动态配置解决方案

作者: hylccmh | 来源:发表于2020-03-11 10:16 被阅读0次
    一、说明

    从2019年3月份接手游戏SDK任务以来,我们完善了 登录模块、支付模块、事件 统计模块、分享模块 等功能 ,随着游戏发布的区域变化,游戏方也提出了很多个性 化的需求,比如就拿登录来说,美国地区的用户常用的第三方登录方式是: facebook、Twitter ,而日本地区的用户常用的第三方登录方式是:Twitter 、Line 。刚开始为了快速满足游戏的需求,我们把 所有的登录方式都集成了一遍,但 是对于有些游戏是不需要那么多登录方式的,为了优化 SDK 和减少包体积,我们做 了一个动态的配置,举例子:如果不需要 line 登录,游戏方就不需要添加LineSDK 。问题来了:我们给游戏的包中是集成 LineSDK 相关代码的,如果游戏方 不添加 LineSDK ,代码就会报错。以下我们会给出几种解决方案。

    二、预编译方案

    这是我们刚开始给出的第一种方案,就是在原来的 SDK 进行低成本的改造,首先 通过预编译的方式 根据 第三方SDK的头文件是否存在来判断是否需要执行相关代 码,代码如下:

    #define lineSDKModule __has_include(<LineSDK/LineSDKLogin.h>) 
    #if lineSDKModule @import LineSDK; 
    #endif 
    

    这种方式的改造,在 SDK 运行阶段,确实也按照我们期望的方式运行了,不添加 lineSDK 也不会报错,但是当我们把 SDK 编译成 SDK.framework 包给到另一个工程 使用的时候就出现问题了。假如我们在导出SDK.framework 的时候项目中有 lineSDK 包,而另一个添加 SDK 的工程中,没有添加 lineSDK,就会报错,提示找不 到 LineSDK。相信看到这里大部分人都知道问题的所在了, __has_include()是一 个宏定义,在编译阶段都已经确定了是否存在值。也就是在我们导出 SDK.framework 的时候,就确定了 lineSDKModule 的值,所以,它不是在另个工 程中动态的判断是否存在 lineSDK 。所以,这种方案并不能达到我们做动态配置的 需求。

    三、通过 runtime 方式

    这种方式相信大家都会想到,通过苹果的运行时来判断类是否存在,进而调用类
    内部的方法,从而达到我们的目的。部分代码如下:

    1. 获取类
    Class lineSDkLogin = NSClassFromString(@"LineSDKLogin"); 
    
    2.通过 performSelector 执行第三方 SDK 的方法
    if ([self.lineLogin respondsToSelector:@selector(startLoginWithPermissions:)]){ 
    [self.lineLogin performSelector:@selector(startLoginWithPermissions:) withObject:@[@"profile", @"friends", @"groups"]]; 
    } 
    

    通过这种方式确实达到了我们期望的需求,但是有一个问题就是如果第三方 SDK 方 法进行升级的时候,维护就会比较困难,而且代码会比较臃肿,我们在看看还有没 有其他的解决方案。

    四、runtime 方式 + 每个第三方 SDKAdapter

    这种方式就是我们为每个第三方需要动态配置的SDK创建一个Adapter.SDK ,
    在 Adapter.SDK 内部实现 第三方的 SDK 功能 ,比如 Facebook SDK ,我们可以创 建一个 FBAdapter.SDK ,在这个SDK内部实现我们所需要的Facebook相关的功 能,在我们的 SDK.framework 内部 通过 runtime 的方式 判断工程中是否引用了 FBAdapter.SDK ,从而达到 对 Facebook 相关功能模块的操纵。
    优点:我们只需要通过 runtime的 方式判断 第三方Adapter.SDK 是否存在,而 在 Adapter.SDK 内部不需要 runtime 处理第三方 SDK 功能调用,便于后期的 SDK 升级和维护。
    缺点:随着我们要动态配置的 第三方SDK的数量的增加,我们创建多个 Adapter.SDK ,会导致要维护的 Adapter.SDK 比较多 。

    五、Adapter 文件 + 预编译方案

    我们在讨论预编译方案的时候知道,这种方案是行不通的,这次我们做下变通, 我们添加一个 桥接的中间层(我们通过这个中间层调用第三方SDK的相关功能) , 而这个中间层我们 不打成 framework 包给到游戏方,而是以 .h .m的方式给到游戏 方。而在中间层的内部我们通过 预编译的方案处理项目工程中是否添加了 第三方 SDK ,因为我们的中间层没有编译成 framework ,所以判断项目工程中是否存在第 三方 SDK 是在游戏方 在打 IPA 包的时候进行判断的。
    这样就解决了 我们只是使用 预编译方案的不足。
    优点:便于后期第三方SDK的升级维护
    缺点:我们的一部分实现文件会暴露出来

    六、总结

    在接手 SDK 后,遇到了很多问题,也解决了很多问题,以上是我们解决动态配
    置第三方 SDK 时候,提出的几个方案,同时,也欢迎大家讨论更多其他解决方案

    相关文章

      网友评论

          本文标题:第三方SDK 动态配置解决方案

          本文链接:https://www.haomeiwen.com/subject/zhafjhtx.html