浏览器问题解决的心得

浏览器问题解决的心得

 

近期在跟平台厂商进行内置合作时，碰到了不少的问题，经过大家不懈的努力都已经解决。现将解决的心得分享一下。

       问题：平台厂商浏览器在某地区不能正常使用。

       第一阶段现象：死机（解决周期1天）

 

       分析：同样的代码，在深圳这边没有发现问题，而在某地区发现死机，应该跟网关有关吧。

       过程：

 

1.       收集对方的catch信息，收集自己的日志输出信息。

2.       发现对方返回无法Not Authored 信息的wml页面。

3.       将日志提取为页面文件，本地解析，发现卡死。

4.       调试发现计算逻辑存在问题，导致调用栈耗尽。

 

第二阶段现象：Not Authored(解决周期 3天，可能沟通问题，导致要不到某些数据)

 

       分析：同样的代码，在大陆深圳这边没有发现问题，而在某地区发现Not Authored，应该跟网关有关吧。

       过程：

 

1.       收集对方的catch信息，收集自己的日志输出信息。

2.       没有发现有价值的数据。

3.       要求对方提供一下现有的可用浏览器包头信息。

4.       发现可能属于ua或者资源信息打包方式的问题

5.       依据可用包头信息重新打包数据，发现ok。

 

第三阶段现象：打不开页面，总是显示正在打开（解决周期 5天，）

 

       分析：同样的代码，在深圳这边没有发现问题，而在某地区发现总是打不开，应该跟网关有关吧。

       过程：

 

1.       收集对方的catch信息，收集自己的日志输出信息。

2.       发现数据总是收集不完整，没有发现其他有价值的数据。

3.       怀疑跟文件操作有关（部分机型，在无法写文件时，一切正常）。

4.       然而分析不到有效信息，问题方向无法确定

5.       平台开发商那边分析catch日志（对方提供的日志信息方式），确定是由于浏览器本身主动关闭网络所致。

6.       抓取在某地区那边收集的日志信息，将包头（台湾那边数据）和数据（本地数据）重新组织后，发现本地测试，也是正在打开中。

7.       经过仔细调试，发现包头解析存在逻辑问题，导致包头长度解析不正确（这个之前有同事提起过有问题，而且也作了修改）。

 

 

心得体会：（以下内容，很多基于个人思路，难免偏激，欢迎各位指正）

 

解决过程

第一次，        通过某地区数据分析，得以较好解决

第二次，        通过某地区提取其他浏览器信息进行对比，得以解决

第三次，        通过某地区查出问题的方向，我们这边再以数据模拟处理。

 

解决方法：

 

都是通过日志分析，找出问题的所在。

 

心得：

 

我们这次有了非常好的日志信息架构，在输出信息时，以模块等进行屏蔽输出，便于减少无用日志导致的疲劳；所以我们建议每款软件，都要有良好的日志模块。

 

另外，信息对比尤为重要，模拟数据，模拟现场信息非常重要，提供额外的数据输入接口以方便调试

 

最后，问题的方向确定尤为重要（良好的日志输出，丰富的开发经验，对软件架构的熟悉）。在第三个问题的解决上，就是由于无法快速确定主攻方向，导致四处怀疑，无法深入的测试某些关键环节。

 

平台厂商那边以他们丰富的经验和对己方catch熟练的使用，得出问题出在我们主动关闭网络，其后我们则以日志构造模拟台湾数据，进行测试，从而查出问题所在。

 

感慨：

方向问题是最大的问题，其次是问题的原因，最后是解决的方法。

 

有这么一个故事：

 

有位病人，四处求医，久病不愈。一日，他确定远离家乡去找闻名的神医治疗。神医经过慎重的诊断，给他开了一剂简单的药方，但总费用却非常高5000元。这位病人不解，这么简单的药方为什么费用这么高。神医给了个清单：诊断费4999元,药费1元。

 

从这里我们可以看到，怎样找到问题的原因的难度要远远大于解决的方法，然而要找到问题的原因，就必须确定正确的方向，不然，可能四处求医，也不得病因。

 

 

对我们软件的问题调试也是同样的道理，问题的方向>>问题的原因>>解决方案。

 

这就要求我们必须良好的信息收集机制（日志），良好的分析机制（日志分析软件），软件架构的兼容性（扩展接口），软件代码的可读性（巧妙的逻辑，可能不严谨，然而日久可能自己都不熟悉）。

 

额外话题

 ....................................