后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
我要游戏程序
查看: 2737|回复: 2
高效率完成一次接入80个手游渠道SDK——游戏接入SDK服务端篇
& & 通常，游戏开发商并不会只在一个渠道上线他们的游戏，接入越多的渠道，代表着可能获取越多的用户，但同时也代表着越多的接入SDK工作量、工期和费用。一款游戏要有足够的用户，甚至需要接入30家以上的各种渠道，以保障自己的市场覆盖率。单个SDK接入流程在一位有经验的全职客户端程序、一位全职服务端程序员、一位全职QA处理的情况下，需要3天时间才能完成。因此当一款产品面对30个甚至更多不同需求的渠道SDK时，人员成本和时间成本就会急剧增加。所以我们需要一个通用接口，来处理各种渠道的需求，这就是统一渠道SDK接入框架。 本部分主要提供平台SDK服务器与CP方游戏服务器交互的接口规范1.2& &支付基本流程1.2.1 渠道支付流程游戏客户端在每次用户点击购买时向服务端请求生成内部订单。并需要采用特定机制（例如一定时间内禁止连续点击购买）防止用户频繁操作对服务器造成过高负载。游戏服务端生成的所有内部订单需要存储待查。并在得到渠道返回的外部订单后异步处理发货操作并以特定机制通知客户端更新数据显示。渠道支付接口负责完成货币交易操作，生成并存储外部订单，供对账查询使用。& && & SDK服务端转发请求时额外存储一份订单日志数据，存储内部订单号，外部订单号及订单状态，供对账及查找BUG时作为参考。
1.2.2 一般渠道支付流程图1.3 协议说明1.3.1 通信协议& && & SDK服务器采用HTTP协议作为通信协议，游戏服务器通过构造HTTP请求（POST方式）向SDK服务器发起接口请求。1.3.2 数据协议1.数据格式& && & 请求消息和响应消息的内容都使用JSON表示数据。2.字符编码& && & 请求与相应内容均采用UTF-8字符编码3.签名规则& && & 请求和响应中的签名均使用md5哈希进行，算法如下：& && & MD5(签名内容 + ”|” + apiKey)& && & 说明：& && & ·MD5使用RFC1321标准，编码后需转换成全小写。& && & ·描述签名的表达式中，”+”表示做字符串连接，实际产生的待签名字符串中并不存在。& && & ·签名内容指各接口请求数据中若干字段的拼接。基本格式为各字段值以 ”|” 符号分隔后直接连接。注意，由于”|”符号用作分隔字段，签名内容中需避免出现该符号，换行符(回车或换行)等特殊符号也需要预先剔除。如果对应字段为空，仍然需要保留“|”符号占位。& && & ·计算MD5签名时，应以UTF8编码取字符串的字节值。& && & ·appid及apiKey由打包工具分配，打包工具使用方法请参考使用文档。4.签名示例& && & 假设请求数据为：& && & “data:{& && && && &&&“id” : 123,& && && && &&&“name” : “test”& && && && &&&“value” : “something”& && && && &&&“other” : “blarblar”& && & }& && & 要求的签名内容为:id + name + value则拼接后得出要签名的内容串为123|test|something假定apiKey=aabbcc，则需要进行MD5哈希的字符串为：123|test|something|aabbcc 1.4 接口说明1.4.1 用户会话验证1.请求地址：http://TypeSDKORT/{appid}/{channelid}/Login/& && & 说明：URL中的{appid}代表游戏代码，由打包工具生成，{channelid}代表渠道代码，渠道代码列表可以参考打包工具说明，可以从客户端提交的参数中获取当前渠道代码。& && & 例： http://192.168.0.1:/1/Login/2.调用方式：HTTP POST3.接口描述：& && & 验证用户登录结果。A)& &游戏客户端通过SDK客户端的登录动作获取用户登录信息。B)& &游戏客户端将获取的用户登录信息传送至游戏服务端。C)& &游戏服务端通过本请求将用户登录信息传送到SDK服务端，验证该登录信息是否有效。D)& &SDK服务端返回验证结果及其他信息，供游戏服务器使用。4.请求方：游戏服务端5.响应方：SDK服务端6.请求内容（JSON格式）：字段名称
用户唯一标识
对应渠道的用户ID。并非必传，未作说明的情况下传空字符串。
用户登录会话标识
本次登录标识。并非必传，未作说明的情况下传空字符串。
附加信息。并非必传，根据渠道不同，该字段含义不同，未作说明的情况下传空字符串。
MD5(签名内容 +&&”|”&&+&&apiKey)
签名内容：
Id + ”|” + token + ”|” + data
7.返回内容（JSON格式）：字段名称
本次请求结果标志
用户唯一标识
对应渠道的用户ID
用户在渠道的昵称
对应渠道的用户昵称
用户登录会话标识
本次登录标识
如果请求出错，描述错误信息。
渠道返回信息
渠道返回的原始结果信息。
响应码说明：& && & 0：渠道正常返回，结果成功& && & 1：渠道正常返回，结果失败& && & 2：渠道服务端请求错误& && & -1：提交的请求参数错误& && & -2：提交的请求转换成渠道参数错误& && & -3：提交的请求参数签名错误& && & -99：未知错误id,nick,token说明：& && & 根据不同渠道定义的返回字段不同，此三个字段不一定有值。渠道未返回对应字段时，该字段值为空字符串。1.4.2 充值结果回调1.请求地址：& && & 该地址为充值结果通知地址，由游戏服务端在下文的SaveOrder接口中通过notifyurl字段提交至SDK服务端。2.调用方式：HTTP POST3.接口描述：& && & 通知用户充值结果。A)& &用户在游戏中向SDK客户端提交充值请求。B)& &SDK客户端将充值请求转发渠道方C)& &渠道方异步执行充值。D)& &渠道方将充值结果发送给SDK服务端E)& &SDK服务端通过该接口将充值结果发送给游戏服务端。F)& & 游戏服务端处理充值逻辑。G)& &游戏服务端向SDK服务端返回处理结果。H)& &SDK服务端向渠道方返回处理结果。4.请求方：SDK服务端5.响应方：游戏服务端6.请求内容（JSON格式）：字段名称
渠道返回的充值结果。
用户唯一标识
对应渠道的用户ID。
渠道订单号
渠道返回的订单号。
游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数，则该字段为空字符串。
订单附加信息
游戏客户端在提交订单时传送的附加信息。如果该渠道未接收该参数，则该字段为空字符串。
MD5(签名内容 +&&”|”&&+&&apiKey)
签名内容：
code + ”|” + id + ”|” + order+ ”|” + cporder + ”|” + info
该笔订单价值折算为人民币的金额（以分为单位）供服务端校验使用，不参与签名。
7.返回内容（JSON格式）：字段名称
本次请求结果标志
如果请求出错，描述错误信息。
响应码说明：& && & 0：正常返回，结果成功& && & 1：正常返回，结果失败-99：未知错误
8.推荐处理方式游戏服务端收到该请求后可保存该次请求参数，随即返回code=0，表明成功收到消息。之后异步处理充值或发放道具逻辑。1.4.3 充值信息提交1.请求地址：[url=http://typesdkORT/%7bappid%7d/%7bchannelid%7d/SaveOrder/]http://TypeSDK:PORT/{appid}/{channelid}/SaveOrder/[/url]& && &说明：URL中的{appid}代表游戏代码，由打包工具生成，{channelid}代表渠道代码，渠道代码列表可以参考打包工具文档，可以从客户端提交的参数中获取当前渠道代码。& && & 例： 2.调用方式：HTTP POST3.接口描述：& && &充值信息存档待查。A)& &用户在游戏中向游戏服务端提交充值请求。B)& & 游戏服务端生成内部充值订单号及相关充值信息C)& &游戏服务端将内部充值订单号及相关充值信息返回游戏客户端，供其提交给渠道方。D)& &游戏服务端异步将内部充值订单号，该笔订单回调url及相关充值信息发送给SDK服务端。E)& & SDK服务端将充值信息存档待查并返回处理结果。4.请求方：游戏服务端5.响应方：SDK服务端6.请求内容（JSON格式）：字段名称
游戏客户端在提交订单时传送的内部订单号。
由CP生成订单时自定义的附加信息,不能为空及空字符串。
MD5(签名内容 +&&”|”&&+&&apiKey)
签名内容：
cporder + ”|” + data
订单回调url
该笔订单回调通知游戏服务端的url，不参与签名。
订单查询url
该笔订单向游戏服务端查询详情的url，不参与签名。
7.返回内容（JSON格式）：字段名称
本次请求结果标志
如果请求出错，描述错误信息。
响应码说明：0：正常返回，存档成功1：正常返回，存档失败-1：系统错误-2：参数错误-3：签名校验错误-99：未知错误注意：SaveOrder接口在服务端生成内部订单号时请求。只有获取到该请求成功返回，才能允许客户端作后续充值动作。1.4.4 充值信息确认1.请求地址：& && &说明：URL中的{appid}代表游戏代码，由打包工具生成，{channelid}代表渠道代码，渠道代码列表可以参考打包工具文档，可以从客户端提交的参数中获取当前渠道代码。& && & 例： 2.调用方式：HTTP POST3.接口描述：& && &充值信息查询。A)& &SDK服务端向游戏服务端转发充值结果回调。B)& & 游戏服务端向SDK发送充值信息查询请求，目的是确认该充值结果有效性。C)& &SDK服务端根据提交的内部充值订单号查询充值信息并返回游戏服务端。D)& &游戏服务端根据查询结果进行逻辑处理。说明：部分渠道提供信息查询接口，本接口将优先使用渠道的信息查询接口处理请求。如果该渠道没有提供信息查询接口，则查询 3.3.3 充值信息提交 接口中保存的充值信息，如果创建充值信息时没有调用该接口，或者没有查询到目标订单对应的充值信息，则会返回未查询到相应充值信息。4.请求方：游戏服务端5.响应方：SDK服务端6.请求内容（JSON格式）：字段名称
游戏客户端在提交订单时传送的内部订单号。
MD5(签名内容 +&&”|”&&+&&apiKey)
签名内容：
7.返回内容（JSON格式）：字段名称
本次请求结果标志
如果请求出错，描述错误信息。
订单详细信息
根据渠道不同，返回相应订单信息。
响应码说明：& && & 0：正常返回，获取订单信息成功& && & 1：正常返回，没有获取到订单信息& && & 2：正常返回，获取订单信息错误-1：系统错误-2：参数错误-3：签名校验错误-99：未知错误1.4.5 游戏订单查询1.请求地址：& && & 该地址为订单查询地址，在SaveOrder接口中通过verifyurl字段提交至SDK服务端。2.调用方式：HTTP POST3.接口描述：& && & SDK服务端向游戏服务端查询收到的订单信息。A)& &用户在游戏中向SDK客户端提交充值请求。B)& &SDK客户端将充值请求转发渠道方C)& &渠道方异步执行充值。D)& &渠道方将充值结果发送给SDK服务端E)& &SDK服务端通过该接口向游戏服务端查询该充值请求是否合法。F)& & 游戏服务端处理查询逻辑。G)& &游戏服务端向SDK服务端返回查询结果。H)& &SDK服务端比对订单信息并依此确定下一步处理流程。4.请求方：SDK服务端5.响应方：游戏服务端6.请求内容（JSON格式）：字段名称
预留字段，区分本次查询操作类型。目前统一传0
用户唯一标识
对应渠道的用户ID。
渠道订单号
渠道返回的订单号。
游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数，则该字段为空字符串。
订单附加信息
游戏客户端在提交订单时传送的附加信息。如果该渠道未接收该参数，则该字段为空字符串。
MD5(签名内容 +&&”|”&&+&&apiKey)
签名内容：
code + ”|” + id + ”|” + order+ ”|” + cporder + ”|” + info
7.返回内容（JSON格式）：字段名称
本次请求结果标志
如果请求出错，描述错误信息。
用户唯一标识
对应渠道的用户ID。
渠道订单号
渠道返回的订单号。
游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数，则该字段为空字符串。
该笔订单价值折算为人民币的金额（以分为单位）。
createtime
订单创建时间
该笔订单创建时间。
该笔订单的道具id，如果没有传空字符串。
(该字段标识订单中的商品ID，需要与客户端下订单时对应的字段匹配，验证对比不符时不发货)
Itemquantity
该笔订单道具数量，没有传0。
（该字段标识客户端提交的订单中的道具数量，渠道不接受该字段时，客户端提交的订单没有该字段，此时直接传0或1均可）
订单状态码。
备用字段，传送其他可供比对的信息。
响应码说明：& && & 0：正常返回，结果成功& && & 1：正常返回，结果失败-99：未知错误8.推荐处理方式游戏服务端收到该请求后优先以CP订单号为条件查询，查询不到或请求中没有CP订单号时以渠道订单号为条件查询，找到匹配的订单信息并同步返回SDK服务端。1.5 约定l&&支付相关接口内部订单号字段长度不能超过10位，格式使用英文字母和数字的组合，需要能够区分区服。不可重复。l&&渠道返回的用户id用于用户唯一标识。单区服内不可重复。l&&支付接口返回的amount是当次支付产生的实际金额。
该项目已开源，大家有兴趣可以自己研究或使用接入
项目地址：
项目地址：
提供游戏支付整体解决方案，接口有微信、支付宝、银联SDK,WAP,详情私聊qq：.后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
运营：手游常用渠道SDK接入事项流程
22N58PICYu4.jpg (81.07 KB, 下载次数: 20)
16:29 上传
　　文／66TEAM
　　常见渠道
　　安卓：360手机助手、UC（九游游戏中心）、百度移动游戏、小米、豌豆荚、当乐、安智、应用汇、益玩；
　　安卓终端（硬核联盟）：华为（智汇云）、联想（乐商店）、OPPO（可可游戏中心）、步步高（vivo）、金立、酷派；
　　越狱：91助手、PP助手、同步推、快用、itools、XY助手、爱思、海马；
　　运营商：移动、电信、联通
　　SDK接入流程
　　1、制作裸包
　　让研发-客户端技术制作产品裸包，针对账号解决异常问题并预调高级账号供渠道顺利测试。
　　如之前对外测试过，玩家已安装过游戏，那么为避免玩家进入渠道测试服，在接入新渠道时最好制作直连渠道测试服的包，好处是无外网IP限制，省略为渠道添加IP白名单的步骤。
　　2、提交评测
　　填写各渠道的新游接入表、联络表、评测表等，填好后和裸包一并交给我司渠道商务，商务联系各渠道进行评测/评级。
　　部分成熟渠道例如360、UC、百度……会对产品评级，用来确认后续合作中的推广资源。评测历时3天左右，期间请保证渠道测试人员能够正常游戏。
　　3、拉SDK联调群
　　由商务与渠道商务建立讨论组或Q群，并拉齐双方运营、客户端技术、渠道SDK技术支持人员。
　　前端技术：在后续接入SDK时有任何技术问题可直接在Q群咨询渠道方SDK技术支持人员即可。
　　运营：全程配合商务满足渠道提出的需求。包括渠道后台创建应用、获取参数、提供产品资料、软文、建立专区、论坛、确认上线时间、运营计划、预热活动、发布软文、新闻、发布大事件（UC）、制作并提供礼包、用户服务等等。
　　4、获取参数
　　4.1渠道后台创建应用获取参数
　　向渠道商务要最新的各渠道后台地址、账密。
　　运营在各渠道的开发者后台创建应用，即可获取appID、appkey、支付密钥等渠道参数，整理所有渠道参数表，通过邮件发送给平台进行配置，邮件记得抄送给研发前端技术，待平台配置好并回复后研发前端即可在接入产品时使用该参数。
　　部分渠道没有后台或创建后无法获得参数，直接在讨论组中向渠道方获取即可。
　　一般渠道可直接创建应用获取参数，但部分渠道在创建时就需要安装包、资料等，需准备好后再一同提交创建。
　　4.2产品上线所需素材准备
　　游戏名称：尽早在各渠道确认是否有重名应用等情况，与市场确定最终游戏名称，尽量避免走改名流程，否则会给各个部门增加不必要的工作量。
　　Logo：确定名称后制作相应logo，向美术要大图psd备用。
　　申请软著：向商务部提出申请软著的需求，没有软著无法上线。若名称确定沿用可同时申请商标（版号、文网文备案等全套资质带软著申请下来后可继续申请）。
　　ICON：事先向研发索要512×512的游戏ICON（最好是PSD格式），由运营向美术发需求添加各渠道角标并批量各种尺寸。
　　各渠道所需常用尺寸：36，48，57，72，76，96，114，120，144，152，175，192，512
　　宣传图：由于各应用商店上架都必须要游戏宣传图，需要在提包前准备好。
　　这期间需要研发提供游戏的美术素材及相关资料，包括绘制高清角色模型等png，运营和市场也要亲自体验游戏并截出大量可用于推广的图，5张宣传图的slogan由运营和市场开会讨论后确认；
　　软文：部分渠道创建应用、建立专区、开测上架时需要游戏介绍、一句话描述（20字内）、攻略软文等，由运营负责撰写。同时还需要研发提供一个能对外展示的PPT产品介绍以及word产品说明，运营了解产品后也可自行撰写PPT。
　　配置各渠道充值回调地址：运营在渠道后台配置或给渠道配置充值回调地址后才能接通支付。
　　安卓：xx
　　越狱：xx
　　5、平台集成
　　如果是公司已合作过的渠道（代表平台已集成过该渠道SDK），运营需要在各渠道开发者后台查看各渠道的SDK是否更新，并在xx检查平台集成的SDK是否为渠道发布的最新版本。
　　如果为旧版，需下载渠道开发者平台中的最新版SDK并发邮件给平台进行更新集成。
　　如为最新版本，直接让研发的前端技术在xx下载集成好的SDK开始接入产品。
　　接入之前，运营应通过邮件告知研发，并倒推、约定好需要最终接完并出包的时间点；
　　期间请运营协调好研发前端、平台、渠道技术支持人员的沟通，避免发生在中间传话的现象。
iOS渠道支持：xx安卓渠道支持：xx支付SDK支持：xx中心服支持：xx
　　6、渠道SDK接入及提交测试
　　6.1渠道SDK接入和自测调试
　　研发-前端技术在xx上获取各渠道的SDK文档进行产品接入。
　　SDK文档中除了基础的集成包之外，还包括了渠道SDK的规范文档，部分渠道（尤其是安卓渠道）会在文档里提出各自的要求，请研发技术务必仔细阅读渠道的SDK文档并按照文档要求进行开发。部分渠道的文档里包括开发者自检规范，请研发技术在开发完毕后务必仔细对照规范进行自检。
　　各渠道要用规定的包名、icon角标、进游闪屏logo、用户中心、悬浮标等功能需求，以及在plist或manifest.xml中所填的信息需求，请务必符合渠道要求。
　　研发接入完SDK务必协调QA部门进行相关测试（部分sdk包中有自测用例，例如UC的，在测试后还需要填写，并在提交包时在后台上传）
　　付费方面的测试由QA协助测试，如个别渠道可以申请测试帐号的，运营可以协助申请，技术方面的支持找平台中心负责支付的同事。
　　6.2渠道审核
　　研发需按事先约定时间制作完渠道SDK最终包，自测后传给运营。最少要在上线前3天以上出包。
　　运营提交最终包给渠道审核，如发现问题打回，由运营转达给研发进行修改，直至审核通过。
　　由于每次返回修改包后渠道都是从头重启审核流程，因此请研发务必尽快完成修改。
　　渠道测试反馈中标明必须修改的地方，研发务必进行修改，否则无法上架。
　　渠道审核通过后，由我方约好上架时间，通知研发准备开服。
　　个别渠道特殊问题
　　UC/九游参数获取：
　　进入UC后台，选择产品，进入配置sd参数、支付地址界面。
1.png (6.31 KB, 下载次数: 6)
16:30 上传
　　点击发送到该邮箱即可。
2.png (7.84 KB, 下载次数: 5)
16:30 上传
　　其中serverId请联系UC技术接口人配置，配置后可在平台上看到，查看地址：
关注我们官方微信公众号
下载我们官方APP-游戏行
关注手游动态微信公众号
背靠4亿小程序用户，小游戏想通过两种广告游戏开箱到底算啥？比利时：就是赌博 罚款大厂们为什么都一致押宝沙盒游戏？杉果 —— 砥砺前行的“单机”老兵三消类游戏突破之作 RPG战斗消除手游《童话硬核动作游戏《SINNER 救赎之路》今日正式
微信扫一扫关注我们→溪谷每次动态 都能让您尽在掌握
手游联运 你必须知道的一些平台知识
当前位置： >>
手游联运顾名思义就是手游联合运营，是指网络游戏研发厂商（“简称CP”），以合作分成的方式将产品放到其他合作平台上来运营，即手游研发厂商提供手游原包、手游更新包、手游充值系统、玩家服务系统等必要原始内容，合作平台提供平台使用权、广告位等资源进行合作运营。手游市场中的产品数量、厂商数量、用户数量等之间供求的变化直接影响着手游联运平台的存亡。而联运涉及到的环节之多，做法之复杂，手游联运平台需要围绕产品做特别精细化的工作，包括市场调研、资源优化、后台数据分析等等。对于联运平台来说，纵使自身平台上有大量优质的用户，也不可避免地需要和一线渠道建立起“铁磁儿”关系。尽管现在流量越来越分散，一线渠道的话语权也是不容忽视，其平台上的用户量和用户质量都抛开二、三线渠道不止一个身位。由此可见，渠道关系对于联运平台来说有着关键性的作用。而做得好的联运平台最起码有自己“擅长”的一两个一线渠道。对于手游联运平台来说，优质的手游产品、出色的渠道接入、强大的运营能力任何一项都不能出现断层。
相关文章:平台开发常识 更多
手游sdk常识
手游平台常识
平台开发常识
手游app常识手游运营应用搭建找哪个方式好？_百度知道
手游运营应用搭建找哪个方式好？
手游运营应用搭建找哪个方式好？
我有更好的答案
主要用到的是
SDK系统，目前比较流行的是
系统，重庆玖度
技研发的，免费使用。
采纳率：45%
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。