CN108465236B - 一种游戏手柄及其对手机的控制方法 - Google Patents

Abstract

本发明公开了一种游戏手柄，包括与手机匹配的夹持部，还包括安装在夹持部与手机顶边或底边其中一个匹配的侧面的控制部，所述控制部正面设置有方向舵和控制按键中的至少一种，控制部通过设置在控制部内部的通信模块与手机匹配。采用上述结构的游戏手柄，使用者可以一只手通过控制部对手柄进行控制，而由于上述手柄只在手机的一边设置有控制部，因此，使用者的另一只手可以方便的握持手机，对手机的触摸屏进行控制，解决由于现有的游戏手柄接入手机后，使用者就无法再通过触摸屏对手机进行控制，在一些游戏上，手柄还无法完全替代触摸屏的功能，因此***手柄难以普及的问题。

Description

一种游戏手柄及其对手机的控制方法

技术领域

本发明涉及一种手机控制器，具体涉及一种游戏手柄。

背景技术

手柄是一种电子游戏机的输入设备，通过操纵其按钮等，可以实现对电脑上模拟角色等的控制。家用游戏机式的手柄设计，左侧为方向键、右侧有4～6个功能键，根据需要还可能在别的部位加入更多的功能键，实现不同的功能。采用手柄比较适于进行模拟器类游戏，特别是一些滚屏类游戏。几乎所有家用游戏机都使用手柄进行操作。Wii主机采取了新式的操纵杆，但也支持GameCube风格的手柄操作。手柄也常用于电脑模拟器、电脑上的赛车等类型游戏。手柄在英文中有Gamepad和Joystick两个词，区别在于Gamepad是手握的，Joystick是平放在桌上。

现在市面上纯粹的游戏机已经很少了，大部分人一般通过手机进行游戏，因此，***手柄必不可少，而由于现有的游戏手柄接入手机后，使用者就无法再通过触摸屏对手机进行控制，在一些游戏上，手柄还无法完全替代触摸屏的功能，因此***手柄难以普及。

发明内容

本发明所要解决的技术问题是现在市面上纯粹的游戏机已经很少了，大部分人一般通过手机进行游戏，因此，***手柄必不可少，而由于现有的游戏手柄接入手机后，使用者就无法再通过触摸屏对手机进行控制，在一些游戏上，手柄还无法完全替代触摸屏的功能，因此***手柄难以普及，目的在于提供一种游戏手柄，解决现在市面上纯粹的游戏机已经很少了，大部分人一般通过手机进行游戏，因此，***手柄必不可少，而由于现有的游戏手柄接入手机后，使用者就无法再通过触摸屏对手机进行控制，在一些游戏上，手柄还无法完全替代触摸屏的功能，因此***手柄难以普及的问题。

本发明通过下述技术方案实现：

一种游戏手柄，包括与手机匹配的夹持部，还包括安装在夹持部与手机顶边或底边其中一个匹配的侧面的控制部，所述控制部正面设置有方向舵和控制按键中的至少一种，控制部通过设置在控制部内部的通信模块与手机匹配。采用上述结构的游戏手柄，使用者可以一只手通过控制部对手柄进行控制，而由于上述手柄只在手机的一边设置有控制部，因此，使用者的另一只手可以方便的握持手机，对手机的触摸屏进行控制，解决现在市面上纯粹的游戏机已经很少了，大部分人一般通过手机进行游戏，因此，***手柄必不可少，而由于现有的游戏手柄接入手机后，使用者就无法再通过触摸屏对手机进行控制，在一些游戏上，手柄还无法完全替代触摸屏的功能，因此***手柄难以普及的问题。

控制部外壳上还设置有与设置在控制部内部的锂电池匹配的充电接口。由于手柄本身也具有包括通信模块的各种电路模块，因此通过在手柄控制部的外壳内设置锂电池的方法，可以使手柄自己为自己供电而不依赖手机，增加手柄和手机的续航时间，甚至还可以作为应急的移动电源为手机充电。

