一. 问题背景

因为H5在iOS13以下系统通过web api来获取设备运动数据，会有授权弹框，体验不好，因此决定通过js来App获取设备运动数据。

H5通过下发js命令给App,App 通过CMMotionManager获取deviceMotion运动信息，然后回调给H5去更新晃动动画效果。

但兼容性测试的时候，发现在iPhone 6s等性能较差的设备上，会导致H5滑动卡顿。

二. 问题排查

经断点调试发现，当出现H5滑动卡顿, Xcode控制台会输出:

iOS [IPC] Connection::waitForSyncReply: Timed-out while waiting for reply, id = 81

从这个提示可以推测，很有可能是App通过CMMotionManager获取deviceMotion运动数据，需要跨进程通讯，去操作系统里面读取设备运动数据。

image.png

而App通过js将设备运动数据回调给WKWebView,因为WKWebView内部是多进程组件，App内部的WKWebView对象，需要将数据提交给WKWebView处理进程，这里也涉及到了进程间通讯导致等待同步应答时间超时。

为了证实猜测，分别将CMMotionManager获取deviceMotion获取运动数据操作和App通过js将设备运动数据回调给WKWebView，独立进行测试，发现在iPhone 6s等性能较差的设备上，H5滑动并未出现卡顿。因此进一步证明了推测。

既然两者结合在一起才会在低版本机型上导致H5滑动卡顿问题。

那是否有其他方法可以尝试下呢？

我们这边可以看到我们用的是CMMotionManager的startDeviceMotionUpdates自动回调的方法。

    /*
     *  startDeviceMotionUpdatesToQueue:withHandler:
     *
     *  Discussion:
     *    Starts device motion updates, providing data to the given handler through the given queue.
     *    Uses the default reference frame for the device. Examine CMMotionManager's
     *    attitudeReferenceFrame to determine this.
     *
     */
    open func startDeviceMotionUpdates(to queue: OperationQueue, withHandler handler: @escaping CMDeviceMotionHandler)

这里还有另外一种方式，就是自己通过业务侧的定时器，定时去读取设备运动数据。

因此改用业务侧自己的定时器来定时读取设备运动数据:

image.png

经测试发现，在业务侧自己设置定时去读取设备的运动数据，在iPhone 6s等性能较差的设备上，H5滑动并未出现卡顿。是可以完美解决问题的。

三. 原因分析

为什么通过设置CMMotionManager的deviceMotionUpdateInterval回调时间，然后开启设备监听d的回调方法startDeviceMotionUpdates(to queue: OperationQueue, withHandler handler: @escaping CMDeviceMotionHandler)，去回调相关设备数据给H5在iPhone 6s等性能较差的设备上，H5滑动会出现卡顿。

但在业务侧自己用定时器，定时去读取就不会。

按道理系统设置定时回调间隔，然后定时回调数据，跟业务侧自己用定时器，定时去读取设备运动数据。两者逻辑是一致的。

因此查找了一些相关的资料，但并没有找到相关的确定的描述。

因此这里也是一个自己的推测:

就是系统CMMotionManager的startDeviceMotionUpdates(to queue: OperationQueue, withHandler handler: @escaping CMDeviceMotionHandler)，可以是一个跨进程的频繁的读取操作，而

deviceMotionUpdateInterval回调时间，只是设定了间隔多久再回调数据。

而业务侧自己设置定时器，定时去读取，是只是到了定时时间，才去跨进程读取设备运动数据。因此业务侧定时读取，跨进程读取的频率相对低很多。

四. 解决方案

• 改用业务侧自己的定时器来定时读取设备运动数据

image.png