# 怎样算复杂？

相信经常看我写的性能相关文章的小伙伴都知道，复杂的前端应用、大型前端应用这个词经常会出现在我的文章里。

是的，我经常说像在线文档、在线表格这样的应用是很复杂的大型应用，但是具体是复杂在哪呢？代码量大算复杂吗？模块很多算复杂吗？功能繁杂又该怎么定义呢？

在我们的工作里，也经常会提到一些网页之所以卡顿、加载慢，是因为它很复杂。但是，我们只能用“复杂”二字来概括所有的无法精细描述和量化的场景吗？

# 关于网页复杂度的畅想

关于复杂度，相信所有开发都了解这个词。在计算机领域，复杂度常常出现在程序算法中，主要包括：时间复杂度、空间复杂度。

我们衡量不同算法之间的优劣主要是通过时间和空间两个维度去考量：

如果将一篇网页的体验视作一组算法题目，那么其中需要考虑的同样包括了时间和空间两个维度。我们可以同样地用复杂度来定义其中的解法，同样包括时间和空间两个维度：

之前在《前端性能优化--网页质量得分》一文中，有介绍跟进一些用户体验的影响指标，来建设网页的质量得分数据。

基于该体系之上，我们可以根据大盘得分情况，捞取体验得分低的网页进行分析，获取其中的一些共同特征。通过可量化的方式，来搭建该特征与得分之间的大盘数据关系图，验证是否为网页质量得分的影响因子。

比如，在线文档的使用体验可能与文本内容数量、文档内容类型等情况有关系，在线表格则可能与单元格数量、单元格类型等情况有关系。我们可以根据实际的使用体验、用户反馈，再结合大盘数据来验证这些影响因子是否正确，再慢慢探索其中可量化的关系。

通过这样的方式，我们得到了网页质量得分（即用户访问和使用体验）的影响因子，它们同时也会是我们做复杂度定义的一些影响因素了。

找到影响因子之后，我们可以慢慢探索影响因子与复杂度之间的关系，并且尝试使用可量化可计算的方式来对复杂度进行表达。

我们知道，算法中时间复杂度是指执行这个算法所需要的计算工作量，其复杂度反映了程序执行时间「随输入规模增长而增长的量级」。

在网页的场景中，我们将时间复杂度定义为「随网页内容数量规模增长而增长的量级」。其中，根据浏览器渲染的原理和常见的性能优化经验，我们可猜测时间复杂度的一些影响因素：

网页 DOM 元素数量：该因素可定义为常数项。在理想情况中，用户体验不应该受到网页元素数量的影响（因为大多数都会做首屏渲染和分片渲染），即仅有一屏内容和 10 屏、20 屏内容的网页体验相近，因此时间复杂度理想情况下应该为常数，但现实中显然不是这样。
网页打开性能影响因素：首屏内容数量、首屏不同类型的内容数量。
页面重排重绘次数。

空间复杂度主要指执行算法所需内存的大小，用于对程序运行过程中所需要的临时存储空间的度量。

在网页的场景中，与空间复杂度相关的主要有：

假设我们认为网页 DOM 元素数量会同时影响网页的时间复杂度和空间复杂度，那么我们可以捞取大盘数据来验证当中的关系，并尝试使用函数关系来表达复杂度的定义。

在多次摸索和验证后，我们将能得到一个较完整的复杂度定义公式。我们可以通过复杂度的计算，来捞取大盘上复杂的网页内容，并且可验证复杂度和得分质量会呈负相关，即复杂度越高的网页，质量得分会越低。

或许有些人会很困惑，我们得到了这样一个复杂度指标也好，质量得分数据也好，似乎也都没啥意义。

很多时候，我们都觉得一些指标或许不能代表什么，也经常会执着于它的准确精确与否。但除此之外，对于大盘用户的现状，往往也只能用“机器性能差”、“复杂”等字眼来描述，而可量化则是我们验证许多方案有效性的重要前提。