所述夹持部为与手机外形匹配的带有背板的矩形外框，在外框内部与手机充电口对应的位置还设置有插接头。由于上述结构的外框本身对手机的固定效果较差，因此，在外框上设置插接头既可以加固手机与手柄之间的连接，还可以建立手机与手柄之间的物理通信。

所述夹持部包括一个控制部的一个侧边和一个挡板，所述控制部的一个侧边和挡板之间通过可伸缩的背板连接。所述可伸缩的背板包括至少两块背板和相邻背板之间设置的伸缩板，所述伸缩板通过稳定状态处于拉伸状态的弹性结构与背板连接。所述背板在没有手机放入时处于收缩状态，当需要放入手机时，背板在外力的作用下伸长，然后将手机置入控制部的一个侧边和挡板之间，伸长状态的背板向收缩方向将手机压紧。

所述夹持部与手机接触的地方均设置有缓冲材料，所述手柄上的棱角均打磨为圆角。由于手柄在使用时由操作人员徒手操作，因此，进行上述处理有助于提升使用者的手感，同时减小手柄对手机的磨损。

游戏手柄对手机的控制方法，包括以下步骤：

A、通过手柄的通信模块建立手柄与手机之间的连接；

B、通过手柄的控制部采集使用者输入的手柄控制信号；接收手机触摸屏采集的触摸屏控制信号；

C、通过手柄中的处理器将步骤B中采集的手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号，将手机控制信号通过通信模块发送到手机。

所述步骤A中手柄的通信模块通过蓝牙与手机建立连接。用蓝牙与手机连接可以适配市面上的大多数手机。

所述步骤C中将手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号的方法包括针对Android***的以下步骤：

CA1、拦截游戏app内的input消息分发链，拦截所有InputEvent；

CA2、判断InputEvent是***发送的原始input事件，还是经过我们程序处理过的input事件，如果是***发送的原始input，就处理冲突；如果是处理过的input事件，就放行派发给游戏。Android使用MotionEvent来表示触屏操作，其成员finger id标示是哪个手指。当手柄模拟触屏产生的MotionEvent和真实触屏的MotionEvent中finger id值有重叠时就会导致冲突。所以，只要将***的finger id与手柄模拟操作的finger统一管理，即可解决冲突。

所述步骤CA1中拦截所有InputEvent包括两个拦截点共同协作来实现拦截：

CA101、拦截普通activity的输入事件：在activity创建回调中，使用activity.getWindow().setCallback替换java层activity.window的Window.Callback；

CA102、拦截NativeActivity的输入事件：c++层Hook JNI函数：

InputQueue.nativeSendKeyEvent；

InputQueue.nativeSendMotionEvent。

Android使用ART运行时之后，JAVA层不能很好的实现HOOK Method，没有办法拦截函数调用，截获Input消息并不好实现。由于我们不能修改游戏的代码，就需要在androidInputEvent派发链上精心寻找满足条件的拦截点：

1、时机足够早，必须在游戏activity处理之前拦截；

2、游戏可能使用NativeActivity，必须要能拦截这种情况；

3、拦截点必须可过滤(截断)InputEvent；

4、拦截点必须稳定(android碎片化严重)；

如果是java层拦截，那么拦截点必须是Java reflection就可处理的情况；如果是c++层拦截，那么拦截点必须在各个版本的android代码中一致。经过仔细分析，最终选定两个拦截点共同协作来实现拦截。

所述步骤CA2中判断InputEvent是***发送的原始input事件，还是经过我们程序处理过的input事件的方法包括以下步骤：

CA201、通过InputEvent中的InputEvent.getSource()获取自定义Mask；

CA202、根据Mask判断是否是原始消息；若是，进入CA203步骤，若不是，进入步骤CA204；

CA203、依次进行：映射finger id处理冲突；映射手柄触屏映射转换消息；为setSource添加Mask；将处理生成的新的event放入处理队列；

CA204、删除自定义Mask后放行，让***继续派发。

所述步骤C中将手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号的方法包括针对IOS***的以下步骤：

CI1、hook掉UIApplication的sendEvent函数；

CI2、修改之前模拟触屏方式，不清空所有的touches，只清空模拟的部分的touches。

