JavaScript享元模式详解：原理、DOM应用与性能优化

享元模式概述

享元模式（Flyweight Pattern）在设计模式中较为特殊，其核心目标并非单纯的结构设计，而是专注于程序性能优化。该模式特别适用于处理大量相似对象导致的性能瓶颈问题。通过深入分析应用程序中的对象结构，享元模式将对象数据拆解为“内在数据”和“外在数据”，从而大幅减少系统中实际创建的对象数量，最终提升整体运行效率。

基础概念

基础概念与角色

享元模式利用共享大量细粒度对象来降低对象总数，进而节省内存并提升应用性能。其核心在于将类似对象拆解为可共享的内在数据与不可共享的外在数据，其中持有内在数据的对象被称为享元对象。通常需配备一个工厂类以管理这些内在数据。 在JS语境下，享元模式主要包含以下角色： （1）客户端：负责调用享元工厂以获取内在数据的类，通常代表应用程序所需的具体对象。 （2）享元工厂：负责维护和管理享元数据的类。 （3）享元类：用于存储和保持内在数据的类。

实现与应用场景

JavaScript中的常规实现

常规实现方式

为了直观说明，我们以苹果公司批量生产iPhone为例。在iPhone的生产中，大部分属性如型号、屏幕尺寸是固定的，而内存容量（如16G或32G）等少数属性则有所差异。在未使用享元模式之前，代码实现可能如下所示：

function Iphone(model, screen, memory, SN) {
  this. model = model;
  this.screen = screen;
  this.memory = memory;
  this.SN = SN;
}
var phones = [];
for (var i = 0; i < 1000000; i++) {
  var memory = i % 2 == 0 ? 16 : 32;
  phones.push(new Iphone("iphone6s", 5.0, memory, i));
}

上述代码创建了一百万个iPhone实例，每个实例都独立申请内存空间。然而仔细观察可以发现，绝大多数iPhone仅内存容量和序列号不同，其余属性高度相似。若程序对性能有较高要求，这种实现方式显然存在优化空间。对于包含大量相似对象的程序，我们可以利用享元模式进行优化。通过分析，我们将型号、屏幕等相同数据视为共享的“内在数据”，并定义相应的享元类：

function IphoneFlyweight(model, screen, memory) {
  this.model = model;
  this.screen = screen;
  this.memory = memory;
}

我们定义了iPhone的享元类，该类包含型号、屏幕和内存三个核心数据属性。此外，还需要一个享元工厂来维护这些共享数据：

 var flyweightFactory = (function () {
  var iphones = {};
  return {
    get: function (model, screen, memory) {
      var key = model + screen + memory;
      if (!iphones[key]) {
        iphones[key] = new IphoneFlyweight(model, screen, memory);
      }
      return iphones[key];
    }
  };
})();

在该工厂中，我们使用字典（对象）来存储已创建的享元对象，并提供一个获取方法。当请求获取享元对象时，若字典中已存在相同参数的对象，则直接返回该对象；否则，创建新对象并返回。接着，我们构建一个客户端类，该类由原有的iPhone类修改而来：

 function Iphone(model, screen, memory, SN) {
  this.flyweight = flyweightFactory.get(model, screen, memory);
  this.SN = SN;
}

随后，我们依然按照之前的逻辑生成多个iPhone实例：

var phones = [];
for (var i = 0; i < 1000000; i++) {
  var memory = i % 2 == 0 ? 16 : 32;
  phones.push(new Iphone("iphone6s", 5.0, memory, i));
}
console.log(phones);

优化的关键在于Iphone构造函数中的 `this.flyweight = flyweightFactory.get(model, screen, memory)` 这一行代码。通过调用享元工厂获取共享数据，工厂会在内部检查是否存在相同数据的对象。若存在，则直接返回引用，使得多个iPhone实例共享同一份内在数据。这种机制大幅减少了重复数据的内存占用，从而实现了性能优化。

DOM事件委托中的应用

DOM中的应用场景

