同程艺龙资深架构师牛提罚：同程艺龙小程序性能监控系统的探索与实践

11月24日，腾讯云开发者社区开发者大会（苏州站）圆满落幕。本次开发者大会的主题为“姑苏城外论技术：物联网·小程序·微服务”，邀请了腾讯内部及业内行业大咖就物联网、小程序、微服务等当前互联网领域的热点技术的落地实践问题进行了深度探讨。同时，各位技术专家也与到场的开发者们展开了开放式对话，精彩不断。下边是牛提罚老师关于整个监控系统从前端实现原理到中间层、到后端、再到大数据等实践过程和经验的分享。

讲师介绍：牛提罚，同程艺龙资深架构师。擅长互联网及移动互联网前端领域， 有十多年前端开发、团队管理等实战经验。

今天主要跟大家介绍一下整个小程序怎么去做监控？我们监控从前端到中间系统再到数据库底层怎么实现的？跟大家进行一些经验分享：

l 第一是微信小程序实现原理，大家做微信小程序技术的有多少伙伴？大家举手示意一下？挺多的，为什么给大家介绍这一块，因为基于程序做这个系统你要根据系统原理还有机制要去了解，才能写小程序相关的框架才能更加明确。

l 第二是系统实现的机制，包括架构，还有集成化，基本把监控的架构跟大家进行了一些总结。

第三是应用实践，发现问题帮助大家解决的什么问题，我们怎么做，怎么解决，主要分三个部分。

刚才跟大家讲了一下今天的主要内容，今天主要是讲小程序实现原理，包括启动加载流程，渲染机制，还有setData运行机制，为什么讲这些？因为三块是微信小程序的核心，是小程序前端加载速度、渲染等性能方面是非常重要的部分。

还有三个监控系统如何实现，核心指标有什么？我们为什么没有直接用微信小程序去进行比较？其实微信小程序后台大家也有看到，也有一些核心性能监控在里面，但是这一块我们如何进行渗透进去，如何为业务进行更好的服务。还有整个应用的实践。

我们先看第一部分，第一部分先跟大家简单介绍小程序应用环节，应用环节大家都知道，其实跟以前做hybrid app的实现机制，或者环境基本上是一样的，有渲染层和逻辑层，逻辑层也是我们经常所说的JScore这一层、webview这一层，会通过第三方负责一切服务进行交互。

其次，我们要了解小程序生命周期怎么样？先后顺序怎么样？这些东西我相信大家在写小程序代码的时候一直有用到，我们了解代码运行时间，这其实也是监控里面的核心。

还有整个小程序启动的加载流程，我们启动一个小程序，整个加载流程是什么样？大家可以看到从逻辑层到渲染层初始化再到JS引擎初始化，还有到公共库的注入，再到代码包的下载，还有到业务代码的注入，注入完以后呈现在我们面前的渲染首屏界面结构才出现，这是整个的一个加载过程，我相信大家现在都了解了再小程序的加载过程，对于小程序业务代码比较多，一直要控制大小，为什么控制大小？因为包括小程序下载方面，不能太长，还有加载系统第一呈现时间就会越长。

还有再一个是我们渲染机制，渲染机制主要所说的就是setData，我们要尽量减少setData数据，为什么要这么去做，比如说我们前端所写的数据也好，还有一些脚本，最终渲染到整个的一个webview，渲染过程是一个单线程的操作，比如说有N个内容去进行加载，不管再多，只有一个JS运营环境下去做，如我们用了10个webview，但是也只能单线来做，这就是整个webview加载和渲染的过程。

以上就是小程序的一些实现机制和原理，简单的跟大家介绍了一下。

大家可能被老板说为什么小程序启动的那么慢，为什么加载那么慢？还有白屏了，加载不出数据，我相信大家或多或少都有遇到，怎么保证我们代码没有bug，或者即使有bug，如何快速可以发现，这就需要有一双眼睛盯着帮助我们的程序发现问题，所以我们就做了这套系统。

做性能监控系统我们要明确我们核心目标指标是有什么？我们做PC指标有很多的指标，有很多的加载资源的一些指标，这些指标跟小程序肯定有不一样，因为小程序跟我们封装了很多插件或者组件，并把我们前端代码打包在客户端。

基于小程序的特性，我们把监控分四大块，第一基础数据，第二是页面各阶段的耗时，刚才说有生命周期还有生命周期的耗期怎样的？还有查询按纽到列表页面整个耗时过程又怎样的？还有整个生命周期之间耗时又是怎样的？这个知道了以后对我们小程序写得好不好快不快，基本上就有数据来支撑我们，帮助我们进行完善和优化程序。