IOS使用UIEvent来管理一系列事件如HID、触控等，使用UITouch对象来跟踪一个手指的完整触控操作行为。对应到多点触屏操作，那么UIEvent中就包含N个UITouch对象，每个UITouch对象表示一个手指的操作，他包含按下、弹起、移动、压力等一列事件。当这些事件更新时，UIView就会收到对应UITouch的更新回调。对应的事件回调方法有：UIView.touchesBegan(touches,event)、UIView.touchesMoved(touches,event)、UIView.touchesEnded(touches,event)、UIView.touchesCancelled(touches,event)；其中，touches代表所有触控。如果手指1，2同时按下，那么这里touches就包含1，2两个UITouch对象；如果先按1再按2，这个方法就会被调用两次，先收到1，再收到2。event代表UIEvent对象。Cocos2d等大部分游戏引擎直接处理touches增量更新数据，然后将每个touch对象映射为finger id，所以可以同时获取***管理的touches和手柄模拟的touches对象，不会冲突。而查U3D文档与逆向分析得知，U3D直接使用UIEvent.allTouches()来将event中的所有触控映射到U3DEngine.Input类，他没有使用的增量信息来映射触控。我们在注入模拟touches事件时，清空了***管理的touches事件，这样手柄send给游戏app的event中只包含模拟的触控touches，而***发给游戏app的只包含手动操作的touches。因此U3D从event中获取所有touches时，就要么只能得到手柄的操作，要么只能得到手指的真实触控操作，从而引起冲突。

之前使用的模拟操作触控屏的方法：

由于UIEvent细节太多，无法自由创建，所以手柄使用UIApplication成员变量_touchesEvent(类型兼容UIEvent)来发送模拟产生的touches触控操作。

参数：touches模拟的触控操作

1、UIEvent*event＝[[UIApplication sharedApplication]_touchesEvent]；//获取UIEvent；

2、[event_clearTouches]；//清空event中管理的所有touches事件；

3、为event构建touches对应的细节数据；

4、循环将touches添加到event中：

for(UITouch*aTouch in touches){

[event_addTouch:aTouch forDelayedDelivery:NO]；

}；

5、[[UIApplication sharedApplication]sendEvent:event]；//发送事件让游戏处理；

本方法通过接管消息分发，将***管理的touches和手柄程序管理的touches都添加到UIEvent中，让U3D可以拿到全部的touches对象；具体的：

1、hook掉UIApplication的sendEvent函数，此函数为消息app消息分发链的起点app:sendEvent-->window:sendEvent-->View/Ctrl；

2、修改之前模拟触屏方式的第二步，不要清空所有的touches，只清空模拟的部分。

本发明与现有技术相比，具有如下的优点和有益效果：

1、本发明一种游戏手柄，使操作者可以同时通过手柄和触摸屏对手机进行控制；

2、本发明一种游戏手柄，结构简单，使用时舒适度高，不易磨损手机，便于普及；

3、本发明一种游戏手柄，能与市面上大部分手机进行匹配。

附图说明

此处所说明的附图用来提供对本发明实施例的进一步理解，构成本申请的一部分，并不构成对本发明实施例的限定。在附图中：

图1为本发明结构示意图；

图2为本发明结构示意图；

图3为本发明应用于Android***流程示意图；

图4为本发明应用于IOS***流程示意图。

附图中标记及对应的零部件名称：

1-外框，101-插接头，2-控制部，201-方向舵，202-控制按键，203-***按键，3-充电接口，4-背板，5-挡板，6-伸缩板，7-支撑座。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明作进一步的详细说明，本发明的示意性实施方式及其说明仅用于解释本发明，并不作为对本发明的限定。

实施例1

如图1所示，本发明一种游戏手柄，包括与手机匹配的夹持部，还包括安装在夹持部与手机顶边或底边其中一个匹配的侧面的控制部2，所述控制部2正面设置有方向舵201、控制按键202和***按键203，控制部2通过设置在控制部2内部的蓝牙通信模块与手机匹配。采用上述结构的游戏手柄，使用者可以一只手通过控制部2对手柄进行控制，而由于上述手柄只在手机的一边设置有控制部2，因此，使用者的另一只手可以方便的握持手机，对手机的触摸屏进行控制，解决现在市面上纯粹的游戏机已经很少了，大部分人一般通过手机进行游戏，因此，***手柄必不可少，而由于现有的游戏手柄接入手机后，使用者就无法再通过触摸屏对手机进行控制，在一些游戏上，手柄还无法完全替代触摸屏的功能，因此***手柄难以普及的问题。

