手游海外SDK开发实战——开发原则

一、前言

随着国内手游版号申请难度的增加，以及防沉迷等一系列政策的影响，很多国内开发者纷纷开始寻求海外发行之路。那么手游出海首要的是需要一套适合海外发行和运营的手游SDK联运系统。

本系列我们就来开发一套这样的SDK，我们暂且称这套SDK为UGSDK。

整个UGSDK项目，暂时可以分为三大部分——Android客户端SDK部分、iOS客户端SDK部分以及服务端部分（目前不考虑H5游戏部分）。

本篇主要介绍UGSDK项目技术选型以及开发过程中遵循的一些开发原则。

一、Android客户端

1、技术选型和基础开发原则

• 根据目前游戏引擎主流环境，SDK项目采用java语言开发，不使用kotlin。采用open jdk 1.8。
• 项目根据不同业务功能，尽可能地采用多模块组织，但是不要过分细化模块。
• 整个项目采用主流MVC架构，但是也不要为了使用该架构而写入很多不必要的代码和逻辑，以“简单、合理、合适”为基本架构宗旨。
• 对游戏层设计的api调用接口尽可能地简单。因为该SDK开发之后，将会被不同的游戏去接入，不同的游戏有不同技术水平的开发者，简单的api调用，将极大方便和加快游戏研发的对接。
• 界面UI采用fragment开发，每个业务流程，采用单个activity。流程的控制，在activity中处理。UI界面的跳转，需要有统一的进入和弹出过渡效果。
• 所有资源的读取，采用统一的辅助类ResourceUtils读取，不要直接使用R.xxx.xxx的形式。
• 所有资源文件和资源文件中唯一id的命名，全部以ug_开头。

2、其他原则

• 为了减少和不同游戏之间的冲突，尽可能少的使用第三方框架，基础轮子尽可能自己封装。
• 插件设计需要遵循动态可插拔可替换原则，防止后续增加和替换同类的插件，以及出现和游戏方插件冲突时，可以快速替换或者去除插件。
• 模块的封装尽可能纯粹，不要将多个不同的api调用暴露给外部。
• 复杂业务代码的注释要竟可能的详细。
• 尽可能地将配置参数放到服务端，从服务端读取。
• 尽可能将需要游戏层设置的参数配置，放到统一的位置或者文件中。

二、iOS客户端

1、技术选型和基础开发原则

• 根据目前游戏引擎主流环境，SDK项目采用objective-c语言开发，不使用swift。
• 项目工程依赖采用CocoaPods创建和管理依赖。
• 整个项目采用主流MVC架构，但是也不要为了使用该架构而写入很多不必要的代码和逻辑，以“简单、合理、合适”为基本架构宗旨。
• 对游戏层设计的api调用接口尽可能地简单。因为该SDK开发之后，将会被不同的游戏去接入，不同的游戏有不同技术水平的开发者，简单的api调用，将极大方便和加快游戏研发的对接。
• 界面UI采用代码开发，不使用storyboard。 UI流程的控制，在controller中处理。UI界面的跳转，需要有统一的进入和弹出过渡效果。
• 所有资源文件全部以ug_开头。
• 所有目录、类名、方法和变量的命名，都以UG_或者ug_开够，方便后期如果需要出马甲SDK时，便于全局混淆和替换。

2、其他原则

• 为了减少和不同游戏之间的冲突，尽可能少的使用第三方框架，基础轮子尽可能自己封装。如果需要使用开发的第三方库，可以做改名处理。
• 插件设计需要遵循动态可插拔可替换原则，防止后续增加和替换同类的插件，以及出现和游戏方插件冲突时，可以快速替换或者去除插件。
• 模块的封装尽可能纯粹，不要将多个不同的api调用暴露给外部。
• 复杂业务代码的注释要竟可能的详细。
• 尽可能地将配置参数放到服务端，从服务端读取。
• 尽可能将需要游戏层设置的参数配置，放到统一的位置或者文件中。

三、服务端

1、技术选型和基础开发原则

• 服务端采用java开发(open jdk 1.8)，采用SpringBoot+Mybatis框架(使用开发时最新的稳定版)。
• 数据库采用mysql(5.6+，数据库编码使用utfmb4)， 缓存服务采用Redis(3.0+)。
• 后台管理系统等有UI界面的控制台系统，全部采用vue+element前后端分离方式开发。
• 服务端主体分为四个部分——Server、Manager、批处理作业和监控。Server主要处理和客户端部分的协议和业务核心逻辑，采用Spring Restful Api形式提供服务；Manager主要处理后台管理系统的逻辑；批处理作业主要用于定时任务和数据统计部分的业务，基于Quartz开发可视化批处理作业的管理和调度中心；监控主要用于其他几个程序服务的监控和告警，目前采用SpringBootAdmin。
• 核心业务和批处理业务需要支持集群部署。
• 业务中像用户和订单等数据的唯一ID均采用分布式唯一ID，使用改良的雪花算法生成。
• 项目根据不同业务功能，尽可能地采用多模块组织，将需要被不同模块依赖的功能独立成单独的模块。
• 整个项目采用主流MVC架构，业务逻辑尽可能写在service层，不要写在controller里面。

2、其他原则

• 项目模块的依赖管理统一使用gradle，不适用maven。
• 所有API协议采用统一的sign签名校验规则。
• 所有模块服务需要增加容器化部署支持，比如Docker，为各个模块编写对应的Dockerfile。
• 模块的编译需要使用gradle task，尽可能减少手动操作。
• 复杂业务代码的注释要竟可能的详细。
• 模块的项目配置文件，需要区分部署环境，比如dev, prod等。
• 统一的日志输出规范。

可见，SDK项目看起来功能虽然不多，但是想要开发的好，后期可维护性高，可扩展性强，还是需要花很多心思并做很多功课的。