原生UI开发实战技巧与性能优化全解析

我的写法，亲测靠谱

做移动端原生UI开发这些年，踩过的坑比走过的路还多。尤其是那种看似简单、实际一上线就各种诡异问题的交互，比如 touch 事件冲突、滚动卡顿、点击穿透……我一般这样处理：先上代码，再说思路。

let startY = 0;
let isScrolling = false;

document.addEventListener('touchstart', (e) => {
  startY = e.touches[0].clientY;
  isScrolling = false;
}, { passive: true });

document.addEventListener('touchmove', (e) => {
  const moveY = e.touches[0].clientY;
  const diff = startY - moveY;

  // 垂直移动距离大于水平？说明用户想滚动
  if (Math.abs(diff) > 5) {
    isScrolling = true;
  }

  // 如果是横向滚动容器，阻止默认行为容易出问题
  // 这里加个判断更稳妥
  const target = e.target;
  if (target.classList.contains('horizontal-scroll')) {
    return; // 让它自己滚
  }

  if (isScrolling) {
    // 阻止页面级滚动，只在必要时
    if (!target.closest('.scrollable-area')) {
      e.preventDefault();
    }
  }
}, { passive: false }); // 注意这里不能设为 true

这段代码我在好几个 H5 活动页和 Hybrid 页面都用过，核心就是两个点：

• 通过 startY 和移动差值判断是否进入滚动状态
• 只在真正需要的时候才调用 e.preventDefault()，避免整个页面被锁死

很多人一上来就在 touchmove 里直接 e.preventDefault()，结果导致页面完全不能滑动，微信浏览器里尤其明显。这种写法更靠谱——让用户的行为决定行为。

这几种错误写法，别再踩坑了

我见过太多项目因为这几个低级错误上线后被打回三次。

错误一：无脑 preventDefault

document.addEventListener('touchmove', (e) => {
  e.preventDefault(); // ❌ 完全禁止滚动
});

看起来能解决“滚动穿透”，实际上会让整个页面变砖。用户在安卓机上上下划一下，发现没反应，直接以为是 bug。而且还会触发 Chrome 的警告：[Intervention] Unable to preventDefault…

错误二：忘了 passive 参数

document.addEventListener('touchstart', (e) => {
  // 占用主线程，阻塞滚动
  console.log(e.touches[0].clientX);
});

默认情况下，现代浏览器会把带事件监听的 touch 事件标记为非 passive，意味着你可能会调用 preventDefault，从而阻塞滚动响应。正确做法是加上 { passive: true }，除非你真的要拦截。

错误三：在 scrollable div 外层也锁死

有个同事做了一个弹窗，里面有个长列表要滚动。他这么写的：

.modal-open {
  overflow: hidden;
  position: fixed;
  width: 100%;
}

然后给 body 加这个 class。问题是：fixed 后 scrollTop 丢了，iOS 上还会跳到顶部。而且如果弹窗里的内容不够长，根本没法滚动，用户体验极差。

后来我们改成只禁用 body 的滚动事件，保留结构：

const handleBodyScroll = (e) => {
  if (document.body.classList.contains('modal-open')) {
    e.preventDefault();
  }
};

document.addEventListener('touchmove', handleBodyScroll, { passive: false });

并且只在 modal 显示时添加监听，隐藏时移除。虽然多几行代码，但稳得多。

实际项目中的坑

去年做一个电商促销页，有个横滑商品卡片区域，在安卓低端机上滑着滑着就卡住，怎么都动不了。排查半天发现是父级容器加了 transform: translateZ(0) 硬件加速，但子元素用了 position: fixed，导致合成层错乱。

建议避开这种组合，容易出问题。能用 transform 就别用 fixed，特别是涉及到动画或滑动的场景。

还有一次是在 iOS 上，input 聚焦唤起键盘后，页面布局错位，footer 跑到了中间。折腾了半天发现是因为 viewport 高度变了，但我们用的是固定 height: 100vh。后来改成了 JS 动态计算：

function updateViewportHeight() {
  const vh = window.innerHeight * 0.01;
  document.documentElement.style.setProperty('--vh', ${vh}px);
}

window.addEventListener('resize', updateViewportHeight);
updateViewportHeight();

.container {
  height: calc(var(--vh, 1vh) * 100);
}

这样一来，哪怕键盘弹起，也能动态适配。jztheme.com 上那个表单页就是这么修好的。

关于 click 延迟和穿透

fastclick 是过去式了，现在大多数机型已经没有 300ms 延迟。但如果你还在维护老项目，注意不要混用 fastclick 和现代框架自带的事件系统，会导致某些按钮被触发两次。

我自己现在统一用 CSS 来增强响应性：

.touch-item {
  touch-action: manipulation; /* 等效于禁用双击缩放 */
  -webkit-tap-highlight-color: transparent;
}

这一招比引入库简单多了，还不增加包体积。对于已知的可点击元素（button、a、自定义组件），加上这个类就行。

至于点击穿透，通常是出现在蒙层点击关闭时，下面的按钮也被触发了。解决方案有两个：

1. 关闭前用 setTimeout 延迟 hide，让点击事件冒泡完（不推荐）
2. 在蒙层消失前，临时给底层加一个全屏透明遮罩层挡一下（推荐）

第二种虽然多一个 DOM 节点，但逻辑清晰，不容易翻车。

最后一点：别迷信“完美方案”

说实话，移动端 UI 就没有银弹。不同机型、不同系统版本、不同 WebView 内核，表现可能完全不同。比如三星自带浏览器对 overflow-scrolling: touch 支持不好，而小米某些版本又会对 transform 元素丢帧。

我的经验是：测试一定要覆盖主流真机，模拟器只能作为初步验证。线上监控也要加上用户行为日志，比如记录是否有异常的 touch 中断事件。

另外，尽量避免过度定制原生行为。有时候你觉得“这个下拉刷新太丑了，我要自己写”，结果搞出一堆兼容性问题。不如直接用现成库，比如 better-scroll，至少人家踩过的坑比你多。

当然，如果只是简单场景，比如一个横向滑动 tab，自己手写完全没问题。关键是权衡复杂度和风险。

以上是我踩坑后的总结，希望对你有帮助

这些方法不是最优解，有些甚至只是“将就能用”。但在真实项目中，时间紧任务重，能快速解决问题才是王道。改完后仍有一两个小问题，只要不影响主流程，我就先放着，后续再优化。

如果你有更好的实现方式，比如更轻量的滚动检测逻辑，或者处理键盘弹起的新姿势，欢迎评论区交流。我也一直在找更干净的解法。