⼀一个顽强的Bug修复经历  

shengxuanwei  2013-­‐02-­‐05

1

Bug复现• Android  2.3的UC浏览器中浏览WebApp地铁专题图，容易出现浏览器崩溃。

Bug背景• WebApp地铁专题图以XML⽂文件作为源数据，在固定尺⼨寸（平均1600px*1600px）的Canvas画布绘制出地铁专题图  

• 拖动和缩放均只是对Canvas画布的绝对定位（left/top）和样式尺⼨寸（width/height)进⾏行改变，不重绘Canvas  

• ⽤用户点击事件的捕获采⽤用了hitCanvas⽅方式，即采⽤用不绘制在屏幕上的Canvas

Bug判断1. Canvas尺⼨寸过⼤大？  2. 拖动或缩放更新样式？  3. hitCanvas导致？

Bug跟踪1. Canvas尺⼨寸过⼤大  –使⽤用静态图⽚片替换Canvas画布  –将⼀一个⼤大的Canvas分割成多个⼩小的Canvas，组合成⺴⽹网格Grid排列  

–创建固定尺⼨寸的⼩小Canvas，组合成Canvas  Grid  –创建屏幕尺⼨寸相当的⼀一个Canvas  –涉及到交互逻辑和Canvas  Grid逻辑全⾯面修改

Bug跟踪2. 拖动或缩放更新样式  – 通过setInterval模拟⽤用户拖动⾏行为，观察CPU和内存情况  

– 同时，模拟⽤用户缩放和点击⾏行为，观察CPU和内存情况

Bug跟踪3. hitCanvas导致  – 不创建hitCanvas，不监听Click事件

Bug根源• Canvas属于⾼高消耗的⻚页⾯面元素，创建尺⼨寸超出⼀一定范围对内存消耗⼤大，容易造成绘制不完全，甚⾄至导致系统内核强制关闭浏览器回收内存  

• 重绘Canvas相对于创建Canvas开销⼩小很多• 相同尺⼨寸的静态图⽚片性能很好

Bug修复• 采⽤用⼀一张与屏幕尺⼨寸相当或者稍⼤大的Canvas绘制，拖动或者缩放时重绘  

• 替换hitCanvas技术，采⽤用数学计算⽅方式分析⽤用户点击状态  

• iOS下SVG性能较好，且能保证⾼高清效果

Bug⼼心得• 针对可能的原因寻找相关资料，尤其是Android  WebKit，Google  Group⾥里有不少Bug  Issue可供参考  

• ⼀一次只针对⼀一个影响因素进⾏行定量分析，隔离影响因素  

• 借助可靠有效的调试⼯工具  • ⽇日志分析，  DDMS