手游SDK — 第九篇（浅谈适配H5游戏）

Hi，各位老铁，又见面了。之前的文章大多是介绍手游SDK的，但是2016年开始，H5游戏就陆陆续续的走进了大家的视野之内，到了2018年，H5游戏走向了爆发，很多游戏CP也开始出品自己自己的H5游戏。所以，咱们这边文章就聊聊SDK如何适配H5游戏。

H5游戏的形态

大家都知道H5游戏是纯前端代码编写的，H5游戏开发周期相对较短，灵活性较强。玩家也可以即玩即走，通常的入口都是类似微信游戏中心，QQ空间，视频广告等方式引导玩家去玩。像这种形态的游戏，作为客户端开发咱们就不需要过多的关注这个。

但是，据数据显示呢(实际上就是我跟项目组的技术聊天吹牛的)，这种形态方式的玩家付费率不是很高。而微端的付费率相对更高些，微端简单来说就是将H5游戏打包成app给玩家下载玩，这种包体，小的只有几百K，大的也就几十M的样子，玩家下载的意愿也相对高，手机是直接玩，直接拉起支付付费，付费率也高些。

H5游戏微端

既然是打包成apk，咱们Android开发的活就来了，通常的做法是：一种是纯H5游戏的展示，Android直接用webview加载url即可，渠道的登录支付全部是Js的调用；还有另一种是：H5和Android混合调用，通常是登录和支付等常用接口都是调用原生的。下面咱们就来聊聊技术方案。

纯H5交互

本来纯H5交互涉及到Android客户端的开发量不是很大，直接用webView加载游戏的入口url就可以了。但是在实际的应用中，会发现一个非常致命的痛点问题：url每次加载游戏的资源都需要耗费流量，想想当玩家玩你的游戏的时候，耗费流量非常多，你是不是想卸载了。所以这里就会涉及到一个资源缓存的问题。

下面给大家推荐一个缓存WebView的库：CacheWebView
如果没有特殊需求的话，这个缓存库就很符合当前的需求了。如果要兼容腾讯的X5内核的话，也可以看看这位老铁的踩坑实践：Android-X5WebView封装（Cookie管理、进度监听、适配8.1系统等策略）

不过我在CacheWebView的基础上做了二次开发，游戏的cdn会根据游戏来变，根据需求多添加了个磁盘缓存，(实际上Okhttp已经有了DisLruCache，但是不满足需求，所以自己优化了下并做了进一步封装)

可以给大家看下效果图，有需要的话，可以私聊我要源码，我就不开源了。

image.png

H5与Android混合调用

来重点了哈，为什么说是重点呢，因为要跟原生做交互了，之前设计的聚合SDK就可以用了呀，打包系统也可以用了。

技术方案分析：

在现有的游戏行业里面，H5游戏算是异军突起的新潮流，在原有的行业做法都是打手游的SDK渠道打法，所以H5要发微端的话，上渠道打法也是渠道SDK，但是不是所有的渠道都有对应的H5SDK，但是基本是所有的渠道都有客户端的SDK，所以走微端的话，聚合SDK和打包系统是最方便的方案，H5游戏和手机游戏都可以适用同一套。

技术实现方案：

1、技术沉淀的SDK基础上：聚合SDK和缓存库SDK，只需要在现有的基础上做一层与JS交互的封装就可以了。要么把这两个SDK直接给游戏项目组自己做交互，要么我们自己做封装要求项目组前端按定义好的字段来做具体交互。

但是在实际操作中会发现，第一种方式：项目组没有专业的Android开发，写的代码有点忧伤.... 第二种方式：将所有的交互接口定义好之后，后续拓展不太好，而且还得跟项目组的人对接，当对接多个项目组或者CP的时候，排期啊，接口数据问题也会出来了。

2、有没有更好的方式呢？答案是肯定的。SDK出一套H5聚合SDK接口，所有的交互逻辑及缓存逻辑都在SDK内部完成，H5游戏只需要对接对应的H5SDK接口就可以了。因为涉及到与JS交互这块，我就不细讲了，大家可以自己完成。

结语

祝大家生活愉快。

如果觉得我的文章对你有帮助，请随意赞赏。您的支持将鼓励我继续创作！