SDK 体积与性能优化实践举例解释篇

逃离我推掉我的手 2024-04-01 11:15 83阅读 0赞

### **背景** ###

字节各类业务拥有众多用户群，作为字节前端性能监控 SDK，自身若存在性能问题，则会影响到数以亿计的真实用户的体验。所以此类 SDK 自身的性能在设计之初，就必须达到一个非常极致的水准。

与此同时，随着业务不断迭代，功能变得越来越多，对监控的需求也会变得越来越多。例如，今天 A 业务更新了架构，想要自定义性能指标的获取规则，明天 B 业务接入了微前端框架，需要监控子应用的性能。在解决这些业务需求的同时，我们会不断加入额外的判断逻辑、配置项。同时由于用户的电脑性能、浏览器环境的不同，我们又要解决各种兼容性问题，加入 polyfill 等代码，不可避免地造成 SDK 体积膨胀，性能劣化。那么我们是如何在需求和功能不断迭代的情况下，持续追踪和优化 SDK 的体积和性能的呢？

### **SDK 体积优化** ###

通常而言，体积的优化是最容易拿到收益的一项。

由于监控 SDK 通常作为第一个脚本被加载到页面中，体积的膨胀不仅会增加用户的下载时间，还会增加浏览器解析脚本的时间。对于体积优化，我们可以从宏观和微观两个角度去实现。

微观上，我们会去尽可能去精简所有的表达，剥离冗余重复代码，同时尽可能减少以下写法的出现：

1. 过多的 class 和过长的属性方法名

Class 的定义会被转换成 function 声明 + prototype 赋值，以及常用代码压缩工具无法对 object 属性名压缩，过多的面向对象写法会让编译后的 js 代码体积膨胀得非常快。例如下列代码

class ClassWithLongName {
        methodWithALongLongName() {}
    }

经过 ts 转换后会变成

压缩后代码为

var ClassWithLongName=function(){function n(){}return n.prototype.methodWithALongLongName=function(){},n}();

可以看到以上长命名都无法被压缩

如果使用函数式编程来代替面向对象编程，能够很好的避免代码无法被压缩的情况：