从事sdk接入，支付模块设计，打包系统设计已经将近2年了，接的大大小小的SDK已经有数十个了，支付，广告，社交...... 中间碰到了太多太多的坑了，从最基础的代码管理，到哪家的SDK有什么特点，都算是略有心得吧。网上很少有这一类的文章，有时候发现一个坑，完全搜不到线索，只能自己慢慢调，十分痛苦。于是，起意把自己的心得都写出来，供大家参考，可能有写的不对或不好的地方，希望大家能给我留言指出来，一起学习，共同进步！
1.技术
SDK接入对技术的要求杂而不深，似乎什么都要懂一点（许多bug千奇百怪，如果没有足够广的知识面，很难发现root cause， 比如有一次接oppo的SDK，商务发现她手机上弹不出悬浮球。而最后的结果是，她用的是米3，小米设置里面默认是禁止悬浮球弹出的）
具体而言，知识点方面，以我们公司开发的一款游戏为例， cocos2d-x/c++ ，这款游戏是以cocos2dx框架开发的，所以要想接sdk，对cocos2dx必需有一定的了解； jni接口，与java部分的sdk进行交互； android/java ，接入主要写的就是java代码； shell/Python脚本, 一般是用脚本去修改配置，以方便批量打包，和反复打包； git , 在代码管理中会用到，最好是尽可能把sdk的接入代码独立于整个工程，避免依赖，这样才能方便代码管理。
2.方法
代码管理， 打包方法， 接入方法，这3套方法的设计应该是SDK接入中最重要的事了。谈一下其基本的方法。
代码管理：目前最好的是git，把sdk以及其接入代码作为一个独立代码仓库，并在包含游戏主工程的git中将其配置为submodule。而不是直接跟游戏的逻辑代码等写在一个代码仓库里。 这样做的好处很多，一是不用依赖游戏的逻辑代码，在实际编码中，我们很多情况是明知道不能依赖，但是写着写着代码就分不开了。二是版本发布时相当灵活，游戏功能和sdk的接入之间完全解耦，比如要发一个旧版本的包含一个刚刚接入的sdk的apk包。三是其他游戏工程也能使用了，只要同样将sdk的代码仓库配置成其submodule。另外，建议使用gerrit进行代码review
打包方法：脚本解决，这里并不从技术上分析打包脚本，只是讲一下如何更好的利用打包脚本（本文并不涉及具体技术，只是讲方法）。可以使用jenkins开一个打包的job，并配上一些打包参数，这样可以实现由测试甚至运营／商务来打包，来减少开发的工作量，让开发把精力放在游戏逻辑上。
接入方法：这个是最重要的。一定要有一个接入框架。特别像一些新游戏，开发不是很重视这个，等到接入渠道到了3个以上时，就会知道没有接入框架的痛苦了。 所谓接入框架，就是封装一些通用接口，这样不同游戏可以很方便使用，不同sdk也很方便的去实现这些接口。这些接口在最开始就要定下来
3.经验（各种坑）
接入过程中的坑，各个SDK的坑（不过因为版本更迭，这些坑可能会有变化）等等，已略去sdk的名字和版本。
- 服务器限制，比如某sdk，其接入的服务端都必须部署在其指定的xx云上
- eclipse工程的AndroidManifest.xml中不能有中文，否则crash
- 其商户后台有个debug开关，不打开的话，调试一直报错，而且错误信息很奇怪
- 只有当keystore文件的签名和配置在其商户后台的签名一致时，才能调试，如果使用eclipse的默认debug.keystore文件就会报错
- 游戏服务端接收验证第三方sdk服务端的通知时，要考虑其突然增加字段的处理。碰到过这样的sdk，结果损失了几天的收入，直到玩家反映才知道
- 回调地址在他们后台配了，第2天才生效
- 多了一个消费过程，买了东西后，如果不调用消费接口就买不了第2个了
- 这个sdk后台有各种接口开放申请，没申请支付接口开放，调试支付时就悲剧了，死活找不到问题
- 运营商的，有些省份的sim卡被限制了，支付时直接报错，换其他省的就好了。
- sdk初始化后就自动返回登录信息，我们游戏逻辑用的是cpp，结果jni还没有初始化，登录回调就过来了，直接crash
- 透传字段的长度／字符有限制，最少的一个直接限制到11位，透传一般用来传游戏自己的订单号有32位，好几次踩进去了。
- 一个sdk压缩文件里有好几个版本的sdk，联网/单机，有/无账户系统，有无集成第三方支付等等，sdk和文档千万不要看错了。
- 某运营商在通知游戏服务端支付成功时，必须要服务端应答客户端的ip地址等信息，简直麻烦透顶
- googleplay，配好商品后，要等上1到2天，将商品信息同步到全球所有服务器后才能获取到，调试时获取不到商品千万别奇怪。
- 各运营商渠道包和派生包，sdk一样，但是接入要求不一样，所以仍然要把它们当作两个sdk，这样免得每次都要改代码
- 游戏服务端主动访问第三方sdk服务端的时候，一定要注意超时处理，有次别人就没回，结果直接卡在那里了，还有一次是进程死了。
- 客户端尽量使用android推荐的库，不然一旦android sdk升级那就有风险了，很可能你用的库就被废弃了，升到5.0时，就被httpclient坑过。
- 配置数据尽量放在服务端，特别是一些第三方sdk提供的链接什么的，被坑过一两次，它们一要停止服务，就必须强制更新客户端，还有就是一些就是涉及到支付到商户信息数据也不要放到客户端，这些商户id之类的泄漏也没什么，主要是因为如果你想卖掉这个游戏时，就会发现，你的商户id写死在客户端，怎么卖？
4.是否使用第三方接入框架
第三方sdk接入框架现在很多了，接入了这些框架，对于接入sdk的效率／打包等都有很大提升，对于一些个人开发者或者刚刚上路的游戏公司来说，特别方便，不过也有一些不足之处：
- 可靠性问题，基本上就是，第三方服务器是整个游戏过程中不可缺少的一环，由于木桶效应，安全/可靠 等都可能会有影响，以及如果出现了安全问题，谁来负责？
- 法律问题，重要参数泄露（倒不是说它们有意获取这些参数），只是说如果一些重要参数在传输过程中泄漏了或者出现了比较严重的安全问题导致刷号等等，谁来负责？
- 一些大R玩家大信息会被收集，因为登录和支付后的回调是会先到它们的服务器解析后，才会发给游戏服务器。这样一些优质用户的信息就会被收集。
- 更新问题，有些审核比较严厉的渠道，对sdk的更新要求十分变态，必须更新到最新sdk版本才让过，如果这个时候，第三方没来得及更新，结果就只能自己去接了。
所以像这些第三方框架最好可以在一些不太重要的渠道使用，或者是在游戏开发的初期使用。如果游戏用户到了千万级，建议还是开发者自己去接sdk。
