教你快速高效接入SDK——总体思路和架构 - sdk - ITkeyowrd
教你快速高效接入SDK——总体思路和架构
题记：很多做游戏开发的人，估计都或多或少地接过渠道SDK，什么UC，当乐，91，小米，360......据统计国内市场当前不下于100家渠道，还包括一些没有SDK的小渠道。每个渠道SDK接入的方法呢，多是大同小异。但是，正是这些小异，又让SDK的接入，产生了无穷无尽的变数。所以，接入SDK之前，如果你没有经验，或者没有被SDK坑过，那么当你看到这系列文章的时候，你很幸运，你可以避免这一切了。如果你之前被坑过，而且还在继续被坑着，那么现在，就是你解脱的时刻。完成一个SDK的接入并没有多少技术含量，但是能接入100个SDK，而且能做到维护容易，结构清晰，安全可靠，一劳永逸就不是那么容易的事情了。这也是为什么，世面上出现了那么多打包工具的介绍，SDK接入方法的介绍.....而且，还各不相同。随着手游的爆发，做手游的多了，被坑的人多了，那么总会有一些能人异士不甘其苦，开始发动脑筋，去寻求一套既可以服务于自身，也可以服务于他人的统一SDK接入框架。俗话说，有痛苦，就会有需求。所以，SDK接入这个小市场（或者这个市场也很不小）就涌现出了，像棱镜SDK，AnySDK，易接等这样专门做SDK接入的公司或者机构。他们自认为，他们是时代的拯救者。他们的出现，会给广大还在忍受着苦逼SDK接入的童鞋们带来一片光明。然而，事实上呢？这套统一的SDK接入框架本身，就有着和实际情形相矛盾的地方。因为，他们都无一例外地要求，游戏开发商在接入他们那个抽象框架时，服务器端的登陆认证，和支付回调都走他们的服务器。但是，就是这一点，让几乎所有的游戏开发商望而却步。为什么呢？因为，对于游戏开发商来说，还有什么比用户数据和支付数据更重要呢？让这些数据走别人的服务器过一趟，岂不是比让他们的老婆放在别人的家里睡两晚更加难受呢？但是，像棱镜SDK，AnySDK那一套东西，还真的很好。不用呢，又有点心痛的感觉。那么问题来了，能不能自己来实现并维护一套像棱镜SDK，或者AnySDK那样的框架，作为公司自己的统一SDK接入解决方案呢？答案是，当然可以。只不过，自己需要苦逼那么一次，之后就解脱了。因为第一次，每个渠道SDK还是要自己接入的。但是，想到这些东东都是自己的，自己开发，自己维护，一个字：踏实。哦，错了，是两个字。本系列教程，我们就来从头到尾，实现一套类似棱镜SDK，或者AnySDK的那么一套东西。那么，我们先来分析一下，接入一个SDK，我们需要做实现哪些东西。1、首先，客户端需要接入多款SDK，为了能够多款游戏重用，我们不可以在游戏里面直接去接入每个SDK，而是需要将游戏和SDK接入分离。2、上面既然说了SDK接入和游戏分离，那么我们就需要抽象出一个SDK接入框架，游戏只需要接入这个框架即可，然后每个渠道SDK来实现这个框架。3、我们需要实现一个打包工具，不可能100个渠道包，手动一个一个去点击打包，那是会死人的。4、服务器端，同样得，为了支持多款游戏，我们需要一个统一的用户登录认证中心，和一个统一的支付中心。所以，我们这套东西，应该有以下几个部分：1、统一SDK接入框架2、各个SDK接入实现3、一键打包工具4、统一的登陆认证中心和支付中心好，整体的思路有了，我们这好歹也是和棱镜SDK，AnySDK差不多牛逼的玩意，怎么可以没有名字呢？我们姑且叫他 U8 SDK吧。现在，就让我们再来分析下，一般SDK接入都有两大部分。一部分是登陆，一部分是支付。那么我们的u8 sdk自然也一样，我们需要把整个登陆的流程，和整个支付的流程给好好规划一下。我们先看登陆流程，如果不使用这套框架，直接接入SDK，登陆的流程是什么样呢？我们这里可以看下UC SDK他的登陆流程图：1.“游戏客户端”调用“SDK 客户端”的登录功能，“SDK 客户端”引导用户输入 用户名密码，当用户使用“UC 账号”登录时，“SDK 客户端”调用“SDK 服务器” 接口进行身份验证；2.“SDK 服务器”密码验证通过后返回sid 及用户相关信息（包括：ucid、用户昵 称等）；3.“游戏客户端”在“SDK 客户端”回调通知后，可向“SDK 客户端”获取sid；5.“游戏服务器”可向“SDK 服务器”请求验证sid（调用用户会话验证接口，详见《UC 优视游戏SDK 开发参考说明书-服务器接口》）；6.“SDK 服务器”将sid 的验证结果和对应的ucid 返回给“游戏服务器”；7.“游戏服务器”将sid 的验证结果及ucid、用户昵称返回给“游戏客户端”那么，我们现在要加入我们统一的登陆认证中心，而且，我们这个框架，本身就是针对多款游戏的，所以，我们不可以让游戏服务器直接和每个渠道的SDK 服务器进行交互，所以我们增加一个统一登陆认证服务器，姑且叫U8 Server。那么，我们就设计一下u8 sdk的登陆认证流程：1、客户端接入抽象SDK框架，根据当前具体是哪个SDK渠道，调用登陆界面，然后传入用户名和密码，进行SDK登陆操作2、SDK登陆成功，会返回sid等信息3、游戏客户端可以通过SDK抽象层的接口，获取到这个sid4、游戏客户端拿着这个sid以及接入之前向u8 server申请的appid,渠道号等信息，Http访问u8 server进行登陆认证。5、u8 server 根据当前传递的appid, 渠道号，去对应的SDK服务器进行认证6、SDK服务器认证成功，会返回SDK服务器那边的用户信息7、U8 Server拿到用户信息，生成一个u8 server统一的用户信息并存储。然后，紧接着返回给客户端一个有效的token。8、客户端拿着这个token，去访问游戏服务器(多数是游戏登陆服务器)9、游戏服务器，拿着这个token去u8 server 进行登陆认证。10、u8 server 判定token有效，则返回给游戏服务器当前用户的用户信息11、游戏服务器拿到用户信息，证明当前登陆成功，返回给客户端服务器列表等数据，登陆成功。我们再看一个登陆认证的顺序图，可以更直观地看到这个流程的顺序：通过这个新的登陆流程和之前老的登陆流程进行一个简单的对比，大家就可以看出。老的登陆认证流程，对于每一款游戏的服务器，都需要和每个渠道SDK进行交互。但是新的流程，每个游戏服务器只需要和U8 Server 进行交互就可以了，全部由U8 Server进行第三方SDK的登陆认证操作。同样的，每开发一款游戏，客户端也只需要接入抽象的SDK接入层，而不再需要去接入每个渠道的SDK了。所有客户端的操作，和服务器端的操作，都只需要做那么一次就OK了。那么，接下来，我们再来看看支付流程，如果不使用这套框架，我们直接接入SDK，支付是什么样子，我们以UC SDK为例：1.“游戏客户端”调用“SDK 客户端”API 接口，提交充值信息； “SDK 客户端”引导用户选择不同的充值方式，输入充值金额。2.“SDK 客户端”将sid、gameid、serverid 以及对应的充值信息提交给“SDK 服务器”；3.“SDK 服务器”接收充值请求后，将返回对应“订单号”给“SDK 客户端”；4.“SDK 客户端”将回调通知“游戏客户端”对应的充值“订单号”；5.“游戏客户端”将接收到的“订单号”及相关的游戏角色信息（由游戏自行决定） 提交给“游戏服务器”；6.“SDK 服务器”在处理完充值请求后，将通过异步方式通知“游戏服务器”充值 结果。7.“游戏服务器”向“SDK 服务器”返回是否成功接收充值结果的标志（SUCCESS或FAILURE）。充值结果的成功或失败与此处的接收标志无关，不论充值是否成功，只 要“游戏服务器”能够接收并识别充值结果通知，都应该向”SDK 服务器“返回成功标 志（SUCCESS）那么，我们现在要加入我们统一的支付中心，同样针对多款游戏的，所以，我们不可以让游戏服务器直接和每个渠道的SDK 服务器进行交互，我们也增加一个统一支付服务器，我们把支付中心的功能也加到U8 Server里。我们再看下新的支付流程：1、游戏客户端，首先请求游戏服务器要充值2、游戏服务器拿着该用户的id和一些支付成功之后需要原样返回的数据，去访问U8 Server申请订单号3、U8 Server生成一个唯一的订单号，同时数据库中生成一条订单记录，状态是正在支付状态4、游戏服务器将订单号返回给客户端5、游戏客户端，拿到订单号之后，带着订单号以及游戏里充值相关的数据，调用SDK抽象接口的支付接口，调用对应的SDK支付界面，进行充值操作。6、当前SDK的渠道实现在调用SDK支付界面之前，需要把刚刚的订单号，放到渠道SDK支付参数的自定义参数中。这个每个渠道都是一样的。7、渠道SDK支付成功，立马返回一个状态8、同时，渠道SDK服务器会异步通知游戏开发商设置的支付回调地址。注意，游戏接入的时候，这个回调地址要设置到u8 server提供的一个地址。9、u8 server收到充值回调，根据验证结果等判定，立马给渠道SDK服务器返回一个成功或者失败的状态。10、然后u8 server根据自定义参数中的orderID，查询到对应的订单信息，再根据订单信息，获取到当前用户信息和对应的游戏信息，然后调用接入游戏之前，游戏服务器提供给u8 server的支付回调地址。这个回调地址，游戏服务器只需要提供一个给u8 server就可以了。因为游戏服务器只和u8 server交互。11、游戏服务器收到回调，验证成功与否，里面返回给u8 server一个成功或者失败的信息。同时，给对应的玩家加游戏币。这样，大家通过对比两个支付流程图，可以清晰地发现，新的流程，可以做到只接入一次，后面多款游戏，可以共同使用。那么这个就作为我们这个框架的支付流程。我们再发个顺序图，可以更直观地看下整个流程：所以，通过对整个框架需要实现的功能的分析，我们设计了一套可以实现统一SDK登陆认证和支付中心的架构。那么接下来，我们就会具体的来实现每一个部分。包括抽象的SDK接入框架，游戏客户端怎么接入这个抽象的SDK接入框架，各个渠道SDK怎么整合到这个SDK框架中来，怎么实现一键打包工具，怎么实现这个统一的登陆认证中心和支付中心。本系列课程视频教程已经录制完毕，免费的。想要看视频的童鞋请访问：点击打开链接本文作者：小黑转载地址：http://blog.csdn.net/chenjie/article/details/
题记：很多做游戏开发的人，估计都或多或少地接过渠道SDK，什么UC，当乐，91，小米，360......据统计国内市场当前不下于100家渠道，还包括一些没有SDK的小渠道。每个渠道SDK接入的方法呢，多是
相关阅读排行
相关内容推荐
请激活账号
为了能正常使用评论、编辑功能及以后陆续为用户提供的其他产品，请激活账号。
您的注册邮箱：
如果您没有收到激活邮件，请注意检查垃圾箱。2013年10月 Java大版内专家分月排行榜第二2013年3月 Java大版内专家分月排行榜第二2013年2月 Java大版内专家分月排行榜第二
2013年7月 Java大版内专家分月排行榜第三2013年5月 Java大版内专家分月排行榜第三2013年4月 Java大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。如何快速高效的接入移动第三方SDK
时间： 19:50:16
&&&& 阅读：117
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&众所周知SDK接入是一个苦力活,同时维护也是麻烦事。接入了几个SDK以后就将应用工程打的稀巴烂,简直不忍直视。
因此作为领先的Android应用模块化解决方案供应商,apkplug推出了以插件为接入单元的移动第三方SDK快速接入商店apkstore。力图解决这一个困扰开发者多年的问题。
目前apkstore已经集合了ShareSDK,友盟,环信,融云IM等国内十数款优秀SDK组件,未来还将持续不断的接入如支付宝,微信支付等更多组件。
一 基本原理
Apkplug组件的基本原理是以插件化技术为核心，通过将第三方SDK打包为独立的组件(工程独立,资源独立,代码独立)，然后在客户端需要的时候从服务器上拉取下来融入客户端当中。这样做的好处有：
1.第三方SDK作为组件与客户端APP相互独立互不影响
2.客户端app在需要的时候才从服务端拉取,可以减小应用发布时候的体积
3.第三方SDK作为组件可以在云端部署,动态的更新。
4.高度可定制化
为了实现这一想法,Apkplug团队开发了一整套的SDK,包括插件化核心技术Apkplug框架,插件托管云服务及SDK,组件市场apkstore。希望以最简单的方式为开发者提供整套的功能全面的服务。
且看环信IM组件调用示例:
IMSdkAgent imsdkagent=new IMSdkAgent(this,frame.getSystemBundleContext());
imsdkagent.StatIMSDK(
new CheckInitCallBack(){
public void onSuccess(PlugIMSDK service) {
Log.e(&&, &PlugIMSDK&);
//这里就会启动环信界面了
service.StartIM(&&);
public void onFailure(int errorNo, String strMsg) {
Log.e(&onFailure&, strMsg);
如此即可使用环信IM的完整SDK功能了,当然在提供方便快捷的接入方法的同时开发者也可以任意定制个性化的组件以满足自身业务需要,因为我们的所有SDK组件源码都是公开的。
apkplug官网：
apkplug组件市场：
标签：&&&&&&&&&&&&
&&国之画&&&& &&&&chrome插件
版权所有 京ICP备号-2
迷上了代码！无需下载的游戏
您的位置：
震惊！为何快速高效接入了SDK，我的手游公司还是死咗？
　　震惊!为何快速高效接入了SDK，我的手游公司还是死咗?
　　完成一个SDK的接入并没有多少技术含量，但是能接入100个SDK，其实也没什么技术含量。真正有技术含量的还是发行，在我的手游公司死咗的那天我才意识到这个问题，但是为时已晚!也许在2014年，甚至在靠后一点2015年，开一家手游公司，诱拐十来个程序员，开发一个不算太差，用业内行话来说就是一款B级的游戏吧，接上几十个渠道，就可以坐着数钱了，至少不会死。
　　最早进入手游市场的时候，我们也是这么想的，只要多接渠道就能赚钱，于是我们就拼了老命的去接渠道。就和开篇说的一样，接渠道没有什么技术含量，但是坑特别的多，主要依赖于经验的累积。有些人被坑的多了，就想着如何去解决这些坑，比如如果有一个工具只需要接入一个SDK就能够生产所有的渠道安装包，那该多好!有需求，就有市场，尤其是在与我们有同样需求的用户那么多的状况下，解决这种问题的各类SDK如雨后春笋般的冒了出来，棱镜、易接、U8SDK、AnySDK、TypeSDK等等。
　　但从2016年开始，这条路就行不通了，这是为什么呢?我们不是已经用了什么聚合SDK了嘛?照理说我们现在应该身在曼谷的gogobar，身边满是泰国靓女，或是毛里求斯的海滩，晒着太阳吸着鸡尾酒，打开手机一看管理后台都是日均百万的用户充值啊!但我们还是要死了，这是为虾米?因为渠道都在死咗，你知不知道，渠道自身难保，何况你我这种依附于渠道的小CP呢?　　
　　天下着倾盆大雨，失败的创业者站在张江、南山、西二旗等科技园的路口，问着那个千古不变的问题，我是谁?我从哪里来?我要到哪里去?我为什么要做手游?为什么我做手游会死咗?TypeSDK会告诉你，因为你没有做自主发行啊!因为你没有用TypeSDK做自主发行啊!这年头靠渠道有什么用，你只会快速高效接入SDK有什么用，码农们要翻身做主人还得靠自己。
　　那么TypeSDK与传统的渠道聚合接入有什么区别?才能让快死咗的手游公司咸鱼翻身呢。
　　作为TypeSDK的早期功能&&手游渠道聚合接入，这方面就与其他聚合接入工具有着很大的不同。首先，TypeSDK是开源的，作为一款与用户和支付有关系的产品，开源对于用户来说是一种最友善，也是最安全的合作形式，毕竟对于所有人来说只有钱和数据都在自己手里才是最安心的。然后不同于U8、棱镜或者易接的反编译打包，TypeSDK是基于项目打包的，这样有两个好处：1、打包中出现的问题可以直接发现，不用等到包合成以后，成功率远远高于反编译;2、谷歌官方也推荐使用项目打包，这才是正确的打包方式!
　　其次TypeSDK不是单纯的聚合接入工具，针对于2016年以后手游市场的一些新情况，TypeSDK适时的推出了国内国外自主发行系统。而这一系统，是以上所有聚合打包工具，不管是棱镜、易接，还是U8、Qucik，都!没!有!在这套系统里，TypeSDK提供了手游自主发行所需要的全部解决方案，用户中心、支付体系什么的自然都要有，Facebook登录、AppsFlyer广告监控也是一应俱全。如果说TypeSDK是国内唯一的手游自主发行全栈解决方案，笔者也觉得完全不为过!简直就是当之无愧。　　
　　可惜的是，我的手游公司因为只快速高效的接入了SDK，而早早死咗了。要是能早点找到TypeSDK应该事不至此，也许还能抢救一下呢?不，我觉得是一定有救!所以在这里我想和现在的手游开发和发行者说一句话，只有渠道接入的第三方打包工具是靠不住的，未来是自主发行与渠道接入并存的时代，快接入TypeSDK走上自主发行的康庄大道吧。
信息也是生产力，精简才是硬道理！情报猎手带你突破信息迷雾，每日独家为您锁定最有价值的手游行业新鲜事。打开微信，扫描关注，赢取每月粉丝奖！
增值电信业务经营许可证B2-　 闽网文『-017号 客服热线: 1
& All rights reserved
福建博瑞网络科技有限公司 版权所有}