大纲
1.云游戏概念
2.游戏流程图
3.按键下发
4.按键自定义
5.sdk接口
6.鼠标模式
7.优化和方案
8.解决的问题
9.历史
10.后续
云游戏概念
云游戏就是通过和远程服务器建立连接，服务器通过推送视频流，音频流，显示在客户端，同时客户端发送操作指令，操作远程服务器的行为。
游戏业务启动流程图
云游戏sdk初始化流程图
部分说明：本地sdk获取clientSession -> 业务服务器再获取ServerSession -> sdk.start->建立连接->获取视频流
按键下发
1.定义按键接口
2.按键下发后台
3.游戏按键设计图
按键自定义
1.目前支持自定义的按键包含: 鼠标和键盘，组合键，轮盘键, 左右键
2.按键的具体可定义属性包含: 按键增，删，改,
3.单个按键支持行为：缩放，编辑内容，删除
4.按键的点击模式：点击模式，长按模式，状态模式
自定义轮盘键技术总结
按键增删改,缩放，拖拽总结
5.按键对应的mean()
注意点：
1.按键模式的区分, 2.例如：点击模式 down的时候，先move还是先down
2.组合键：2个按键合并为一个按键
3.轮盘键（按键数量>=2&& >= 8）
4.按键数据的设计和按键功能
5.按键增删改设计
sdk接口
视频流和接口底层使用webrtc协议传输，保证传输稳定和安全，详情见:TenGameController
鼠标模式
目前支持的鼠标模式包含: 1.点击模式 2.滑动模式 3.滑动点击模式
旧版本有我们业务方自己实现，最新的纯原生sdk，已经交由腾讯sdk实现，具体参考类: GameView
屏幕双指缩放，拖拽
旧版本也是我们业务方自己实现，最新的纯原生sdk,也已经交由腾讯sdk
【双指缩放和拖拽相关技术总结:
优化和方案
1.鼠标位置如何映射
举个例子：比如后台下发分辨率为1280 * 800的视频，但是手机(横屏)是1920 * 1080，根据等比例缩放规则，
scaleX = 1920 / 1280 = 1.5
scaleY = 1080 / 800 = 1.35
scale = Math.min(scaleX, scaleY)
divide = (1920 - 1080 * scale) / 2 = 96 //那么2边留黑空隙为96
那么eventX,eventY必须处理为(1280 * 800的区间)
changeX = (eventX - divide) / scale
changeY = eventY / scale
2.提高采集速度，减少视频延迟
首先分为合采和独采，所谓合采就是把鼠标图标采集到视频，独采就是指视频流不包含鼠标。
合并的优点是鼠标带入视频，无需客户端自己绘制，缺点是采集鼠标需要消耗性能，增加视频采集时间，增加延迟，独采反之。
3.保证游戏操作的及时性和可靠性，使用kcp协议
Udb 效率高，但是可能丢包，不可靠
Tcp 可靠，面向连接，拥有流量控制和拥塞机制，但是效率低
Kcp 是一个快速可靠协议，能以比Tcg浪费10%-20%的宽带的代价，换取平均延迟降低30%-40%，且最大延迟降低3倍的传输效率，同时Kcp是纯算法协议，本身并不负责，底层的收发。
项目使用Kcp为算法协议，底层传输为Udp,利用Udp的快速传输，同时使用Kcp内部算法验证机制，保证游戏操作的快速和数据完整性。
碰到到的一些小问题
#1.鼠标滑动和按键TouchEvent事件不能同时触发
#2.双指缩放和拖拽
#3.屏幕缩放问题
#4.部分机型适配问题
1.鼠标滑动和按键TouchEvent事件不能同时触发
由于父容器和子view同时监听onTouchListener事件，导致事件被拦截。当容器间存在父子关系时候，只能由一方接管touch事件。
消费事件图
通过消费事件图，我们可以知道当子View的 setOntouchListener返回true时，View的onTouchEvent已经消费事件，上层ViewGroup将无法收到该事件，所以为了解决该问题，我们在父容器中增加触摸层和按键，2者变为兄弟关系，问题解决。
2.双指缩放和双指拖拽
走入缩放和拖拽必须2选一的误区，结果无论怎么判断都无法达到流畅的目标
相关技术总结
3.部分机型适配问题
（1.部分机型挤压问题）
1.本身空间不足
4. 缩放功能
历史
公司云游戏已经停运
后续
如果后期需要加大云游戏开发，包括手游支持，可能需要独立出游戏插件，