编者按：本文是蚂蚁集团前端工程师步悠在 SEE Conf 2022 的演讲内容，包括演讲视频及文字内容，欢迎享用。

开场 

大家好，我是来自蚂蚁财富基金技术组的步悠，今天我给大家分享的主题是：如何打造业务专属的 Can I use。我的分享主要分为：背景、方案、数据结论和后续探索四个部分。

背景：支付宝客户端兼容性问题

第一部分是背景，由于浏览器对 Web 标准的不同实现导致了兼容性问题的产生，而随着浏览器和标准的不断演进，兼容性问题越发突出，处理和规避兼容性问题成了前端工程师重要工作之一，那么我们日常是如何处理兼容性问题的呢？

Can I use 是我们处理兼容性问题的重要依据之一，它通过和浏览器厂商合作，获取到前端方法的兼容性以及浏览器在全球的使用占比情况，但是通过这份数据我依然无法判断前端方法是否能在支付宝客户端上使用，因为支付宝客户端是使用 UC 内核作为浏览器 WebView 内核，而 UC 内核对前端方法进行了特定的支持和剪裁，这就导致了支付宝客户端的兼容性和浏览器的兼容性有一定的差异，另外对在低版本浏览器上不支持的方法，由于无法确定低版本浏览器在支付宝端占比情况，也无法判断是否能忽略低版本浏览器。

基于上述问题，我考虑实现一个支付宝的 Can I use。

方案：支付宝客户端上进行探测

我的整体方案是在支付宝客户端上进行 Can I use 的探测，这样获取的结果是最真实可靠且贴近业务的。方案的流程分为四个部分：首先在服务端上进行探测脚本的开发并将其上传托管获得探测脚本的 URL，将其下发到支付宝客户端，当用户进入支付宝打开特定页面时，会自动执行探测脚本并将结果通过监控平台上报落入离线数据表中，对离线的数据进行开发后回流到实时数据库中，最终从实时数据库中拉取数据对兼容性结果进行可视化展示。

关键点1: 样本充足

这个方案有几个关键点给大家分享一下，首先要做支付宝 Can I use，需要保证数据量充足，那么刚好我所在的大理财业务是支付宝流量最大的业务之一，它覆盖的用户数、操作系统版本和机型都非常广泛，这为支付宝 Can I use 的探测提供了前提条件。

关键点2: 脚本开发

有了这个前提之后，需要做的就是脚本开发，这里所说的脚本实际上就是断言，可以通过编码获得预期结果的都能断言，因此除了常规的 JS 、CSS、 HTML 断言以外，我们还支持如 GPU、WebGL、屏幕尺寸等自定义断言，也因为结构化处理，使得其扩展性很好，添加一个断言，T+1 即能产出探测结论。

关键点3: 业务隔离

方案的第三个关键点是要探测不能影响到正常业务代码，因此需要做业务隔离，业务隔离分为两个部分，第一是代码隔离，我通过创建一个空的 iframe，将探测脚本绑在 iframe 的 window 上执行，这样一方面隔离了业务代码的执行环境，另一方面隔离了业务代码添加的 Polyfill 对探测结果的污染；业务隔离的第二部分是发布隔离，探测脚本的发布不能影响业务发布，发布隔离是通过在第三方服务端上开发脚本并将其上传到 oss 上，再利用蚂蚁的工具将代码托管生成固定链接，这样无论如何修改探测代码，探测地址都不变，因此就做到了探测脚本发布和业务发布的相互独立。

关键点4: 大数据处理

方案的第四个关键点是大数据的处理，在客户端上报的时候，为了节省流量，将所有的探测结果进行了聚合上报，分析结果的时候需要将数据进行拆分，拆分完的数据是亿级的数据，很显然这样大规模的数据无法直接展示，因此这里我对数据进行了处理，通过层层聚合汇总，最终将亿级数据缩减成万级别，然后回流到实时数据库中，这样就能捞取数据进行展示了。

关键点5: 可视化展示

最终的数据展示效果如图所示，相比 Can I use，支付宝 Can I use 聚焦在移动端兼容性上，它直观给出了支持度用户占比情况，另外前文也提到过支付宝使用 UC 内核作为 WebView 内核，这里支付宝 Can I use 按照 UC 内核聚合兼容性结果，基于这份数据，对于支付宝的开发者来说就能非常方便的判断出前端方法是否可用。

