移动端调试那些事儿 从Chrome DevTools到真机测试的实战经验

Mobile调试真让人头疼，Chrome DevTools各种不好使

上周在做一个移动端项目，本来以为Chrome DevTools的移动设备模拟器够用了，结果各种奇怪问题根本定位不到。页面在PC浏览器里跑得好好的，一到手机上就是另一回事了。touch事件不响应、CSS兼容性问题、还有些莫名其妙的性能卡顿，光靠模拟器完全搞不定。

折腾了半天发现，模拟器毕竟还是模拟器，真实的手机环境和浏览器行为差太多。特别是那个Safari的渲染引擎，跟Chrome的差距比想象中大得多。

真机调试才是王道，几种方案都试试

后来我试了几种真机调试的方法，最后找到了一个比较靠谱的组合方案。之前也用过vConsole，但总觉得太重，而且某些情况下还会干扰正常的调试流程。

这里先说下iOS Safari的调试，这个真的坑了我好久。一开始不知道怎么搞，后来才发现Mac上的Safari有个开发者模式，可以直接连接iPhone进行调试。具体步骤：

• iOS设置 > Safari > 高级 > 启用Web检查器
• Mac Safari > 偏好设置 > 高级 > 在菜单栏中显示开发菜单
• 然后就能在Safari的开发菜单里看到连接的设备了

Android这边就相对简单一些，Chrome的inspect功能还算稳定。不过要注意USB调试要开启，还有可能遇到adb连接不稳定的问题。

eruda轻量级调试神器，几行代码搞定

但上面那些方法都有个问题，就是需要物理连接，或者要走网络，有时候还是很麻烦。后来同事推荐了个eruda，这个轻量级的移动端调试工具真的好用。引入一行脚本，在移动端也能有完整的控制台体验。

// 生产环境可以通过这个开关控制是否加载
if (location.href.indexOf('debug=1') !== -1) {
    var src = 'https://cdn.jsdelivr.net/npm/eruda';
    document.write('<script src="' + src + '"></script>');
    document.write('<script>eruda.init();</script>');
}

这里我踩了个坑，一开始想直接全局引入，结果发现在生产环境里不太好，所以加了个参数开关来控制。这样只有手动加上?debug=1的时候才会加载调试工具。

eruda的优势很明显，不用连接电脑，直接在手机上就能看console、network、elements等等。缺点是稍微影响一点性能，而且在某些低端机型上可能会有点卡。

Network面板抓包分析，API调用一目了然

移动端最常见的问题就是API调用失败或者超时。Chrome的devtools虽然有network面板，但模拟器里的网络状况跟真实情况差别很大。用eruda的话，network面板基本就是照搬了Chrome的功能，查看请求参数、响应数据都很方便。

// 示例API调用
fetch('https://jztheme.com/api/mobile-data', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json'
    },
    body: JSON.stringify({
        userId: 123,
        action: 'getData'
    })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

通过eruda的network面板，能很清楚地看到请求的完整过程，包括header、payload、response等等。这一点对于排查移动端的跨域问题特别有用，因为有时候手机浏览器的安全策略跟PC不太一样。

Touch事件调试，滑动卡顿问题终于找到原因

之前遇到个很诡异的问题，列表滑动在某些机型上特别卡。用模拟器完全复现不出来，但真实设备上就是有问题。后来用eruda打开了performance面板，发现是touchmove事件处理函数里做了太多DOM操作。

let isScrolling = false;
document.addEventListener('touchstart', function() {
    isScrolling = true;
}, { passive: true });

document.addEventListener('touchmove', function(e) {
    // 这里如果做复杂计算会导致卡顿
    if (isScrolling) {
        requestAnimationFrame(() => {
            // 耗时操作放到requestAnimationFrame里
            updateScrollPosition(e);
        });
    }
}, { passive: true });

document.addEventListener('touchend', function() {
    isScrolling = false;
}, { passive: true });

上面这个代码需要注意passive参数，这在移动端很重要。如果不加的话，某些浏览器会阻止默认滚动行为，导致页面完全无法滚动。

LocalStorage和Cookie问题，调试起来真不容易

移动端还有一个经常遇到的问题就是存储相关的。某些浏览器对localStorage的限制比PC端严格，有时候会触发安全策略。用devtools的Application面板能很方便地查看和清理这些数据。

但模拟器里的数据存储状态和真实设备也可能不一样，特别是iOS的Safari，有时候会自动清理存储空间。这个问题我在测试登录态保持的时候遇到过，明明本地存了token，刷新页面就没了。

后来写了个简单的存储检测工具：

function testStorage() {
    try {
        const testKey = 'mobile_debug_test';
        localStorage.setItem(testKey, 'test');
        const value = localStorage.getItem(testKey);
        localStorage.removeItem(testKey);
        
        if (value === 'test') {
            console.log('localStorage works fine');
            return true;
        } else {
            console.log('localStorage has issues');
            return false;
        }
    } catch (e) {
        console.log('localStorage not available:', e.message);
        return false;
    }
}

性能监控不能少，内存泄漏问题排查

移动端的性能问题往往比PC端更严重，特别是内存管理。某些页面切换或者组件销毁的时候，如果处理不当很容易造成内存泄漏。eruda的performance面板在这方面帮了大忙，能看到详细的内存使用情况和垃圾回收信息。

我还自己写了个简单的FPS监控工具，专门用来检测页面卡顿：

function startFPSTracker() {
    let lastTime = performance.now();
    let frameCount = 0;
    let fps = 0;

    function update(now) {
        frameCount++;
        if (now >= lastTime + 1000) {
            fps = Math.round((frameCount * 1000) / (now - lastTime));
            console.log(Current FPS: ${fps});
            
            frameCount = 0;
            lastTime = now;
        }
        requestAnimationFrame(update);
    }

    requestAnimationFrame(update);
}

// 在需要监控的地方调用
startFPSTracker();

这个工具在调试动画性能的时候特别有用，能够实时看到当前页面的帧率，判断是否存在性能瓶颈。

远程调试HTTPS页面，证书问题有办法

HTTPS页面的调试也有坑，特别是本地开发环境的证书问题。有些移动端浏览器对证书校验比较严格，会阻止不安全的内容加载。这个问题我后来是通过Charles或者Fiddler这样的代理工具解决的，给移动设备安装证书之后就能正常调试了。

但这种方式配置比较复杂，而且还要考虑不同设备的兼容性。现在我的方案是结合使用多种调试方式，在开发阶段尽量保证HTTP和HTTPS两种环境都能正常调试。

几个常用的调试技巧，日常必备

平时工作中总结了几个移动端调试的小技巧，感觉还挺实用的：

1. 打开移动端的点击高亮效果，在Chrome devtools里可以设置touch events相关选项

2. 某些CSS属性在移动端的表现跟PC端不一样，特别是transform和transition相关的，要特别注意硬件加速的问题

3. viewport meta标签的设置会影响调试体验，有时候需要临时修改来测试不同场景

4. console.log的输出在移动端要格外小心，大量的日志输出可能会影响性能

这些技巧看起来简单，但在实际开发中经常能节省不少时间。特别是viewport相关的调试，之前我就被这个问题坑过好几次。

以上是我踩坑后的总结，主要针对移动端开发中常见的调试问题。每个人的项目情况不同，适用的方案也不完全一样。如果你有更好的移动端调试方案，欢迎评论区交流。