控制部2外壳上还设置有与设置在控制部2内部的锂电池匹配的充电接口3。由于手柄本身也具有包括通信模块的各种电路模块，因此通过在手柄控制部2的外壳内设置锂电池的方法，可以使手柄自己为自己供电而不依赖手机，增加手柄和手机的续航时间，甚至还可以作为应急的移动电源为手机充电。

实施例2

如图2所示，本实施例与实施例1的区别在于，所述夹持部为与手机外形匹配的带有背板的矩形外框1，在外框1内部与手机充电口对应的位置还设置有插接头101。由于上述结构的外框1本身对手机的固定效果较差，因此，在外框1上设置插接头101既可以加固手机与手柄之间的连接，还可以建立手机与手柄之间的物理通信。

所述夹持部包括一个控制部2的一个侧边和一个挡板5，所述控制部2的一个侧边和挡板5之间通过可伸缩的背板4连接。所述可伸缩的背板4包括至少两块背板4和相邻背板4之间设置的伸缩板6，所述伸缩板6通过稳定状态处于拉伸状态的弹性结构与背板4连接。所述背板4在没有手机放入时处于收缩状态，当需要放入手机时，背板4在外力的作用下伸长，然后将手机置入控制部2的一个侧边和挡板5之间，伸长状态的背板4向收缩方向将手机压紧。

所述夹持部与手机接触的地方均设置有缓冲材料，所述手柄上的棱角均打磨为圆角。由于手柄在使用时由操作人员徒手操作，因此，进行上述处理有助于提升使用者的手感，同时减小手柄对手机的磨损。

实施例3

如图3、4所示，本实施例与实施例2的区别在于，所述控制部2和挡板5的底部还设置有与手机匹配的支撑座7，由于手机是被伸长状态的背板4压在控制部2的一个侧边和挡板5之间的，当压力不足时容易下滑，因此设置支撑座7避免手机下滑。

实施例4

基于实施例1的游戏手柄对手机的控制方法，包括以下步骤：

A、通过手柄的通信模块建立手柄与手机之间的连接；

B、通过手柄的控制部采集使用者输入的手柄控制信号；接收手机触摸屏采集的触摸屏控制信号；

C、通过手柄中的处理器将步骤B中采集的手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号，将手机控制信号通过通信模块发送到手机。

所述步骤A中手柄的通信模块通过蓝牙与手机建立连接。用蓝牙与手机连接可以适配市面上的大多数手机。

所述步骤C中将手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号的方法包括针对Android***的以下步骤：

CA1、拦截游戏app内的input消息分发链，拦截所有InputEvent；

CA2、判断InputEvent是***发送的原始input事件，还是经过我们程序处理过的input事件，如果是***发送的原始input，就处理冲突；如果是处理过的input事件，就放行派发给游戏。Android使用MotionEvent来表示触屏操作，其成员finger id标示是哪个手指。当手柄模拟触屏产生的MotionEvent和真实触屏的MotionEvent中finger id值有重叠时就会导致冲突。所以，只要将***的finger id与手柄模拟操作的finger统一管理，即可解决冲突。

所述步骤CA1中拦截所有InputEvent包括两个拦截点共同协作来实现拦截：

CA101、拦截普通activity的输入事件：在activity创建回调中，使用activity.getWindow().setCallback替换java层activity.window的Window.Callback；

CA102、拦截NativeActivity的输入事件：c++层Hook JNI函数：

InputQueue.nativeSendKeyEvent；

InputQueue.nativeSendMotionEvent。

Android使用ART运行时之后，JAVA层不能很好的实现HOOK Method，没有办法拦截函数调用，截获Input消息并不好实现。由于我们不能修改游戏的代码，就需要在androidInputEvent派发链上精心寻找满足条件的拦截点：

