我们这样做容器分层性能测试

前言

目前闲鱼不少业务正在从H5/Weex升级到Kun（基于W3C标准&Flutter打造的混合高性能终端容器），从测试角度来看，我们希望这种升级迭代对于用户体验是正向的，所以用好性能测试这把标准尺就显得格外重要。

早期做性能保障时，我们在一些核心场景要上线或者上线之后遇到问题时，才去跑一些性能测试，这种方式只知道性能变差了，至于差在哪里，就只能反推开发去查问题，效率低且容易出问题。今年我们提出了基于容器分层的性能测试，目的是提前将性能风险点抛的更前置、更明确，特别对于Kun，除了容器本身的影响，Flutter引擎也会影响性能体验。

我们要测什么

性能指标对齐

在确定我们要做性能分层测试后，第一个问题就随之而来——性能测试到底要测什么，什么样的指标才能够去衡量一个页面的好坏。我们有两个选择：A、业界通用的指标，和友商APP的度量标准对齐；B、开发打点，测试侧对数据进行清洗；我们毫不犹豫选择了方案A，因为我们期望的性能测试并不只是在闲鱼内部赛马，而是说这些数据也能与友商以及业界标杆APP看齐，追求更加极致的用户体验。最终我们KO确定的指标如下：

我们对现有的主干业务场景以及技术栈进行了梳理，并结合核心的业务场景和关键能力组件，建立对于引擎电商领域核心的数据观察策略，沉淀各个能力层和领域层度量体系，用于衡量在各个领域层开展相关性能优化取得的效果。

1. 1. 明确基于Flutter引擎层，对齐Flutter页面和Kun页面的度量体系标准；

2. 2. 分别基于组件层面和核心业务，搭建benchMark测试场景；

3. 3. 回归业务，从核心业务层观测判定性能优化结果