举个例子，网上关于 sticky 兼容性讨论很多，主要是因为 sticky 在 Chrome 上的兼容性很差，看 Can I use 能知道是 sticky 从 Chrome 56 开始支持的，但是不知道支付宝使用的 Chrome 版本是多少，也不知 Chrome 56 以下在支付宝的占比是多少，所以很难判断 sticky 到底能否在支付宝上使用，而支付宝 Can I use 明确给出了它在支付宝上的支持度超过了 99.99%，所以能判断 sticky 在支付宝上是可用的。

数据结论:  有趣的数据发现

经过一段时间的探测之后，支付宝 Can I use 积累了大量的数据，通过数据分析发现了一些比较有趣的数据结论，这里给大家分享一下。

1. 总结性结论

目前已经没有 iOS 8.0 以下和 Chrome 40 以下的用户了，无需考虑这些极低手机的兼容性，其实数据变化非常快，2020 年还能看到一些 iOS 7.0 以下的用户，到 2021 年就已经没有了；另外支付宝完全支持所有的 ES5 属性，ES6 的支持度超过了 99%，随着时间推移，支持度会越来越高。 2. 浏览器不支持，支付宝支持

除了总结性的结论，也发现了一些特殊的情况：浏览器本身不支持但是支付宝对其进行了特殊的支持，比如 Promise.finally 这个方法从 Can I use 看，它是从 Chrome 63 开始支持的，但是支付宝 Can I use 探测出来它从 UC4 2.0 即 Chrome 57 就开始支持了，经过数据分析发现支付宝初期不支持，后来对这个方法进行了特殊的支持，所以从数据上看有 0.5% 的老版支付宝不支持，后来升级了支付宝版本的的都支持了。

3. 浏览器支持，支付宝不支持      

除了对某些方法进行了特殊支持以外，也有本身浏览器是支持的，但是因为支付宝自身的原因导致没有支持的情况，比如 String.normalize 这个方法，从左边 Can I use 看它从 Chrome 34 就支持了，但是支付宝 Can I use 探测发现，加载到 UC 内核的手机均不支持的情况。 4. 屏效分析

除了兼容性问题以外，页面屏效也与前端工程师息息相关，屏效简单来说就是屏幕信息的转化率，通常第一屏的转化是远高于第二屏的，而屏幕纵横比越高的手机能传递的信息越多，也就是第一屏可见的内容越多，基于这个事实，为了提升页面的屏效，我利用探测到的屏幕纵横比数据做了屏效分析工具。如图所示，屏效分析工具左边给出了屏幕纵横比占比前 10 的数据以及对应的典型机型，右边上传视觉稿即可得出页面的屏效，黑线标注了屏幕纵横比及可见用户占比，比如第一个红箭头的位置，对应的屏幕纵横比是 1.779，超过 99% 的用户都能看到这个位置，而第二个红箭头的位置仅有 52% 的用户可见，那么对于重要转化按钮或者任务模块，可以进行适当的调整位置，提升屏效，进而提高业务转化。

后续探索：未来小畅想

数据分析就讲到这里，最后讲下关于支付宝 Can I use 的后续探索。目前的数据分析维度是按照 JS、CSS、HTML 这种大类来的，后续期望按照 ES 版本、 Array、Object 方法等多维度去分析数据，从而得出更加有效的数据结论。另外由于探测数据按日进行滚动探测的，探测的数据都存储在离线表中，拉长时间维度来看，可以进行浏览器、前端api兼容性的演进趋势分析。最后，日常工作中因为忘了添加 Polyfill 导致页面不可用，或者全量引入 Polyfill 导致页面体积过大性能较差的问题时有发生，基于支付宝 Can I use 的数据，可以按照 UC 内核、iOS 版本维度进行数据分层，定制兼具性能和可用性的 Polyfill.io 的最佳实践。

回顾一下

最后回顾一下，如果你也想定制自己业务的 Can I use，可以按照下面四个步骤：首先进行探测脚本的开发，开发完成之后下发到业务，进行探测并将探测结果上报，对上报的数据进行开发清洗，最终通过可视化的方式将结果展示出来。 是不是很简单呢？那么我今天的分享就到这里，有问题的小伙伴可以联系我，谢谢大家。