1、时机足够早，必须在游戏activity处理之前拦截；

2、游戏可能使用NativeActivity，必须要能拦截这种情况；

3、拦截点必须可过滤(截断)InputEvent；

4、拦截点必须稳定(android碎片化严重)；

如果是java层拦截，那么拦截点必须是Java reflection就可处理的情况；如果是c++层拦截，那么拦截点必须在各个版本的android代码中一致。经过仔细分析，最终选定两个拦截点共同协作来实现拦截。

所述步骤CA2中判断InputEvent是***发送的原始input事件，还是经过我们程序处理过的input事件的方法包括以下步骤：

CA201、通过InputEvent中的InputEvent.getSource()获取自定义Mask；

CA202、根据Mask判断是否是原始消息；若是，进入CA203步骤，若不是，进入步骤CA204；

CA203、依次进行：映射finger id处理冲突；映射手柄触屏映射转换消息；为setSource添加Mask；将处理生成的新的event放入处理队列；

CA204、删除自定义Mask后放行，让***继续派发。

所述步骤C中将手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号的方法包括针对IOS***的以下步骤：

CI1、hook掉UIApplication的sendEvent函数；

CI2、修改之前模拟触屏方式，不清空所有的touches，只清空模拟的部分的touches。

IOS使用UIEvent来管理一系列事件如HID、触控等，使用UITouch对象来跟踪一个手指的完整触控操作行为。对应到多点触屏操作，那么UIEvent中就包含N个UITouch对象，每个UITouch对象表示一个手指的操作，他包含按下、弹起、移动、压力等一列事件。当这些事件更新时，UIView就会收到对应UITouch的更新回调。对应的事件回调方法有：UIView.touchesBegan(touches,event)、UIView.touchesMoved(touches,event)、UIView.touchesEnded(touches,event)、UIView.touchesCancelled(touches,event)；其中，touches代表所有触控。如果手指1，2同时按下，那么这里touches就包含1，2两个UITouch对象；如果先按1再按2，这个方法就会被调用两次，先收到1，再收到2。event代表UIEvent对象。Cocos2d等大部分游戏引擎直接处理touches增量更新数据，然后将每个touch对象映射为finger id，所以可以同时获取***管理的touches和手柄模拟的touches对象，不会冲突。而查U3D文档与逆向分析得知，U3D直接使用UIEvent.allTouches()来将event中的所有触控映射到U3DEngine.Input类，他没有使用的增量信息来映射触控。我们在注入模拟touches事件时，清空了***管理的touches事件，这样手柄send给游戏app的event中只包含模拟的触控touches，而***发给游戏app的只包含手动操作的touches。因此U3D从event中获取所有touches时，就要么只能得到手柄的操作，要么只能得到手指的真实触控操作，从而引起冲突。

之前使用的模拟操作触控屏的方法：

由于UIEvent细节太多，无法自由创建，所以手柄使用UIApplication成员变量_touchesEvent(类型兼容UIEvent)来发送模拟产生的touches触控操作。

参数：touches模拟的触控操作

1、UIEvent*event＝[[UIApplication sharedApplication]_touchesEvent]；//获取UIEvent；

2、[event_clearTouches]；//清空event中管理的所有touches事件；

3、为event构建touches对应的细节数据；

4、循环将touches添加到event中：

for(UITouch*aTouch in touches){

[event_addTouch:aTouch forDelayedDelivery:NO]；

}；

5、[[UIApplication sharedApplication]sendEvent:event]；//发送事件让游戏处理；

本方法通过接管消息分发，将***管理的touches和手柄程序管理的touches都添加到UIEvent中，让U3D可以拿到全部的touches对象；具体的：

1、hook掉UIApplication的sendEvent函数，此函数为消息app消息分发链的起点app:sendEvent-->window:sendEvent-->View/Ctrl；

2、修改之前模拟触屏方式的第二步，不要清空所有的touches，只清空模拟的部分。以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种游戏手柄，包括与手机匹配的夹持部，其特征在于，还包括安装在夹持部与手机顶边或底边其中一个匹配的侧面的控制部(2)，所述控制部(2)正面设置有方向舵(201)和控制按键(202)中的至少一种，控制部(2)通过设置在控制部(2)内部的通信模块与手机匹配；

