3. 操作系统触摸事件处理：Android、iOS、Windows 的底层逻辑
触摸偏移校准，说白了就是跟操作系统的触摸事件分发机制打交道。你校准做得再好，如果系统把触摸点传错了，一切都是白搭。我这些年做触控优化，踩得最深的坑，往往不是算法本身，而是没搞懂系统到底是怎么把手指位置传给应用的。
今天咱们就掰开揉碎了看看，三大主流系统——Android、iOS、Windows——各自是怎么处理触摸事件的。理解了这些，你才能知道校准代码该插在哪个环节。
3.1 Android 触摸事件分发机制
Android 的触摸事件分发，核心就三个方法：dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent。它们组成了一个责任链，从 Activity 一路传到最底层的 View。
核心流程：触摸事件从 Activity 开始，经过 ViewGroup 的层层拦截，最终交给目标 View 处理。如果某个环节不消费事件，它就会沿着链条往回传。
我个人习惯把 Android 的分发机制画成一张流程图，这样看更直观：
这张图里有个关键点：onInterceptTouchEvent 返回 true 时，事件就被当前 ViewGroup 截胡了，子 View 再也收不到。我曾经在项目中遇到过 ScrollView 嵌套 ViewPager 的场景，滑动冲突导致 ViewPager 翻页卡顿，最后就是在 onInterceptTouchEvent 里加了手指滑动方向的判断才解决。
避坑指南：如果你在自定义 ViewGroup 里重写了 onInterceptTouchEvent，记得在 ACTION_DOWN 时返回 false，否则后续事件都会被拦截。我曾经见过同事直接返回 true，结果所有子 View 都点不动了。
对于触摸偏移校准来说，Android 的 MotionEvent 对象里有个 getRawX() 和 getRawY()，它们返回的是屏幕绝对坐标。而 getX() 和 getY() 是相对当前 View 的坐标。校准的时候，我建议优先用 getRawX()，因为它不受 View 层级偏移的影响。
3.2 iOS 触摸事件处理流程
iOS 的触摸事件处理，核心是 UIResponder 链。从 UIApplication 开始，经过 UIWindow，再到 UIView，最后到 UIViewController。跟 Android 最大的区别是：iOS 没有拦截机制，事件只能沿着响应链往下传，直到有人处理它。
核心流程：系统通过 hitTest:withEvent: 方法找到最合适的视图，然后把 UITouch 对象交给它。如果这个视图不处理，事件就沿着响应链往上回溯。
你想想看，iOS 的 hitTest 其实是个递归过程。它会从最上层的 Window 开始，遍历所有子视图，找到触摸点所在的、最底层的那个视图。这个过程跟 Android 的 dispatchTouchEvent 有点像，但更直接——没有拦截，只有寻找。
我举个例子，假设你有一个 UIButton 被一个 UIView 盖住了。在 Android 里，你可以通过 onInterceptTouchEvent 让父 View 把事件传给 Button。但在 iOS 里，如果你不重写 hitTest，事件永远到不了 Button，因为 hitTest 默认只返回最上层的视图。
注意：iOS 的 pointInside:withEvent: 方法决定了触摸点是否在视图范围内。如果你自定义了视图形状（比如圆形按钮），必须重写这个方法，否则系统会按矩形区域判断。我做过一个圆形拨号盘，忘了重写 pointInside，结果用户点角落也能触发，体验很差。
对于触摸偏移校准，iOS 的 UITouch 对象提供了 locationInView: 和 preciseLocationInView: 方法。后者在 iPad Pro 配合 Apple Pencil 时能返回亚像素级别的坐标。如果你在做手写笔校准，一定要用 preciseLocationInView，否则精度不够。
下面这个表格对比了 Android 和 iOS 在触摸事件处理上的关键差异：
| 对比维度 | Android | iOS |
|---|---|---|
| 事件分发入口 | Activity.dispatchTouchEvent() | UIApplication.sendEvent() |
| 寻找目标视图 | 递归遍历 ViewGroup 子 View | hitTest:withEvent: 递归 |
| 拦截机制 | onInterceptTouchEvent 支持拦截 | 无拦截，只能重写 hitTest |
| 事件消费 | onTouchEvent 返回 true 表示消费 | touchesBegan: 等方法处理 |
| 坐标精度 | getRawX/getRawY 像素级 | preciseLocationInView 亚像素级 |
3.3 Windows 触摸事件处理
Windows 的触摸事件处理，跟 Android 和 iOS 都不太一样。它走的是 WM_TOUCH 消息机制。当用户触摸屏幕时，系统会生成一条 WM_TOUCH 消息，包含触摸点的 ID、坐标、压力等信息。应用程序需要在自己的窗口过程里处理这条消息。
嗯，这里要注意：Windows 的触摸事件是 多点触控 原生的。每条 WM_TOUCH 消息可以携带多个触摸点，通过 TOUCHINPUT 结构体数组传递。这一点跟 Android 的 MotionEvent 类似，但 iOS 的 UITouch 是每个触摸点单独一个对象。
核心流程：系统通过 RegisterTouchWindow 注册窗口支持触摸，然后处理 WM_TOUCH 消息。消息中包含 TOUCHINPUT 结构体，里面有触摸坐标、压力、接触面积等信息。
我做过一个 Windows 平板上的手写输入应用，当时就遇到了触摸偏移问题。Windows 的 TOUCHINPUT 结构体里有个 x 和 y 字段，但它们不是屏幕像素坐标，而是 物理坐标（单位是百分之一毫米）。你需要用 PhysicalToLogicalPoint 函数把它们转换成屏幕坐标。这个转换如果没做对，触摸点就会偏。
// Windows 触摸事件处理示例
// 注册窗口支持触摸
RegisterTouchWindow(hWnd, 0);
// 窗口过程处理 WM_TOUCH
case WM_TOUCH: {
UINT cInputs = LOWORD(wParam);
TOUCHINPUT* pInputs = new TOUCHINPUT[cInputs];
if (GetTouchInputInfo((HTOUCHINPUT)lParam, cInputs, pInputs, sizeof(TOUCHINPUT))) {
for (UINT i = 0; i < cInputs; i++) {
TOUCHINPUT ti = pInputs[i];
// 将物理坐标转换为屏幕坐标
POINT pt;
pt.x = ti.x / 100; // 百分之一毫米 -> 像素（粗略）
pt.y = ti.y / 100;
PhysicalToLogicalPoint(hWnd, &pt);
// 处理触摸点
if (ti.dwFlags & TOUCHEVENTF_DOWN) {
// 触摸按下
} else if (ti.dwFlags & TOUCHEVENTF_UP) {
// 触摸抬起
} else if (ti.dwFlags & TOUCHEVENTF_MOVE) {
// 触摸移动
}
}
}
delete[] pInputs;
CloseTouchInputHandle((HTOUCHINPUT)lParam);
return 0;
}
注意：Windows 的触摸事件跟鼠标事件是独立的。如果你同时处理 WM_TOUCH 和 WM_MOUSEMOVE，可能会收到重复的事件。我建议在触摸设备上只处理 WM_TOUCH，禁用鼠标事件，避免冲突。
另外，Windows 10/11 引入了 Pointer API（WM_POINTER 消息），它统一了触摸、触控笔、鼠标的输入。如果你在做新项目，我建议直接用 Pointer API，它更现代，而且能自动处理坐标转换。老项目如果还在用 WM_TOUCH，记得检查 PhysicalToLogicalPoint 的调用是否正确。
3.4 三大系统对比总结
好了，三个系统都讲完了。我最后用一张表总结一下它们的关键差异，方便你以后做跨平台开发时参考：
| 特性 | Android | iOS | Windows |
|---|---|---|---|
| 事件模型 | 责任链分发 | 响应链 + hitTest | 消息队列（WM_TOUCH） |
| 多点触控 | MotionEvent 支持多点 | 每个 UITouch 独立 | TOUCHINPUT 数组 |
| 坐标系统 | 屏幕像素坐标 | 视图相对坐标 | 物理坐标需转换 |
| 拦截能力 | 强（onInterceptTouchEvent） | 弱（需重写 hitTest） | 无（消息级别处理） |
| 校准切入点 | getRawX/getRawY 后修正 | preciseLocationInView 后修正 | PhysicalToLogicalPoint 后修正 |
说实话，这三个系统的触摸事件处理，本质上都是在解决同一个问题：把物理触摸映射到 UI 元素上。只是各自的实现路径不同。Android 给了开发者最大的控制权（拦截、分发、消费），iOS 追求简洁和确定性，Windows 则保留了传统的消息机制。
对于触摸偏移校准来说，你不需要在每个系统里都重新发明轮子。核心思路是一样的：拿到原始触摸坐标，减去校准偏移量，再把修正后的坐标交给 UI 系统。区别只在于，你在哪个环节做这个减法。
我的建议：在 Android 里，在 onTouchEvent 的 ACTION_MOVE 里做校准；在 iOS 里，在 touchesMoved:withEvent: 里做校准；在 Windows 里，在 WM_TOUCH 或 WM_POINTER 处理函数里做校准。这样能保证校准逻辑在最底层生效，不影响上层 UI 的布局计算。