享元模式在Web开发中的一个典型应用是DOM事件处理。DOM事件机制包含事件冒泡和事件捕获两种模式。简要介绍如下： 事件冒泡：事件从最内层的元素开始触发，逐层向上传播至最外层元素。 事件捕获：事件从最外层的元素开始触发，逐层向下传播至最内层元素。 假设HTML中存在一个菜单列表：

<ul class="menu">
  <li class="item">选项1</li>
  <li class="item">选项2</li>
  <li class="item">选项3</li>
  <li class="item">选项4</li>
  <li class="item">选项5</li>
  <li class="item">选项6</li>
</ul>

点击菜单项执行相应操作时，使用jQuery绑定事件的常规做法如下：

$(".item").on("click", function () {
  console.log($(this).text());
})

为每个列表项单独绑定事件，点击时输出对应文本。这种写法在列表较短时看似无问题，但在移动端或长列表场景中，每个项都绑定独立事件会导致严重的性能问题，因为每个事件处理程序都会占用内存。鉴于这些事件处理程序逻辑高度相似，我们有必要对其进行优化。

$(".menu").on("click", ".item", function () {
  console.log($(this).text());
})

通过上述方式绑定事件，可以显著减少事件处理程序的数量，这种方法称为“事件委托”，其本质也是享元模式的应用。在这里，事件处理程序是公用的“内在部分”，而每个菜单项的具体文本则是“外在部分”。事件委托的原理简述如下：点击菜单项时，事件会从li元素冒泡至ul元素。我们将事件绑定在ul上，实际上只绑定了一个事件处理器。通过事件参数 `event` 中的 `target` 属性，我们可以判断具体点击的是哪个元素（例如第一个li元素，此时 `event.target` 指向该li）。据此，我们可以针对不同元素执行不同的处理逻辑。

总结与适用场景分析

总结

享元模式是一种旨在优化程序性能的设计手段。它通过共享公用数据来减少对象数量，从而提升系统效率。该模式特别适用于拥有大量相似对象且对性能有严格要求的场景。然而，由于享元模式需要分离内部和外部数据，这增加了程序的逻辑复杂性。因此，建议仅在确实对性能有明确要求的场景下使用享元模式。

享元模式的优势： 它可以显著降低网页的资源负荷，甚至将资源消耗降低几个数量级。即使应用享元模式后实例数量无法完全削减，开发者仍能从中获得可观的收益。

这种节省无需对原有代码进行大规模修改。在创建了管理器、工厂和享元之后，需要做的修改仅涉及将直接实例化目标类改为调用管理器对象的相应方法。

享元模式的劣势： 若在不必要的地方强行应用，反而可能损害代码的运行效率。该模式在优化性能的同时，也提高了代码的复杂程度，这会给后续的调试和维护带来困难。

它之所以妨碍调试，是因为潜在的错误点从单一对象扩展到了三个部分：管理器、工厂和享元。

这种优化也会使维护工作变得更加复杂。开发者面对的不再是封装清晰数据的对象架构，而是一堆分散且杂乱的数据结构。数据至少分布在两个地方存储，因此最好通过注释明确标注哪些是内在数据，哪些是外在数据。

只有在必要时才应进行此类优化。必须在运行效率和可维护性之间做出权衡。如果不确定是否需要使用享元模式，那么很可能并不需要它。该模式最适合的场景是系统资源已接近瓶颈，且明显需要进行某种优化的情况。

这种模式对JavaScript程序员尤为有用，因为它可以用来减少网页上DOM元素的数量，而DOM元素往往消耗大量内存。结合组合模式等组织型模式，可以开发出功能丰富且复杂的Web应用系统，这些系统能够在任何现代JavaScript环境中平稳运行。

享元模式的适用场合： 网页中必须使用了大量资源密集型对象。如果仅使用少量此类对象，这种优化并不划算。

对象中所保存的数据至少有一部分能被转化为外在数据。此外，将这些数据存储于对象外部所占用的资源应相对较少，否则这种做法对性能的提升实际上毫无意义。那些大量包含基础性代码和HTML内容的对象可能比较适合这种优化策略。

将外在数据分离出去后，独一无二的对象数目应相对较少。