本文已独家授权 鸿洋( hongyangAndroid ) 公众号发布！
前不久入职于一家游戏研发公司，公司部门给我的开发需求是研发H5游戏SDK和对接H5渠道SDK（对于只有App研发的我来说，其中经历和酸甜苦辣那可真是一把鼻涕一把泪。不乏笔者牺牲周末时间去熟悉该业务的朋友公司向他取经讨论技术方案，画UML图等等）。既然是完成需求，首先需要分析这个需求是用来做什么的，接下来在去考虑现有的技能点如何完成产品需求。
虽然更多的Android Developer倾向于APP研发（倾向，这个词形容的不是太好，因为APP依旧占市场主导地位）。但考虑到未来的某些日子，一些哥们去了新公司也会遇到这种情况，而且要命的是网上可查询资料几乎就是打广告打广告，免费解决技术方案的参考实在太少（这根本不能符合我大Android集思广益忠于开源的灵魂好嘛）这实在是让我深恶痛绝！所以这篇文章不仅是针对未来有类似研发需求的朋友传道解惑，节约时间少走弯路，而且更主要的是揭开关于Android游戏SDK的神秘面纱。文章延续之前的风格，篇幅虽长，但力争写得清楚，也是方便各位看官清晰明了易于理解。
另外老版本SDK已经删掉了因为种种原因，新版本SDK已经编码完毕，源码见末尾。
问题：游戏APK，到底是什么？
和APP不同，我们编写APP一套代码测试编码无误后，打包上线推广维护即可，这就是APP研发流程；但是游戏apk那就大相径庭（以下简称手游）了，因为手游使用到的技术是基于游戏引擎研发的。如unity3d，cocos2dx，H5用到的Egret等等。你不可能说，哇，老铁没毛病我给你在Android Studio上去开发游戏。那么，作为Android开发，我们暂时先不研究游戏研发的具体内容，只关注Android本身开发即可。换个角度想，那些专门写游戏代码的哥们，也不知道你Android，ios怎么写（当然，大牛技术狂魔除外哈），游戏技术只关注这个游戏场景怎么弄，怎么设计个帮派技能，怎样让你多充钱变的更强等等。那么，纯粹从技术的角度去分析游戏APK，介绍下我在公司的这些日子，个人对手游APK最简单的理解（原创公式，非喜勿喷）：
渠道手游SDK + 游戏研发 = 手游
概念一：渠道手游SDK
在Android开发中，有多渠道打包的概念。简单点说，apk需求完成以后，但需要给用户去下载去可以使用。用户下载使用体验有流量，有流量app才能赚钱盈利。但是你可能说，没事，咱家技术哥体力强技术棒轻松无痛苦在撸一个给用户下载的平台。当然，这是不可能的。因为你不仅要考虑怎样推广怎样运营还需考虑用户量的大小消费者对应用的偏好等等。
引用下《猎场》的台词，找最专业的人，做最专业的事。
这种聚集了一定用户量的平台，一般称为，渠道。通过渠道，就可以解决上面的问题。 比如，360手机助手，豌豆荚，应用宝等等，这些就是渠道（这种千万级的渠道也称大渠道）。所以，我们多渠道打包，打的就是渠道包，将这些渠道包，上架到对应的平台上，让他们上架APP，供用户下载使用体验即可。
说完渠道，我们就开始说渠道SDK，上面说了，渠道会有很多家，大渠道如豌豆荚、应用宝这些，小渠道如，XXX、XXXX这些，既然是不同的渠道，那么每一家渠道就会有自己的数据后台以及相应的个性化设置。
举个例子，应用宝和豌豆荚主要就是给用户去下载不同的apk，他们的核心都是是下载应用，主要功能如手机注册，登录，获取注册验证码等这些基本功能（也称为 接口）本质上也是一样的；不同点就是，他们的UI不同，后台架构，请求参数等等这些也不同。
那么，渠道SDK就可以简单理解为（个人理解），在同一业务节点上，满足市面上相同业务的基本功能，但提供相对差异化的服务。（相对差异化的服务，简单理解就是UI和数据结构差异，并不能理解为功能上的大差异）。
基于渠道SDK，在举个简单的例子加深其概念理解。当我们集成百度地图or高德地图；极光推送or信鸽推送；热云统计or TalkingData,这些第三方SDK的时候，他们主要完成的功能业务几乎都是一样的，比如地图主要是为了定位和出行方便；比如推送是为了吸引用户，唤起APP；再比如数据统计，是为了收集用户数据做筛选统计等；他们在某一块做着相同的事情，但他们是不同公司的产品（当然，也不排除换马甲的这种可能）也就是不同的渠道。不同的渠道做同一业务节点上SDK的研发，市面上对他们有个统一的说法，就是渠道SDK。
SDK开发（SDK翻译过来就是，软件开发工具包）其开发本质就是，隐藏内部实现细节，对外提供公共的访问方式（是不是很像封装）。但SDK需将逻辑结果告知调用者，这个接口的功能你是调用成功还是失败 ，成功以后你会通过SDK拿到什么样的数据等等。
SDK开发的优点就是，拓展性较强。这里的拓展性不仅可以理解为，SDK是专注于为某一个功能模块提供一套完整的解决方案，减少各应用开发周期和难度，而且，可以为很多家想使用SDK的应用提供相同的技术方案，复用性较强。
概念二：游戏研发
说完渠道SDK，在额外拓展下游戏研发。游戏研发的内容一般是使用unit3d，cocos2dx等游戏引擎去完成研发内容，研发游戏的技术人员，刚才说了，这里我们不具体探讨他们的研发技术，这里只讨论他们的角色。换个角度想，做APP研发的时候，接入地图SDK是不是首先会在他们的渠道上面，申请我们自己开发应用的参数（比如 AppId，AppKey等），去激活使用这套SDK。参数配置完毕以后，然后，在具体场景的代码中，去调用该SDK逻辑。以登录场景，举个伪代码例子：
Sdk.Login()；
那么，当应用场景调用此功能（简称接口），就会调起SDK的登录。但是，上述伪代码是有问题的。设想，当手游开始时，首先肯定会唤起登陆接口（一般是游戏先初始化，在调登录接口），但是，接入SDK的开发人员（也属于游戏研发公司的技术）怎么知道登录用户登录成功或登录失败？而且，实际开发场景是当玩家登录成功以后，游戏研发或者其他第三方（一般是聚合平台）还要去记录用户的信息（所以，玩手游呐，你的账号信息会暴露给一些人，后台会记录你的数据然后进行数据分析和数据挖掘......）。但是，SDK的内部逻辑是走SDK自家的服务器，你只是使用罢了。（你要说抓包，那也是呵呵哒，接口一个个抓，岂不是抓到天荒地老）所以，SDK常用的做法就是通过接口回调的方式，将接口回调的结果告知调用者（也就是游戏研发），这个登录接口成功还是失败。下面是一个初始化接口的截图，通过接口回调，告知调用者该初始化接口是成功或失败，然后从接口的response里面去获取到什么样的数据
另外，上面也说到了关于游戏研发的内容，这里不做过多描述。因此，本文所指的游戏研发具体是指，对接渠道游戏SDK的技术人员。需要注意的是，有些公司的SDK开发，不仅要写渠道SDK也负责对接其他家的渠道SDK。当然本文重点是突出如何编写渠道的SDK,因为开源的项目是一套Android渠道SDK。既然是渠道，所以大家可以私人订制、随意扩展。
分析：H5游戏SDK
说完Android在谈谈H5的游戏SDK。顺道说一声，最近在游戏领域H5游戏可谓是趋势刚猛异军突起，可能一说H5，程序猿思维就直接告诉我们，这不是写前端网页的嘛。没错，H5的确是写网页的，但是H5适配客户端的优势相较于之前Html的几个版本优势会更加明显。而且，H5游戏开发周期相对较短，灵活性较强。 我们知道，在Android加载H5只需要webview.load(url)即可，所以，现在市面上也很流行将H5游戏打包成Apk(是的，将H5打包成APK，一个包才几M，之前的游戏APK动辄百M，这样也为用户节省内存)网络环境较好的情况下，用户体验也比较流畅，那么，既然是H5的渠道游戏SDK，我们也来分析下其使用的技术栈。
既然是H5，那么在纯粹的网页上，肯定会用到JavaScript（AJAX,JQuery）等技术。如果是打包成Apk,市面上常用的做法有如下两种，一种纯H5展示，还有一种即H5互调Android。因此，H5的游戏SDK一般分为两套（以下只是我个人的分析，若分析有误，请大家不吝赐教）：一套SDK就是纯粹的JS，Android直接用webview加载url即可，所有的登录或支付全部是url内部完成；还有一套SDK就是Android调H5，H5调Android混合调用。第一种的话，Android这边只需要webview处理即可，所以我们针对第二套SDK方案作进一步的技术分析。
当应用启动的时候，一般会先调用初始化接口。
初始化接口首先肯定会访问渠道服务器后台，当客户端请求参数和拼接规则符合后台规则时（比如渠道后台给你分配的appId和appKey这些必要的参数），也就是初始化成功，然后在调起Android的登录界面。（当然，界面包括登录界面，注册界面，支付界面等）当用户登录成功以后，webview在去加载url（这个url可以写在客户端，也可以由后台返回，实现方式很多种），也就是用户进入游戏正式开车。（当然，这只是其中的一种分析，不排除有别的实现方式，如果有别的实现方式，请知会笔者，因为笔者现在也只是摸着石字过河）。基本的一些使用我会在下面的开源SDK进行更加详细的说明。
开源SDK声明：
1：本项目使用到了2个接口（登录、注册），具体来说是 玩Android网站 开放API，项目源码没有涉及任何商业机密，所以请放心学习研究使用！（这里在次感谢鸿洋大神）
2：之前开源的那套SDK项目个人觉得太LOW，虽然大家点了上百个star，但思考在三最后还是决定重写，所以原库已被笔者毫无保留的给删除了。
3：最新版本的SDK是 基于Android界内流行的MVP架构进行编码设计且抛弃了传统代码布局！
4：新项目短小精悍但是容易拓展，至于怎么拓展怎么玩怎么使用、主观能动性全在开发者自己手中，所以，你懂的。
5：新项目个人更加想表达的并不是针对需求的面面俱到，而是通过分析现象去思考并解决问题，比如现有的设计模式以及设计架构能否满足现阶段开发需求以达到思想互通与共鸣。
项目说明及使用：
关于MVP模式，这种架构主要是用来解决 View层与逻辑层过重的耦合导致的诸如后期维护困难等一些问题，这种架构的编码细节实则是通过接口回调进行结果传递来达到项目解耦、职责细分这一目的。在文章的前面也说到，既然SDK开发的本质是将结果回调给接入人员，那么这两种思想本质是互通的。当然这也是新版本使用到的设计架构。另外，关于MVP这一模式我想要说的是，市面上流行很多MVP不同的设计版本，每一个版本都有它自己的优点。笔者项目里面的MVP编码应该是相对来说比较好理解的且已经伴随好几个项目了。所谓：一千个读者有一千个哈姆莱特。寻找适合自己的才是最好的。
好了，下面是项目结构图：
红色矩形：SDK内部逻辑编码层（本质库文件、将其打成jar包给对接技术使用）
绿色矩形：主要是用来测试SDK内部逻辑是否正常，一般是用此测试类进行技术对接。下面以登录为例进行说明：
这里是测试类SDK登录的源码设计，可以看到这里首先调用了SDK内部的逻辑层（这里的GameSdkLogic我将其定义为组件核心类），然后通过接口回调进行了状态码判断操作。试想我们在不知道源码的情况下，通过现象去分析本质该如何设计？点击登录接口首先 需要唤起登录界面（View层），然后账号密码输入成功以后才可以登录成功（逻辑判断），登录成功以后回调到这里的组件核心类，在将结果回调给外部，至此，整个流程完毕！因此，笔者源码的设计原则也是基于此进行开发：
好了，现在进入到登录界面之后，我们首先构建 HttpRequest，接着，后台sever接受请求 返回响应体，客户端收到响应体后根据规则去判断用户是否登录成功，登录成功以后在将结果回调给V层。至此整个流程就结束了。
另外：关于SDK的配置，诸如横竖屏配置等一些灵活性较强的功能，SDK内部应要提前设计好。笔者这里的UI是基于XML来进行编写，抛弃了传统代码布局那种琐冗余费时费力且不讨好的写法；另外，关于浮标这一功能，我也没有进行编写，因为在github上有位作者开源了此类轮子，虽然笔者没有clone下来仔细研究但貌似效果还是不错。
这里提一嘴，由于游戏SDK对接的游戏会非常多，官方的微信支付一个账号只能注册10款应用，所以，开发中需要考虑可替代微信支付方式，比如可以接入第三方的H5微信支付去替代传统微信支付。接入第三方的数据统计功能也需要考虑到，对接我们渠道的技术，是否也集成了相同的数据统计功能，如果集成的话该如何处理等等。
更多细节请 参考源码
不积跬步无以至千里，不积小流无以成江海。希望我们能够不断丰富自己的技术栈，早日走上技术之巅！
如果这篇文章对你有帮助，希望各位看官留下宝贵的star，谢谢。
Ps:著作权归作者所有,转载请注明作者, 商业转载请联系作者获得授权，非商业转载请注明出处(开头或结尾请添加转载出处，添加原文url地址),文章请勿滥用,也希望大家尊重笔者的劳动成果,谢谢。
