这一次，卡98%问题终于解决了

今日话题

在新项目中，往往会有一些瓶颈的问题阻碍项目进程，如鲠在喉。而腾讯手游助手项目中，启动卡98%的问题就属于这种问题。幸运的是团队最终解决了此问题，现在回过头来总结与思考一下，看看有什么收获和改进的地方。

1.背景

腾讯手游助手是基于virtualbox二次开发的产品，在virtualbox的基础上做一层UI，封装一些常用的操作，针对游戏设置一些默认虚拟按键，让玩家可以愉快的在电脑上玩手游，而不用操心繁琐的设置问题。

(图一) 模拟器模块结构

在项目初期，陆续接到一些用户的反馈，加载模拟器卡在98%。界面表现如下图：

(图二)助手启动卡98%的表现

翻看BBS的反馈信息可以看到，15年11月份就已经开始暴露该问题：

(图三) BBS卡98%反馈

2. 分析

翻看UI中的相应代码，梳理启动流程如下：

(图四)模拟器主要启动流程

01

CheckEnvironment()检查环境

1. 检查上次是否发生崩溃
2. 检测下COM和驱动是否正常,如果有则尝试修复
3. 检测CPU、CPU是否支持VT、VT是否开启
4. 检测OPENGL渲染是否OK
5. 设置当前显示颜色为32位色

02

StartVM()准备虚拟机

1. 检查OPENGL版本、判断是否强制使用DX模式
2. 调整虚拟机内存大小
3. 调整虚拟机CPU核数

03

StartVMInternal()启动虚拟机

1. 设置虚拟机的分辨率
2. 设置虚拟机的DPI
3. 设置虚拟机开启hardware_opengl
4. 设置IMEI
5. 设置虚拟机代理
6. 设置端口转发
7. 调用启动模拟器的命令

04

Init_devices()初始化各种设备。

这一步会创建多个通讯线程来与android内部通讯，只要有线程能通讯成功，就说明模拟器成功启动且能正常控制模拟器。

1. 启动本地OPENGL渲染，创建渲染窗口
2. 启动输入通讯线程
3. 启动控制通讯线程
4. 启动传感器通讯线程

正常流程下，UI调起一些Tbox(即virtual的修改版)命令行进行设置，然后启动ROM，ROM成功启动后，android内的launch进程会发送一个"connected"消息，UI收到后启动成功。UI通过建立socket来与Tbox来通讯，而Tbox通过虚拟的PCI设备来与ROM通讯。而异常流程下，启动ROM后，UI一直没有收到一个成功连接的消息。所以该问题可能原因只有两种：

1、ROM压根未启动成功

2、ROM启动了，但是通讯失败了。

明确了问题原因后，似乎很容易排查了，但跟进过程并不是那么顺利。

3.跟进

01

机器配置过低

15年11月。发现一些用户的ROM启动不了，共性是机器配置都不高。之后查到主要是内存影响虚拟机的启动，所以解决方案是在安装程序中增加对机器内存的检查，低于2G的不允许安装。

02

Tbox进程卡死

15年11月。跟进了多个启动卡98%的用户发现，如果模拟器非正常退出，TBoxManage.exe、TBoxSVC.exe、TBoxHeadless.exe（tbox进程）三个进程可能会卡死，再次启动模拟器，所依赖的进程卡死，导致启动不成功。解决方案很简单：启动前强制结束三个进程。

03

第三方注入

15年12月。又发现一些用户卡98%的共性是都安装了迅雷网游加速器。进一步定位发现该软件的XLaccLSP.dll会注入到所有进程，包括模拟器的TBoxHeadless.exe进程，而导致socket建立失败。解决办法是防止这个模块的注入。

04

LSP服务等导致socket不可用

16年上半年。仍陆续接到很多反馈，又跟进多个用户，发现用户都是由于建立socket失败而导致的启动卡98%，原因包括:

a) lsp导致断网、

b) V**问题。

c) 防火墙问题。

决定使用管道（pipe)来取代socket来通讯。由于改动涉及底层，改动量大，加上其它业务需要较多，排期至7月份才上线。

05

新ROM的bug

16年8月份。原本以为卡98%能够通过管道版本彻底解决，没想到新版本也仍有不少用户反馈。继续跟用户。发现用户都是单独启动tbox也无法进入至桌面。进一步定位，发现是VDI（也就是ROM）文件损坏而导致。而后在官方论坛上找到原来是由于4.4.2的系统解析损坏的XML异常而导致，而上半年刚好我们由4.2.2的系统升级至4.4.2，打上官方补丁后终于得以解决。至此卡98%的问题终于得以完全解决。

4.反思

01

不要太过相信第三方组件。

对第三方组件过度依赖，太相信第三方组件往往会踩大坑，使用第三方组件一方面需要做全方面深入了解，另一方面是做一些必要的容错或者规避机制。

02

关键信息应该上报

虽然该问题严重程度很高，但该问题只在极少数用户的环境下出现，测试环境无法重现，所以进展非常缓慢。更重要的是，该问题的影响范围我们无法评估。仅仅靠反馈量来驱动问题的解决是非常不靠谱的，用户很有可能试用一次后就流失了。所以，在产品初期就应整理关键路径的数据，并上报给后台，出现问题后能及时评估关键路径上的异常影响范围，及时推进问题的解决。

03

异常原因应尽量细化

首先是产品表现太笼统了，增加了定位问题的成本。只要是未能成功与虚拟机通信，都表现为启动卡98%。另外，一些问题也值得我们思考：

a) 是否可以通过技术手段细化不能通讯的原因呢？

b) 是否能提前检测是VM的自身问题还是通讯的问题？

c) 是否可以提前细化socket建立连接异常的原因？

d) ...

在这种疑难疑难的定位过程中，出现后尽量把异常细化，不论是产品表现还是日志上数据上报，以便在出现问题时能快速而精确的定位问题。