各位看官大家好，经过第一篇 手游SDK — 第一篇（序言）的大体介绍，想必大家应该是对手游SDK有了大体的概念。废话少说，下面欢迎大家跟我走进客户端架构篇，慢慢分析如何搭建一个符合业务需求的SDK架构方案。PS：说明下，由于本人的水平有限，该架构的设计及实现都是基于工作的业务需求及开发经验的总结，有不足的地方还希望大家可以留言指正，同时也感谢Laimo老师的指导。
架构设计的业务场景：
1、基于前文的介绍，游戏SDK最大的业务场景就是需要对接N多的应用渠道，这个是国内特有的，海外一般只有Google和App Store两个平台。所以如何快速、方便的接入渠道SDK及后期的维护SDK就是设计时需要考虑的问题了。
2、SDK的业务场景更多的会集中在账号、支付及数据收集这里，账号体系细分的话，又会有不同的登录逻辑、绑定逻辑、切换逻辑。如：手机游戏通常分网游和休闲游戏，网游一般会有账号的登录、注册等入口，而休闲游戏更多的处理是以手机设备信息来做用户的区分或者通过随机生成一个账号，走游客账号登录；账号入口又可以细分是否有用户的界面，无用户界面的话，怎么处理用户的登录方式及登录、绑定、切换逻辑；支付的话，国内常用的有微信、支付宝等三方支付，还有运营商的短信支付，而且在运营商在不同的省份又会有不同管控，需要我们开发者做后台开关去做控制；数据收集的平台通常不只有一家，不同的游戏是不同的公司，对应的数据平台也不一样，怎么去做差异化处理；在此基础上，后期的话，还有额外的运营需求都需要添加功能。
3、SDK的功能插拔，可能某款游戏上架国内渠道需要提供这个功能，上架Google平台又必须拔出掉该功能或者新增另外功能；游戏游戏需要SDK提供Google支付，有些游戏又只要微信支付，或者都要，但是要优先级，先弹出微信支付，没有微信支付自动弹出支付宝支付等等。
4、除了跟业务相关的需求外，还需要考虑一个比较重要的事情就是，游戏如何方便、快速地接入游戏SDK？业内的通用做法是通过游戏打包系统，批量的打游戏SDK包。（这块后续会跟大家讲解下及实现原理）
PS：业务场景太多了，业务逻辑也很复杂，会导致项目可能会因为需求分化成小项目越来越严重，同时不同的人员维护开发同步的问题也会暴露出来，沉积的业务代码也越来越多，越难维护，这也是我思考SDK架构的设计的原因及初衷了，能不能用一个通用SDK的架构来统一化处理这些问题？
好了，这个问题，我也有了自己的答案，希望与各位看官分享。
架构设计图
废话不多说，反手就是一张架构设计图 (图丑，各位看官莫吐槽哈。)
SDK架构设计.png
我这图跟常规的设计不太一样哈，参考的是Android系统架构的设计，通俗易懂，当然了，也说明了我的水平局限性了。
架构设计分析
回归正题，这个架构设计跟大家平常看到的MVC、MVP、MMVP等常见的架构设计是不太一样的，但是是基于传统的MVC模式来思考设计的。下面我会详细跟大家说说设计的思路。
第一部分：架构的分层设计：
架构设计的初体验
在这里我就不多说什么是MVC架构了，网上相关的博客也比较多。下面大家先看下下面这张图：
SDK架构设计— MVC分层.png
在这张图里面将MVC的模块用框框进行了划分分类，方便大家理解。
Model层：
数据来源model，在游戏SDK里面，数据的来源更多的基于第三方的，可以分为两类：
1、ChannelModel：渠道SDKModel，各个渠道的功能接口，如登录、支付、社区、浮窗等；
2、FunctionPluginModel：功能插件Model，如微信的登录、支付、分享；Google的登录、支付；Bugly日志收集等；
View层：
视图层，在游戏SDK里面，更多的讲对外的API接口，这里的视图就相对弱化些，我这里勉强将它归纳为View层。而且这里要注意的就是接口设计问题，接口如果设计对外输出后，就千万尽量不要修改。
Controller层：
控制层，在游戏SDK里面，会有很多的业务常见，需要我们开发人员做好需求的开关控制和逻辑控制，在这里大体分为两类：
1、业务逻辑控制层：将相关的业务逻辑处理在该层处理，不同的Project有不同的业务逻辑，额外说明下，project就是项目，如国内SDK项目，海外SDK项目，聚合SDK项目等。
2、功能逻辑控制层：功能逻辑层，主要是面对Project服务的，将具体的功能实现，对project暴露逻辑接口，方便project对功能逻辑的调用及控制。具体实现project不需要关心。
架构设计的业务详解
上面跟大家分析了下，架构设计的大体模块划分，下面从业务的逻辑分析下，SDK架构的业务实现。请看下图：
SDK架构设计—业务场景设计.png
在这张图里，也用框框进行的逻辑划分，大体分为四层：
API功能接口层：
该层是对外提供接口，面向游戏开发者的，提供SDK的功能接口，如常见的初始化、登录、支付、绑定、订阅、数据上报、显示浮窗、隐藏浮窗、退出等。这里的接口设计需要注意的地方就是，对外的接口一旦对外提供，就尽量不要修改(这个坑，我踩过 -.- ~~)，且该层的代码不要混淆处理，所以在该层的代码不要做逻辑实现，避免被篡改。
业务逻辑层：
该层是SDK对接API层的，是不同project项目的实现层，在这里通过project配置文件来配置不同的项目。API层持有Project的引用，通过配置，选择不同的项目project实现。如：Project有多个项目：聚合SDKProject、公版SDKProject、海外SDKProject等，多个项目时，每个项目都有不同的业务逻辑，不同的功能实现，对游戏的API接口是不变的，这时就可以通过配置来切换不同的Project，在不改变接口的情况实现换SDK包的功能。
注意：该层还有一个额外的Channel层，该层是三方渠道层，更多是针对聚合SDK项目的业务。也是通过channel配置文件来配置不同的channel入口的。
功能逻辑层：
该层是SDK的功能实现层，是SDK的核心层，对接Project层的，为不同的Project项目提供功能接口。这里采用组件化的思想，细分为各个功能组件，每个组件之间是相互独立的，方便后续业务量大之后将组件抽离处理，单独做成一个独立的项目。如登录SDK、支付SDK等。
注意：这里的功能不做任何的业务逻辑，只做功能实现，业务逻辑放到project层处理，通常与服务的交互也会在这层处理。这里会有一个三方的plugin层，主要是封装三方的功能插件，通过配置提供给Logic对应的功能，如微信插件，有登录、支付等。
PS：这个的配置文件的实现原理是通过反射实现的。还有说明下，这么处理的好处是，后续的游戏打包可以通过选择不同的Project、channel、plugin来快速打项目包、渠道包、及功能包。（打包篇细讲）
基础库
该层是整个SDK的基础，封装通用的基础功能，网络库、数据解析、日志输出、IO流、文件加解密等。这里的基础库，会封装一些流行的框架，需要注意的是，流行的框架几年会有被淘汰的风险，所以尽量做封装处理，不然替换一个框架，上层的SDK都需要修改。
PS：基础库的话，建议分为业务基础库和框架基础库、UI基础库，方便后续的隔离和替换。避免后续基础库越来越臃肿。而且基础库不要轻易修改，不要轻易修改。切记!
总结
由于最近项目比较赶，这个系列的博客有点耽搁了。而且由于商业机密，项目的代码也不能开源出来，后续我会做一个精简版的项目框架给各位分享，也方便理解。敬请期待下一篇（第二部分：架构的代码实现）...
网友评论