一行代码，一个系统！您的 Crash 实时分析已上线

内容摘要

腾讯移动分析（MTA），将内部打磨多年的Crash分析能力对外输出，在复杂的App生态下，专注于构建完善的质量体系，助力App研发者用'一行代码'拥有'完整Crash分析系统'，为App运行时的崩溃检测和恢复提供有力保障。

2017年6月9日-10日，“2017年全球移动技术大会（GMTC）”在北京举行。会议为期两天，面向移动开发、前端、AI技术人员，聚焦前沿技术及实践经验，打造技术人员的学习和交流平台。

大会上腾讯大数据移动开发高级工程师李国栋作为演讲嘉宾，围绕Crash系统实时化演进与实践进行了精彩分享。

以下为演讲简介：

腾讯移动分析（MTA）将内部打磨多年的Crash分析能力对外输出，在复杂的App生态下，专注于构建完善的质量体系，助力App研发者用'一行代码'拥有'完整Crash分析系统'，为App运行时的崩溃检测和恢复提供有力保障。

[1504747389801_1671_1504747390042.jpg]

研究数据表明，60%以上的用户在使用移动App时遭遇过Crash；如果Crash发生在首次启动，21%的用户会选择立即卸载；而如果Crash发生在使用过程中，70%的用户会给应用差评。可以说Crash问题对移动端应用的用户留存率、口碑、市场竞争力和收入都有非常大的影响，是移动应用开发过程中不容忽视的重要因素。

腾讯移动推送MTA推出的Crash分析整体方案，着重要解决的是终端堆栈、机型、日志等数据的完整采集，数据的实时高效处理，堆栈数据的精准还原，以及完善的告警运营体系。

[1504747445826_7563_1504747446047.jpg]

演讲内容干货满满，分享了Crash分析开发工程中的很多技术难点攻克过程。虽然已经邻近大会结束时间，现场也是座无虚席。

[1504747464036_3715_1504747464266.jpg]

演讲结束后，针对腾讯移动分析MTA的Crash能力，我们的讲师李国栋与infoQ的记者也进行了深入的沟通交流。

1. 腾讯MTA Crash分析系统是什么时候创立，经历了哪些里程碑？

腾讯移动分析MTA是在2013年创立的，Crash系统是其一部分功能，也是MTA已有多年的能力，主要面向内部用户开放，为了跟随公司开放的脚步，我们也在不断向外开放和输出我们的核心专业能力，为开发者提供更有价值的功能，为App的质量保驾护航。

近期，我们对Crash系统做了全面的优化升级，不仅支持捕获全平台异常堆栈，还支持实时还原与报表查看，告警监控等一系列功能优化，整个过程来说，至少有三个里程碑：

首先第一个就是基础领域的解决方案。

这一块对开发者来说是一个强刚需的产品，即对Android和iOS原生App的异常处理，其中核心的一个突破在于面向Android的java和NDK、iOS的Objc和Swift两大平台四种语言，我们做到了Crash的全平台覆盖捕获、实时化处理、还原告警与前台报表升级。运营报表的体系这一块的话，我们搭建得很快速，在MTA原有的功能基础上，我们有前期积累的技术优势。

[1504747514425_9243_1504747514686.jpg]

第二个是专业领域的Crash解决方案。

除了原有的一个基础Crash解决方案之外，我们还有一个针对专业领域的统计模块，主要针对游戏引擎，目前我们游戏客户的需求，也是我们内外部产品改进的一个重要驱动力。据MTA内部统计，游戏类App的平均Crash率远超普通App的一倍之多，当前主流游戏引擎是Unity3d与Cocos2dx，上面有四种开发语言：C/C++、Lua、JS与C#，我们以此为基础，为游戏领域提供移动端全面的解决方案，不仅是Crash捕获统计，还有日活统计、时长统计、自定义事件、分群画像、接口监控等一系列功能，目前都正在灰度测试中，很快就会与更多用户见面。

第三个就是整个的Crash系统产品形态包装。

目前，面向App质量的整体解决方案还是以MTA产品中的一个功能模块对外提供服务的，我们内部在构建一种新的产品形态，可以更好为MTA在开发者与App质量这块提供便捷的服务，相信在不久的将来就能与大家见面。

我们希望能够依托团队对数据处理多年的积累，提炼信息指纹，聚类归并相似问题，辅助开发者更快、更简单、更有效解决App质量问题。

2. MTA目前规模多大，消耗了多少计算资源？

先说Crash系统再说MTA。