还有接口耗时不管做哪方面，接口耗时是必不可少，那跟后面的小伙伴做的监控有什么不一样？我们前端是端到端，从前端发起请求到后端拿到这个数据，前端从用户客户端发起到拿到数据，一来一回然后进行渲染数据，包括三大块的内容。这是端对端对于用户来说真实的一个数据，还有就是脚本的异常，脚本的异常就是JS相关的一些异常，我们所做的一些监管。

我们先看下监控系统的实现机制，有一个数据采集的SDK也是嵌入到小程序底层，这样可以更帮助我们去做刚才所说四大块的内容，还有数据采集接口，我们有的前端采集的数据，数据怎么发出来也是有单独的接口进行操作，还有存储，存储有两个库在做，第一个是Druid，我不知道大家有没有大数据的伙伴，这一块是作为聚合数据去用，还有明细是ES，为什么这么用呢？因为之前做APP监控的时候，包括PC端，用的是ES，但是一旦查询数据量很大，查询数据维度多的时候，数据查不动，要查半天才能出来，非常慢。这次经过跟我们大数据同学调研研究，最终确定用Druid做聚合层，做一些指标相关的一些数据，还有通过ES查明细数据，就是比较具体，查某个时段，近半个小时或者近一个小时的数据特别快。

系统看版没有什么核心技术，就是通过系统指标呈现出来，还有报警平台可以通过发现问题报出来。

整个SDK特点就是自动补获未处理异常，接入SDK后，不需要大家写代码，大家可以正常开发就好，所有跟这些数据状态也好，耗时也好，SDK都有帮忙处理好。

所有监控都可以通过配置打开和关闭，也可以一键关闭，也可以部分采取，减少数据的存储等。 还有自定义上报，就是同学可以自定义一些数据统计代码系统或者是相关的一些数据。 包括页面切换的时候，从A页面跳到B页面，通过B页面跳到C页面整个耗时的情况都可以统计。

还有生命周期，生命其在SDK对小程序的生命周期，我们都会去打相应的一些点去做一些我们想要做的这些事情。

这是页面生命周期，从onShow onReady onHide，到onShow的时间点是多少？到onReady的时间点多少？到onHide的时间点是多少？我们可以进行计算，帮助我们分析各个生命周期的耗时情况。

还有request的分装，这个封装很重要，一个页面超过10条就有可能出现request abort的这种问题，为什么呢？因为这个最多只能跑十条，超过之后就会在控制台里面可以看到相应的一些报错。

我们怎么封装呢？封装首先是环境，这个就不多说的，有很多环境。还有队列，队列有可能请求太多，以队列的形式发出来，还有优先级，我们进到核心接口肯定不能堵，可以设为最优先级去把其他接口后置，甚至可以把一些没用的请求可以在跳过程当中取消掉。

接口的监控统计，主要是请求参数、请求方式、状态，耗时等，也就是刚才所说的一些耗时，从请求发出一刹那的时间点，到请求拿到的数据推进，整个耗时情况，还有开关，我们可以针对相应的统计进行开关的控制，包括采样的比例大家知道接口很多，我们假如说全部统计的话有时候数据量很大也不太好，一个项目稳定的话可以采取50%，大家可以按比例的进行控制。

自定义，自定义上报数据，大家在写的过程当中可以通过自己定义一些方法，或者定义字段自己控制，比如说我们写的1000或者2000代码，从代码开始第一行执行到最后一行究竟花了多长时间？自己可以写，写好时间回传过来可以进行统计，然后就可以在系统中查看自定义相关的一些性能。

数据整合和分发，因为对前端的要求是减少前端的请求或者压缩数据大小，为用户节省流量，肯定前端请求越少越小越好，这一点是毋庸置疑。我们基础数据只有一条，从用户进到我们小程序只有一条基础数据，这一条基础数据会一直在服务端等着其他数据过来并进行合并，比如说接口相关数据里面不带任何的基础数据，但是到服务端的时候会合起来，其实合起来不合起来都可以，因为我们有相应的字段自己关联也可以，合起来在同一个表中查表的速度相对快一点，不需要找相关的一个表，这是根据大家数据量大小来进行定义的。

做前端的监控，不能影响主业务的应用这是大前提，可以把这些数据存到本地，有一定数据以后再去发布而不是实时占用前端的资源。 还有服务端去做中间层的一些数据合并分发相关的工作。

