看起来很完美,但是有个小缺点:网络请求,需要刷新页面,可是很多内嵌的 H5 页面是没有机会刷新页面的,所以需要客户端童鞋配合增加刷新的功能方便调试。

 

九、场景分析

 

既然移动端调试有这么多种方案,那在实际操作中,我该如何取舍?

说了这么多钟方案,这里总结一下各个方案的适用场景,根据不同的场景去选择最佳的调试方案,这样才能更快速的输出,Carry 全场:

 

1.SafariiPhone 调试利器,查错改样式首选;
2.iOS 模拟器:不需要真机,适合调试 Webview 和 H5 有频繁交互的功能页面;
3.Charles: Mac OS 系统首选的抓包工具,适合查看、控制网络请求,分析数据情况;
4.Fiddler:适合 Windows 平台,与 Charles 类似,查看、控制网络请求,分析数据情况;
5.Spy-Debugger: 移动端调试的利器,便捷的远程调试手机页面、抓包工具;
6.Whistle:基于 Node 实现的跨平台 Web 调试代理工具;
7.Chrome Remote Devices:依赖 Chrome 来进行远程调试,适合安卓手机远程调试静态页;
8.localhost 转 ip:真机调试,适合远程调试静态页面;
9.vConsole:内置于项目,打印移动端日志,查看网络请求以及查看 Cookie 和 Storage

 

十、白屏处理

 

移动端的白屏是最头疼的问题,这里顺带提供几种分析问题的思路,以供参考。

 

1.方案分析 ☆


一般上线后出现问题,我们最容易想到的就是:是否是新代码引起的问题。所以有效解决手段就是「控制变量法」。

 

2.代码注释法 ☆


莫名奇妙的白屏,适合页面无异常日志,同时无请求发送,问题集中在单一页面的情况。这种问题比较直观,肯定是某一页面出现了代码异常或是无效的 return,导致页面渲染终止,但并不属于异常。这时候,「代码注释法」将是你的最佳选择,逐行去注释可以代码,直到定位问题。

 

3.类库异常,兼容问题 ☆


这种场景也会经常遇到,我们需要用可以调试页面异常的方式,如 SafariSpy-DebuggerWhistlevConsole 查看异常日志,从而迅速定位类库位置,从而找寻替换或是兼容方案。

 

4.try catch ☆☆


如果你的项目没有异常监控,那么在可疑的代码片段中去 Try Catch 吧。

 

5.Debug 包 ☆☆☆

 

在你的项目中装上 vConsole,并配合客户端 debug 插件,360 度无死角监控异常,这才是最有效的方式。

 

6.ES6 语法兼容 ☆

 

一般我们都会通过 Babel 来编译 ES6 ,但是额外的第三方类库如果有不兼容的语法,低版本的移动设备就会异常。所以,先用上文讲述的调试方法,确定异常,然后去增加 polyfill 来兼容吧。