Crash系统其实是MTA的一个子功能模块，它不像用户活跃数据这样每天都上报，只有App崩溃的时候才会去报这个数据，所以相对来说它是比较少的。即使在这样的条件下我们的系统每天超过10亿的Crash数据流水。

在资源消耗方面，整个系统都做云化（虚拟化技术）处理，支持动态调整，支持分群部署，在我们对外开放的常规集群中，基本上维持在一个1000 vCores这样的一个状态，内存的话总共使用了2.8T。计算资源作为它里面的一个核心资源，我们做了很多的性能的优化，这里我们的vCores使用了600个，然后内存使用了1.8T。

今年我们把MTA的核心技术升级，然后对外开放。Crash能力在我们内部其实已经有2年多时间的沉淀，这两年多的宝贵的技术积累和案例实践，是我们能够快速推出Crash能力，面向外部开发者提供优质的服务的基础。

3. 对于Crash分析系统，实时化的难点在哪里？目前延迟能做到多少？

Crash系统这一块，跟我们基础实时统计分析的处理，有相似点也有不一样的地方。主要的挑战点在于海量数据实时的还原处理、指纹智能提取合并、多维查询和性能4个维度。

第一个是还原处理。我们都知道，原始的堆栈的可读性是非常差的，比如iOS和Android的C/C++堆栈就是一串长长的地址，用户几乎无法从肉眼就能看到有用的信息，所有还原是每一条Crash堆栈上来之后，必须要经过第一道工序，只有真正还原到真实的类、函数和行号，才能快速辅助定位问题。对于单一堆栈来说，其结构是非常复杂的。Crash堆栈中既包含App本身固有堆栈，也有有第三方组件，甚至还有很多系统级堆栈，所以，还原过程不仅只是涉及到App本身符号表还原，还有系统库的符号表还原。同时，还原的过程中会涉及到大量的地址计算和字符串匹配，这些都是比较消耗计算资源的，我们也是做了很多优化，才保证整个处理过程控制在秒级。

[1504747610575_7426_1504747610854.jpg]

第二个是指纹智能提取合并。原始堆栈还原后，通常包含大量无效的信息。因为由于App版本、CPU指令集、发布渠道等不一样，Crash堆栈还原后，很可能会分成N个，或者反过来，几个不同Crash堆栈还原后，可能会落地在同一个特性堆栈中。因此，如何在堆栈中提取能够真正代表这个Crash的堆栈指纹是非常关键也是非常有必要的，这能够帮助用户发现真正的问题。所以，我们要保证相同的堆栈归类到一个，而不是说每个堆栈就是一条记录，这样开发者看起来就很复杂了。同时，由于App版本、CPU指令集、发布渠道等不一样，Crash堆栈还原后，很可能会分成N个，或者反过来，几个不同Crash堆栈还原后，可能会落地在同一个特性堆栈中。而我们从用户最关注点出发，以“App到组件到系统”三个层次做分级，把用户最关注的App本身相关内容优先做提取，再经过“干扰数据消除技术”，把不相关堆栈也过滤掉，保证提取出来的堆栈就是能够代表Crash关键内容且用户也是最关注的部分。还有在堆栈的调用过程中，我们要去分析它调用链的调用情况，在这里面也有很大的一个技术挑战。

[1504747646405_1211_1504747646629.jpg]

第三个是多维查询。Crash如果一旦出现问题，其实开发者是很关心的，它还需要第一时间去找到这个问题，但是它怎么找，它有很多方法，它可以通过机型、版本，还有时间，通过用户ID甚至说App内的用户账号，还有就是堆栈的一个模糊的搜索匹配等，这些都是用户常用且很需要的搜索功能。

[1504747712118_7804_1504747712563.jpg]

第四个是性能。我们回头整体看看前面提到的过程，实时是由始至终贯穿所有环节的，我们为什么要强调实时的概念？

这是因为，整个大数据行业的大趋势早已完成“离线到准实时到实时”的演变，行业多数还停留在小时级别，而MTA在实时方面的建设始终都是以业界最严格的标准来做的，所有的实时指标都控制在秒级范围内。

一方面得益于我们公司和部门在大数据这块做的非常多基础平台工作，比如统一接入网关、统一数据中间件之外，系统本身也做了大量的优化处理。为了突破系统性能瓶颈，我们不断挑战专业技术最高点，从CPU SSE指令、多对称网卡驱动、网络协议栈改造、操作系统内核与配置优化、同步异步协程模型，基本上由最底层到上层，穿透了硬件到驱动到协议到架构再到逻辑层的优化技术，把性能挖掘到极限。再通过整个系统的云化处理技术，做到资源合理利用，分集群部署。

4. MTA的并发请求数多少（平均和峰值），如何做到高可用？