所述游戏手柄通过所述通信模块建立与手机之间的连接；通过所述控制部采集使用者输入的手柄控制信号；接收手机触摸屏采集的触摸屏 控制信号；通过处理器将采集的手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号，将手机控制信号通过通信模块发送到手机。

2.根据权利要求1所述的一种游戏手柄，其特征在于，控制部(2)外壳上还设置有与设置在控制部(2)内部的锂电池匹配的充电接口(3)。

3.根据权利要求1所述的一种游戏手柄，其特征在于，所述夹持部为与手机外形匹配的带有背板的矩形外框(1)，在外框(1)内部与手机充电口对应的位置还设置有插接头(101)。

4.根据权利要求1所述的一种游戏手柄，其特征在于，所述夹持部包括一个控制部(2)的一个侧边和一个挡板(5)，所述控制部(2)的一个侧边和挡板(5)之间通过可伸缩的背板(4)连接。

5.根据权利要求4所述的一种游戏手柄，其特征在于，所述可伸缩的背板(4)包括至少两块背板(4)和相邻背板(4)之间设置的伸缩板(6)，所述伸缩板(6)通过稳定状态处于拉伸状态的弹性结构与背板(4)连接。

6.根据权利要求1至5中任意一条所述的一种游戏手柄，其特征在于，所述夹持部与手机接触的地方均设置有缓冲材料，所述手柄上的棱角均打磨为圆角。

7.根据权利要求1至5中任意一条所述的游戏手柄对手机的控制方法，其特征在于，包括以下步骤：

A、通过手柄的通信模块建立手柄与手机之间的连接；

B、通过手柄的控制部采集使用者输入的手柄控制信号；接收手机触摸屏采集的触摸屏控制信号；

C、通过手柄中的处理器将步骤B中采集的手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号，将手机控制信号通过通信模块发送到手机。

8.根据权利要求7所述的游戏手柄对手机的控制方法，其特征在于，所述步骤A中手柄的通信模块通过蓝牙与手机建立连接。

9.根据权利要求7所述的游戏手柄对手机的控制方法，其特征在于，所述步骤C中将手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号的方法包括针对Android***的以下步骤：

CA1、拦截游戏app内的input消息分发链，拦截所有InputEvent；

CA2、判断InputEvent是***发送的原始input事件，还是经过程序处理过的input 事件，如果是***发送的原始input，就处理冲突；如果是处理过的input事件，就放行派发 给游戏。

10.根据权利要求9所述的游戏手柄对手机的控制方法，其特征在于，所述步骤CA1中拦截所有InputEvent包括两个拦截点共同协作来实现拦截：

CA101、拦截普通activity的输入事件：在activity创建回调中，使用activity.getWindow().setCallback替换java层activity.window的Window.Callback；

CA102、拦截NativeActivity的输入事件：c++层Hook JNI函数：

InputQueue.nativeSendKeyEvent；

InputQueue.nativeSendMotionEvent。

11.根据权利要求9所述的游戏手柄对手机的控制方法，其特征在于，所述步骤CA2中判断InputEvent是***发送的原始input事件，还是经过程序处理过的input事件的方法 包括以下步骤：

CA201、通过InputEvent中的InputEvent.getSource()获取自定义Mask；

CA202、根据Mask判断是否是原始消息；若是，进入CA203步骤，若不是，进入步骤CA204；

CA203、依次进行：映射finger id处理冲突；映射手柄触屏映射转换消息；为setSource添加Mask；将处理生成的新的event放入处理队列；

CA204、删除自定义Mask后放行，让***继续派发。

12.根据权利要求7所述的游戏手柄对手机的控制方法，其特征在于，所述步骤C中将手柄控制信号和触摸屏控制信号进行混合生成新的手机控制信号的方法包括针对IOS***的以下步骤：

CI1、hook掉UIApplication的sendEvent函数；

CI2、修改之前模拟触屏方式，不清空所有的touches，只清空模拟的部分的touches。

Images