这是数据的一些架构，第一个是以中间键形式引进来去做，很多都跟大家介绍过，如SDK中的指标等，都是通过系统看版去呈现的，还有报警设置相关的一些方面，通过统一监控平台。

最后一点的话是实践，我们看一下包加载的过程，这是我们的一个页面，这里做了很多事情，如列表预加载，我们小程序里面很多项目大家也可以看到，如火车票、机票、汽车票等等，有很多业务，不可能打到主页里面，也放不下，主包最多2M，我们需要拆包，每个项目都要拆包，拆包要有技巧，拆包不能影响主流程，主页肯定要有，列表页肯定是很核心的模块，要单独去做，不能说进了列表页等了很长时间也不现实，那这里首页到列表页是分了包，还有按需求加载业务级的分包，包括公共的代码，后置流程所用到的一些组件等按需求加载，还有加载过程当中要统计，统计什么？比如说从首页点击机票查询，到列表页的加载耗时，也就是说从查询到页面onLoad代码开始执行这一段时间基本上可以认为分包加载的耗时。

包括其他的后续按需加载的分包是一样的逻辑去进行做的这里可以统计小程序加载的耗时情况，这里不知道是不是大家有所感处，应该是有所感触。

还有兼容性，这是通过我们所发现的一些问题，不支持的JS方法，不支持的ES6方法，大家简单看一下，可以有针对性进行避免。

还有报错应该是四五月份的时候在小程序里面报错最多，每天上百万的报错量，具体怎么一回事，在前端写代码的时候，微信技术最常出现的问题，跟微信小程序版本底层核心库是有关系的，底层对于部分的一些机型是有bug的，官方的一些修复需要时间，我们怎么及时修复，前端的代码，我们靠一些expec Nnd等等形式去代替组件呈现与交互，这个问题当时这里写代码也是写了很久印象很深入，我们A组件引用B组件，当A组件在一个页面被关闭，B组件还没反过来的时候就挂了，用户操作特别快的时候进到A组件，用户进到A组件是不是要加载，A加载同时B组件还没回来，用户切换到其他页面，所以就报错了。

接口异常归档，这一块也是总结了很多，我不知道大家有没有发现，小程序对接口是有一些差异，有接口的状态是在IOS里面100%的去报，但是安卓里面没有，但是有一些状态在安卓里面100%会报，但是IOS是没有，这是我们在做这些过程当中总结出来的经验帮助进行调整。这里面可能含义是一样，这一块需要大家注意，包括怎么去解决，怎么去做。

灾备降级，是当我们小程序项目业务流程中出问题问题，导致不能正常使用时？还有政策需要快速调整小程序不能及时上线？……，怎么办？

用H5去代替小程序可以快速切换到H5站点。 我相信大家在做小程序都有一个公众号的站点，而且公众号的站点，H5站点跟小程序大部分的流程都一样，都很接近，那这样就可以快速切换到公众号里面的一个站点。

近期我不知道大家有没有发现小程序里面有一年三次快速上线的审核这个挺好，大家悠着点用，放在最重要的时候用。但是平时基本也要两个小时左右，快的话也要一个小时的，降级为H5快速上线这个是有必要的。

我们可以看一下效果，大家可以看一下效果，这是小程序原生的，假如说小程序原生出了问题，现在我们切，大家可以看到上面有一个滚动条，先其实已经切到H5的，效果也很好，跟我们原身小程序效果基本上没有什么多大区别，区别就是多看到一个滚动条，这是我们这一套灾备的方案至少可以保证我们业务主流程可以正常运行，给用户更好的一个体验。今天我的分享就至此，谢谢大家。

Q：您好老师，有一个问题因为是关于监控大量数据存储的问题大量数据存储一方面涉及到业务存储问题，但是可能过去一年数据找不到，这两者之间怎么进行平衡？

A：这个问题问得很好，最多保持三个月，这三个月过后存到哪里存到机械硬盘里面，就是你可以拉得慢一点成本就下来了。

Q：谢谢，我想再问一个问题，刚才看到您介绍一些监控数据打点的一些采集，这些数据采集以及与正常业务流程怎么权衡之间的一些权限怎么做到不影响业务流程？

A：你这个问题问得也很好，我们所有这些都是在核心业务之后无论是SDK加载数据也好还是采集出来数据发展的机制以后，都是基于主流业务以后，哪怕丢了也没关系因为是监控。