对MTA整个系统来说的话，我们也是全部做了一个云化处理。

我们现在后台分了好几个集群，比如手机QQ一个、游戏一个、微信一个，以及对外的公共服务集群也有一个。再比如说高峰期的时候，我们支持一个动态资源的协调，从维度上来看的话，我们对外的公共资源的日处理量已经达到了4000亿的规模；并发请求我们是在一秒千万级别的；因为我们一条上报它可能包含着多条的日志的，（从为用户省流量的角度考虑，处理日志时，我们做了一个合并上报），所以日处理量可以达到一秒几千万的计算能力。

从这个方面来说，我们的高可用，可以通过两个维度来衡量。

第一个维度就是我们服务的质量。

从系统服务的质量来说的话，我们系统已经做了一个云化，并且实现了AutoScaling；以及我们所有的服务，基于一个叫“gaia”的云平台，在那里也可以支持我们的任务调度以及资源的协调，实现资源共享，包括伸缩性的共享性。同时对于一个单机的服务器来说，从硬件到驱动到协议栈到一个操作系统，我们都是经过深度定制优化，从头到尾的话，我们都要对它做多版本的优化。我们保证单机的性能是具备有高可吞吐量的计算能力。

第二个维度就是我们数据的质量。

从数据维度来看的话，我们数据的处理过程也是基于腾讯的大数据处理平台，这个平台在腾讯内部已经大规模的使用于我们的金融支付、社交媒体及广告服务中，非常稳定可用。

拿个例子来说，TDBank 系统是一个消息中间件，这个消息中间件不仅起到消息的一个数据流转的过程，必要时，它有起到一个缓冲的削峰的作用。比如说在某个时间点，一下子大量的数据过来了，后端模块不能及时响应，在这个时候TDBank 会把这个日志给缓存起来，做数据回放，这样的操作保证我们的数据不会丢失。

然后我们可以再看一下整体。

我们除了数据和系统维度，还有腾讯TGW这样子的统一网关保证全网运营商最优接入，还有门神系统保障诸如大规模网络攻击等安全问题等系统平台，来保障我们的系统是全面可稳定运营的，所以，不管从哪个维度来看，不管是从系统服务和数据安全各方面，都可以保证MTA的服务的稳定性，实现高并发可用。

5. 能否收集和分析所有Native层Crash？

这肯定是可以的，这是一个Crash的基本能力。

可以从两个维度来看：

第一个是数据采集。

我们现在主流的安卓、IOS平台已经占到百分之九十八、九十九以上了，基本上就是讨论我们在这两个系统上的覆盖。安卓有两个层面：一个是java，一个是C/C++的层面，而iOS有Swift和Objc两种语言，这些我们已经全部覆盖了。

这里面我们想要强调一点，目前在这一块的捕获当中，其实对于安卓的C/C++捕获，业界很少有产品服务能力，因为这里面它涉及到很多的技术挑战，这里面它不仅要掌握linux的信号量机制，还要处理armeabi、armeabi-v7a、x86和mips本身固有的平台指令差异问题，还要兼容64位版本的平台。在Crash发生后，系统传给我们的数据非常有限，只有信号量、Crash地址这些非常非常基础的信息，这就是说，我们必须要通过一个简单的Crash地址，完成一个函数调用的调用链回溯、寄存器数据、子进程数据、临近地址空间，这里面也涉及到大量的技术挑战。

第二块就是在数据处理这一块。

数据处理聚集在终端上报的异常的实时化处理，关键在于堆栈还原与分析，我们建设了一套完整的数据处理方案，可以让开发者通过简单上传符号表就能查看所有异常堆栈、调用链、埋点日志，精准到行号。

再加上对专业领域、专业组件的深度定制，MTA基本上覆盖移动端Crash绝大多数场景，开发者只要通过简单的一两行代码，便可得到一个完整的解决方案。

[1504747803158_7377_1504747803405.jpg]

最后想要说的是，不管是对于Crash系统还是整个腾讯移动分析MTA系统来说，虽然存在前面提到的多平台覆盖、实时化计算、实时还原合并等各种挑战，但我们内部一直强调的是不管多有难度的技术，都要做到“深入浅出”，对于MTA来讲，最直接的莫过于“一行代码，一个系统”。只要终端简单集成一行代码，不仅即刻拥有整个腾讯大数据平台资源万亿级的计算处理能力，还可通过丰富的报表管理台，实时查看Crash指标、自定义事件、页面时长、可视化埋点指标等一系列的功能，真正让用户用的灵活方便。

文章来源：【腾讯大数据】微信号：tencentbigdata