无处不在,搜你所想

第一篇 问题阐述

我有一个看似简单的任务:“从后台检索到一个数据集，其中包含13000个数据项，每个数据项都是一个冗长的名称(科学组织)。使用这些数据创建一个带自动填充搜索栏的功能。”

你也不觉得很难，对不对？

难点1：

不能使用后端。后端只能提供原始数据集，所有的搜索逻辑都必须在前端完成。

难点2：

开发人员（我）：“这些组织的名称很长，需要考虑一下。如果我们只是运行一个简单的字符串匹配，用户可能会键入错误或拼写错误，很难找到任何结果。”

客户：你说得对，我们必须添加一些智能功能来预测用户输入，并忽略输入错误。

注意：在正常情况下，我不建议您在没有得到项目经理同意的情况下，就向客户提示未提及的复杂功能!这种情况称为特征蔓延（feature creep）。在上面的例子中，恰好是我负责这个合同，我有足够的精力，所以我认为这是一个有趣的挑战。

问题3:

这是最大的困难。我选择的智能(也称为“模糊”)搜索引擎很慢……

随着搜索项长度的增加，该搜索算法库的搜索时间将迅速增加。此外，看看下面的巨大列表，其中的数据项非常长，用户需要输入一个长搜索项才能自动填充提示。没有别的办法，搜索引擎跟不上用户的打字速度，这个UI可能会被取消。

我不知道是不是因为我选择的搜索算法库太差了。我不知道是不是因为所有的“模糊”搜索算法都是这样的。幸运的是，我没有费心去寻找其他的选择。

虽然以上的大部分困难都是我自己造成的，但我还是决定坚持下去，尽量优化这个实现。虽然我知道这可能不是最好的策略，但是这个项目的情况允许我这样做，结果会说明一切，最重要的是，这对我来说是一个很好的学习经验和成长机会。

第二篇 问题剖析

在第一个实现中，我使用了UI的react-autocomplete和react-virtualized库。

render () {
    return (
      <Autocomplete
        value={this.state.searchTerm}
        items={this.getSearchResults()}
        renderMenu={this.reactVirtualizedList}
        renderItem={this.renderItem}
        getItemValue={ item => item.name }
        onChange={(e, value) => this.setState({searchTerm: value})}
      />
    )
  }

Autocomplete组件需要传递以下几项：value属性，需要传入输入框中的searchTeam；items属性，传入搜索结果；以及renderMenu函数，该函数将搜索结果列表传递给react-vertualized。

react-virtualized能够很好地处理大型列表（它只会渲染列表显示在屏幕上的一小部分，只有滚动列表时才会更新）。考虑到我们需要渲染的组件并不多，我认为应该不会有太严重的性能问题。

更新操作的声明周期也很简单：

• 用户输入'a'

• Autocomplete的onChange处理函数触发一次渲染，此时this.state.searchTeam = 'a'

• 该渲染会调用getSearchResults方法，在这个方法中，搜索引擎使用'a'作为搜索关键字计算搜索结果，然后将结果传递给react-virtualized负责渲染。

我们来看看结果如何：

哎呀……很糟。在按住删除键时的的确确能感觉到UI的停顿，因为键盘触发delete事件太快了。

但至少模糊搜索很容易使用:“anerican”被正确地解释为“American”。但是随着搜索关键字的增长，这两个元素(输入框和搜索结果)的渲染过程完全跟不上用户输入的速度，延迟非常大。

虽然我们的搜索算法真的很慢，但是这么大的延迟并不是因为一次搜索时间太长。这里还有另一个需要理解的现象:我们称之为UI阻塞。理解这种现象需要深入了解Chrome的DevTools性能度量工具。

性能评测

您可能不熟悉这个工具，但是您应该知道，精通性能测试工具是深入了解JavaScript的最佳方法。这不仅是因为它提供了有用的信息来帮助您解决各种问题，而且还表明JavaScript执行时间可以帮助您更好地理解良好UI、React、JavaScript事件循环、同步异步执行的概念。

在下面的每一部分中，我将给出一个性能分析过程，并从这些过程中推断出有趣的结论。这些数据可能会让你眼花缭乱，但我会试着给出一个合理的解释!

首先评测一下在Autocomplete中按下两个键时的情况：

首先是用户的键盘输入（Key Characer）。这些输入在JavaScript的主线程上触发了Event(keypress)事件，该事件又触发了我们的onChange处理函数，该函数会调用setState（图上看不见，因为它太小了，但它的位置在整个栈的最开头附近）。这一系列动作标志着重新计算的开始，计算setState对组件会产生何种影响。这一过程称为更新，或者叫做重新渲染，它会调用几个React生命周期方法，其中就包括render。这一切都发生在一个执行栈（有时称为“调用栈”或简称为“栈”），在图中由每个Event (keypress)下方竖直排列的框表示。每个框都是执行栈中的一次函数调用。

这里不要被render这个词误导了。React的渲染并不仅仅是在屏幕上绘制。渲染只是React用来计算被更新的元素应当如何显示的过程。如果仔细查看第二个Event (keypress)，就会发现在Event (keypress)框的外面有个小得几乎看不见的绿条。放大一些就能看到这是对浏览器绘制的调用：

这是将UI更新实际绘制到屏幕上并在屏幕上显示新框架的过程。此外，第一个事件(按键)不是在第二个事件之后绘制的，而是在第二个事件之后绘制的。

这意味着浏览器呈现(外观更新)不一定发生在事件(按键)发生并完成更新之后。

原因是JavaScript的事件循环和任务队列的JavaScript优先级处理。在React完成计算并向DOM写入更新(称为提交阶段，发生在每个执行堆栈的末尾)之后，您可能认为浏览器应该开始绘图并在屏幕上显示DOM更新。但是在绘图之前，浏览器将检查JavaScript事件队列中是否有其他任务，并且一些任务将优先于绘图。

当JavaScript线程忙于呈现第一个按键并生成第二个用户输入(例如键盘按键事件)时，就会发生这种情况(您可以看到第二个按键字符输入发生在第一个按键执行堆栈上)。在运行时)。这就是前面提到的UI阻塞。第二个事件(按键)阻止UI更新第一个按键。

不幸的是，这可能导致巨大的延迟。由于呈现本身非常慢(部分原因是呈现包含昂贵的搜索算法)，如果用户输入非常快，很可能在前一个执行堆栈结束之前输入一个新字符。这将生成一个新的事件(按键)，它的优先级比浏览器绘制的要高。所以绘图会被用户的输入延迟。

不仅如此，甚至在用户停止键入之后，队列中仍然有大量的按键时间，React需要依次计算每个按键。因此，即使输入已经完成，您也必须等待这些搜索，以找到您不需要的搜索团队!

注意最后一个Key Character发生后，还有4个Event (keypress)滞留，浏览器需要处理完所有事件才能重绘。

改进方法

为了解决这个问题，重要的是要理解好的UI的要素是什么。实际上，对于每次键盘输入，用户期待的视觉反馈包括两个独立的要素：

• 用户输入的键显示在输入框中；

• 搜索结果根据新的searchTeam进行更新。

理解用户的期望才能找到解决方案。尽管Google搜索快得像闪电一样，但用户无法立即收到搜索结果的事情也屡见不鲜。一些UI甚至会在请求搜索结果时显示加载进度条。

重要的是要理解，对于反应迅速的UI而言，第一种反馈（按下的键显示在输入框中）扮演了非常重要的角色。如果UI无法做到这一点，就会有严重的问题。

查看性能评测是解决问题的第一个提示。仔细观察这些长长的执行栈和render中包含的昂贵的search方法，我们会发现，更新输入框和搜索结果的一切操作都发生在同一个执行栈内。所以，两者的UI更新都会被搜索算法阻塞。

但是，输入框的更新不需要等待结果！它只需要知道用户按下了哪个键，而不需要知道搜索结果是什么。如果我们有办法控制事件执行的顺序，输入框就有机会先更新UI，再去渲染搜索结果，这样就能减少一些延迟。因此，我们的第一个优化措施就是将输入框的渲染从搜索结果的渲染中分离出来。

注意：熟悉Dan Abramov在React JSConf 2018上的演讲的人应该能回忆起这个场景。在他的幻灯片中，他设计了一个昂贵的更新操作，随着输入值的增加，屏幕上需要渲染的组件也越来越多。这里我们遇到的困难非常相似，只不过是随着搜索关键字长度的增加，单个搜索函数的复杂度会增加而已。在Dan的演讲中，他演示了时间切片（Time Slicing），这个React团队在开发中的功能也许可以解决这个问题！我们的尝试会以相似的方案解决问题：找到一个方法来改变渲染的顺序，防止昂贵的计算再次阻塞主线程的UI更新。

第三篇 异步渲染（componentDidUpdate）

注意：本篇讨论的优化最后以失败告终了，但我认为值得讲一讲，因为它能帮助我们更好地理解React的componentDidUpdate生命周期。如果你非常熟悉React，或者只想看看怎样改善性能问题，那么可以直接跳到下一篇。

拆分组件

由于我们想把昂贵的搜索结果更新从输入框更新中拆分出来，所以我们应该自己设计一个组件，并放弃使用react-autocomplete库提供的一站式解决方案Autocomplete：

render () {
  return (
    <div>
      <input
        onChange={ e => this.setState({searchTerm: e.target.value})}
        value={this.state.searchTerm}/>

      <SearchResults
        searchEngine={this.props.searchEngine}
        searchTerm={this.state.searchTerm}/>
    </div> 
  )
}

然后在SearchResults中，我们需要异步触发searchEngine.search(searchTerm)，而不应该在更新searchTerm的同一个渲染中进行。

我最初的想法是利用SearchResults的componentDidUpdate，让searchEngine异步工作，因为听上去这个方法似乎是在更新之后异步执行的。

//searchResults.js

componentDidUpdate(prevProps) {
  const {searchTerm, searchEngine} = this.props;
  if(searchTerm && searchTerm !== prevProps.searchTerm) {
    this.setState({
      searchResults: searchEngine.search(searchTerm)
    })
  }
}

render () {
  return <ReactVirtualizedList searchResults={this.state.searchResults}/>
}

我们将昂贵的searchEngine移动到了componentDidUpdate中，这样就不用在render方法中调用，而是等到更新之后再执行。我希望在输入框更新之后的另一个执行栈中执行render，并两者之间执行一次绘制。我想象的新的更新生命周期如下：

• 输入框使用新的searchTerm渲染；

• React把带有新的searchTerm的componentDidUpdate searchEngine任务放入队列；

• 浏览器绘制输入框的更新，然后处理队列中的searchEngine任务。理论上，浏览器不会把这个任务放在绘制任务之前，因为它不涉及用户交互事件；

• componentDidUpdate在输入框绘制之后执行，计算搜索结果并生成新的更新。

很不幸，认为componentDidUpdate会在浏览器更新之后运行是一个常见的误解。我们来看看这个方法的性能评测：

看到问题了吗？componentDidUpdate跟最初的keypress事件是在同一个执行栈上执行的

componentDidUpdate并不会在绘制结束后执行，因此执行栈跟上一篇一样昂贵，我们只不过是将昂贵的search方法移动到了不同位置而已。尽管这个解决方案并不能改善性能，但我们可以借此机会理解React的生命周期componentDidUpdate的具体行为。

虽然componentDidUpdate不会在另一个执行栈上运行，但它确实是在React更新完组件状态并将更新后的DOM值提交之后才执行的。尽管这些更新后的DOM值还没有被浏览器绘制，它们依然反映了更新后的UI应有的样子。所以，任何componentDidupdate内执行的DOM查询都能访问到更新后的值。所以，组件确实更新了，只是浏览器中看不见而已。

所以，如果想要做DOM计算，一般都应该在componentDidUpdate中进行。在这里很方便根据布局改变进行更新，比如根据新的布局方式计算元素的位置或大小，然后更新状态等。

如果componentDidUpdate每次触发改变布局的更新时都要等待实际的浏览器绘制，那么用户体验会非常糟糕，因为用户可能会在布局改变时看到两次屏幕闪烁。

注（React Hooks）：这个差异也有助于理解新的useEffect和useLayoutEffect钩子。useEffect就是我们在这里尝试实现的效果。它会让代码在另一个执行栈中运行，从而在执行之前浏览器可以进行绘制。而useLayoutEffect更像是componentDidUpdate，允许你在DOM更新之后、浏览器绘制之前执行代码。

第四篇 异步渲染（setTimeout）

上一篇我们拆分了组件：

//autocomplete.js

render () {
  return (
    <div>
      <input
        onChange={ e => this.setState({searchTerm: e.target.value})}
        value={this.state.searchTerm}/>

      <SearchResults
        searchEngine={this.props.searchEngine}
        searchTerm={this.state.searchTerm}/>
    </div> 
  )
}

但我们没能让昂贵的searchEngine在另一个执行栈上运行。那么，还有什么办法能实现这一点呢？

有两个常见的方法可以设置异步调用：Promise和setTimeout。

Promise

//searchResults.js

componentDidUpdate(prevProps) {
  const {searchTerm, searchEngine} = this.props;
  if(searchTerm && searchTerm !== prevProps.searchTerm) {
    /* stick the update with the expensive search method into
    a promise callback: */
    Promise.resolve().then(() => {
      this.setState({
        searchResults: searchEngine.search(searchTerm)
      })
    })
  }
}

render () {
  return <ReactVirtualizedList searchResults={this.state.searchResults}/>
}

我们来看看性能评测：

 (anonymous)是Promise.then()回调函数

又失败了！

理论上Promsie的回调函数是异步的，因为它们不会同步执行，但实际上还是在同一个执行栈中运行的。

仔细看看性能评测就会发现，回调函数被放在了Run Microtasks下，因为Promise的回调函数被当作了微任务。浏览器通常会在完成正常的栈之后检查并运行微任务。

更多信息：Jake Archibald有一篇非常好的演讲（https://medium.com/r/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DcCOL7MC4Pl0），解释了JavaScript事件循环在微任务方面的处理，还深入讨论了许多我涉及到的话题。

尽管了解这一点很好，但并没有解决问题。我们需要新的执行栈，这样浏览器才有机会在新的执行栈开始之前进行绘制。

setTimeout

//searchResults.js

componentDidUpdate(prevProps) {
  const {searchTerm, searchEngine} = this.props;
  if(searchTerm && searchTerm !== prevProps.searchTerm) {
    /* stick the update with the expensive search method into
    a setTimeout callback: */
    const setTimeoutCallback = () => {
      this.setState({
        searchResults: searchEngine.search(searchTerm)
      })
    }
    setTimeout(setTimeoutCallback)
  }
}

render () {
  return <ReactVirtualizedList searchResults={this.state.searchResults}/>
}

性能评测：

绘制很难看到，它太小了，但蓝线的位置的确发生了绘制

哈哈！成功了！注意到这里有两个执行栈：Event (keypress)和Timer Fired (searchResults.js:49)。两个栈之间发生了一次绘制（蓝线的位置）。这正是我们想要的！来看看漂亮的UI！

按住删除键时依然有明显的延迟

有很大的改进，但依然很令人失望……这个页面的确变好了，但依然能感觉到UI的延迟。我们来仔细看看性能测试。

我们需要一些技巧才能分析这个性能测试报告并找出延迟的原因。使用性能报告有几个小技巧：

性能评测工具着重显示了两个特别有用的Key Input Interactions，每个都有不同的性能度量：

• Key Down：从键盘按下到Event (keypress)处理函数被调用的时间间隔；

• Key Character：从键盘按下到浏览器绘制更新的时间间隔。

理想状态下，Key Down交互应该非常短，因为如果JavaScript主线程没有被阻塞的话，事件应该在键盘按下之后立即出发。所以，看到长长的Key Down就意味着发生了UI阻塞问题。

在本例中，长长的Key Down的原因是它们触发时，主线程还在被昂贵的setTimeoutCallback阻塞，比如最后的Key Down。很不幸，Key Down发生时，运行昂贵的search的setTimeoutCallback刚刚开始，也就是说，Key Down只有等待search的计算结束才能触发事件。这个评测中的search方法大约花了330毫秒，也就是1/3秒。从优秀的UI角度而言，1/3秒的主线程阻塞实在太长了。

特别引起我注意的是最后一个Key Character。尽管它关联了Key Down的结束并且触发了Event (keypress)，浏览器并没有绘制新的searchTerm，而是执行了另一个setTimeoutCallback。这就是Key Character交互花了两倍时间的原因。

这一点着实让我大跌眼镜。将search移动到setTimeoutCallback的目的，就是让浏览器能够在调用setTimeoutCallback之前进行绘制。但是在最后的Event (keypress)之前依然没有绘制（蓝线的位置）。

结论是，我们不能依赖于浏览器的队列机制。显然浏览器并不一定将绘制排在超时回调之前。如果超时回调需要占用主线程330毫秒，那么也会阻碍主线程，导致延迟。

第五篇 多线程

在上一篇中，我们拆分了组件，并成功地使用setTimeout将昂贵的search移动到了另一个执行栈中，因此浏览器无需等待 search完成，就可以绘制输入框的更新：

//searchResults.js

componentDidUpdate(prevProps) {
  const {searchTerm, searchEngine} = this.props;
  if(searchTerm && searchTerm !== prevProps.searchTerm) {
    /* stick the update with the expensive search method into
    a setTimeout callback: */
    const setTimeoutCallback = () => {
      this.setState({
        searchResults: searchEngine.search(searchTerm)
      })
    }
    setTimeout(setTimeoutCallback)
  }
}

render () {
  return <ReactVirtualizedList searchResults={this.state.searchResults}/>
}

不幸的是，这依然没有解决每个searchTerm导致search阻塞主线程330毫秒并导致UI延迟的问题。

JavaScript的单线程实在太糟糕了……突然我想到了一个方法。

最近我在阅读渐进式Web应用，其中有人使用Service Worker来实现一些过程，比如在另一个线程中进行缓存。于是我开始学习Service Worker。这是一个全新的API，我需要花点时间来学习。

但在学习之前我想先通过实验来验证一下增加额外的线程是否真的能够提高性能。

用服务器端来模拟第二个线程

我以前就做过搜索和自动补齐提示的功能，但这次特别困难的原因是需要完全在前端实现。以前我做过用API来获取搜索结果。其中一种思路是，API和运行API的服务器实际上相当于前端应用利用的另一个线程。

于是，我想到可以做一个简单的node服务器让searchTerm访问，从而实现在另一个线程中运行昂贵的搜索。这个功能非常容易实现，因为这个项目中已经设置过开发用的服务器了。所以我只需添加一个新的路径：

app.route('/prep-staging/testSearch')
  .post(bodyParser.json(), (req, res) => {

    const {data, searchTerm} = req.body

    const engine = new SearchEngine(data)

    const searchResults = engine.search(searchTerm)

    res.send({searchResult})
  })

然后将SearchResults中的setTimeout改成fetch：

//searchResults.js

componentDidUpdate(prevProps) {
  const {searchTerm, searchEngine, data} = this.props;
  if(searchTerm && searchTerm !== prevProps.searchTerm) {
    /* ping the search route with the searchTerm and update state
    with the results when they return: */
    fetch(`testSearch`, {
      method: 'POST',
      body: JSON.stringify({data, searchTerm}),
      headers: {
        'content-type': 'application/json'
      }
    })
      .then(r => r.json())
      .then(resp => this.setState({searchResults: resp.searchResults}))
  }
}

render () {
  return <ReactVirtualizedList searchResults={this.state.searchResults}/>
}

现在是见证奇迹的时刻！

注意看删除！

太棒了！输入框的更新几乎非常完美。而另一方面，搜索结果的更新依然非常缓慢，但没关系！别忘了我们的首要任务就是让用户在输入时尽快获得反馈。我们来看看性能测试报告：

注意主线程中间漂亮的空白，它不再是之前层层叠叠的样子了。性能优化中经常会遇到这种情况。主线程中的空白越多越好！

从顶端可以看到testSearch花费的时间。最长的一个实际上花了800毫秒，让我很吃惊，但仔细想想就会发现，并不是search花了这么长时间，而是我们的Node服务器也是单线程的。它在第一个搜索完成之前无法开始另一个搜索。由于输入比搜索快得多，所以搜索会进入队列然后被延迟。搜索函数实际花费的时间是前一个搜索完成之后的部分，大约315毫秒。

总的来说，将昂贵的任务放到服务器线程中，就可以将堆叠的栈移动到服务器上。所以，尽管依然有改进的空间，但主线程看起来非常好，UI的响应速度也更快了！

我们已经证明这个思路是正确的，现在来实现吧！

做了一点研究后我发现，Server Worker并不是正确的选择，因为它不兼容Internet Explorer。幸运的是，它还有个近亲，叫做Web Worker，能兼容所有主流服务器，API更简单，而且能完成我们需要的功能！

第六篇 Web Worker

Web worker能够在JavaScript的主线程之外的另一个线程上运行代码，每个Web worker都由一个脚本文件启动。启动方式非常简单：

//searchResults.js

export default class SearchResults extends React.Component {
  constructor (props) {
    super();
    this.state = {
      searchResults: [],
    }
    //initiate the webworker:
    this.webWorker = new Worker('...path to webWorker.js')  
    //pass it the 13,000 item search data to initialize the searchEngine with:
    this.webWorker.postMessage({data: props.data})
    //assign the handler that will accept the searchResults when it sends them back:
    this.webWorker.onmessage = this.handleResults
  }

  componentDidUpdate(prevProps) {
    const {searchTerm} = this.props;
    if(searchTerm && searchTerm !== prevProps.searchTerm) {
      //change our async search request to a .postMessage, the messaging API of webWorkers:
      this.webWorker.postMessage({searchTerm})
    }
  }

  handleResults = (e) => {
    const {searchResults} = e.data
    this.setState({
      searchResults
    })
  }

  render () {
    return <ReactVirtualizedList searchResults={this.state.searchResults}/>
  }
}

下面是webWorker.js脚本，在SearchResults的构造函数中进行初始化：

//webWorker.js

self.importScripts('...the search engine script, provides the SearchEngine constructor');

let searchEngine; 
let cache = {} 
//thought I would add a simple cache... Wait till you see those deletes now :)

function initiateSearchEngine (data) {
  //initiate the search engine with the 13,000 item data set
  searchEngine = new SearchEngine(data); 
  //reset the cache on initiate just in case
  cache = {}; 
}

function search (searchTerm) {
  const cachedResult = cache[searchTerm]
  if(cachedResult) {
    self.postMessage(cachedResult)
    return
  }
  const message = {
    searchResults: searchEngine.search(searchTerm)
  };
  cache[searchTerm] = message;
  //self.postMessage is the api for sending messages to main thread
  self.postMessage(message)
}

/*self.onmessage is where we define the handler for messages recieved
from the main thread*/
self.onmessage = function(e) {
  const {data, searchTerm} = e.data;

  /*We can determine how to respond to the .postMessage from 
  SearchResults.js based on which data properties it has:*/
  if(data) {
    initiateSearchEngine(data)
  } else if(searchTerm) {
    search(searchTerm)
  }
}

可以看到，我还加了些额外的代码。这里我加了缓存，这样之前搜索过的searchTerms就可以立即返回结果了。如此一来，最耗性能的用户交互（常按删除键）的效率就提高了。

我们来看看运行情况：

太棒了……非常快！这看起来很不错啊，实话说，做到这个样子就可以直接发布了！

但是，现在就发布多没劲啊……

从用户体验的角度来说，这个UI已经非常好了。如果仔细观察，其实依然能看到搜索结果的延迟，但几乎察觉不到……不过幸运的是，从性能测试报告中可以看到低效率的地方：

请无视灰色的条，我也不知道它们是怎么来的。

报告中最左侧的线程是我们关注的线程。Main线程已经折叠了，因为里面只有大量的空白，意味着主线程的性能非常好，不会成为任何主要的性能瓶颈。

可以看到，Worker线程里堆满了search调用。从最后一个Key Character输入（蓝线位置）之后就会看到其后果。Worker线程中的最后一个search实际上推迟了3个search才返回。测量一下会发现，延迟大约有850毫秒。而且大部分都是不必要的，因为那三个search都没用，我们不再需要它们返回的结果了。

你也许在想：“这已经很好了！再优化下去性价比不高啊！”

我不这样认为。首先，不要低估尝试新事物和探索带来的价值。如果你从来没做过探索，就很可能无法评价是否值得，因为你不知道你能有哪些收获，以及你将投入多少时间和努力。所以，我认为这种探索带来的经验和知识是无价的。随着知识的积累，你能更好地评价投入的时间是否值得，以及是否应该考虑这些问题。你可以做出更好的决定！

其次，别忘了这并不是过早优化。这些优化都是根据性能评价做出的，我们可以测量出效果。不管怎样评价，如果能改善850毫秒的延迟，那都是非常重大的改进。

最后（但不是唯一），别忘了移动端！虽然我不会在本文中介绍，但我在研究这个问题时，我也跟踪了移动端的性能，现在的条件下依然有能察觉得到的性能延迟。

不管怎么说，我们来解决这个问题！

第七篇 确保searchTerm

前面的性能评测揭示的最明显的问题就是，即使对于无用的searchTerm也会运行昂贵的搜索。所以目前的解决方案之一就是在执行昂贵的搜索之前确保searchTerm是最新的。只要在webWorker脚本中加入confirmSearchTerm就可以非常容易地实现：

//webWorker.js

self.importScripts('...the search engine script, provides the SearchEngine constructor');
let searchEngine; 
let cache = {}

function initiateSearchEngine (data) {
  searchEngine = new SearchEngine(data);
  cache = {};
}
function search (searchTerm) {
  const cachedResult = cache[searchTerm]
  if(cachedResult) {
    self.postMessage(cachedResult)
    return
  }
  const message = {
    searchResults: searchEngine.search(searchTerm)
  };
  cache[searchTerm] = message;
  self.postMessage(message)
}

function confirmSearchTerm (searchTerm) {
  self.postMessage({confirmSearchTerm: searchTerm})
}

self.onmessage = function(e) {
  const {data, searchTerm, confirmed} = e.data;
  if(data) {
    initiateSearchEngine(data)
  } else if(searchTerm) {
    /*check if the searchTerm is confirmed, if not, send a confirmSearchTerm message 
      to compare the searchTerm with the latest value on the main thread */
    confirmed ? search(searchTerm) : confirmSearchTerm(searchTerm)
  }
}

这里还给SearchResults handleResults加了个额外的条件，监听confirmSearchTerm的请求：

//searchResults.js

export default class SearchResults extends React.Component {
  constructor (props) {
    super();
    this.state = {
      searchResults: [],
    }
    this.webWorker = new Worker('...path to webWorker.js')  
    this.webWorker.postMessage({data: props.data})
    this.webWorker.onmessage = this.handleResults
  }

  componentDidUpdate(prevProps) {
    const {searchTerm} = this.props;
    if(searchTerm && searchTerm !== prevProps.searchTerm) {
      this.webWorker.postMessage({searchTerm})
    }
  }

  handleResults = (e) => {
    const {searchResults, confirmSearchTerm} = e.data;
    /* check if confirmSearchTerm property was sent, if so compare it to the 
    latest searchTerm and send back a confirmed searchTerm message */
    if (confirmSearchTerm && confirmSearchTerm === this.props.searchTerm) {
      this.webWorker.postMessage({
        searchTerm: this.props.searchTerm,
        confirmed: true
      })
    } else if (searchResults) {
      this.setState({
        searchResults
      })
    }
  }

  render () {
    return <ReactVirtualizedList searchResults={this.state.searchResults}/>
  }
}

我们来看看性能评测，看看有没有改进：

很难看出结果，因为它们运行得太快了，但在每次Worker的执行栈之前都会执行confirmSearchTerm（见蓝线）。

说明的确管用了：Worker在每次运行昂贵的search方法之前都会确认搜索是否必要。而且可以看到，顶部的橙色部分有4个Key Character输入，但只运行了三个搜索。这里我们成功地去掉了一个不必要的搜索，节约了最多330毫秒。但之前我们看到，多个额外的搜索会进入队列然后再不必要地运行，而现在我们完全避免了这个问题。所以，节约的时间非常显著，特别是在移动端上。

但仔细观察就会发现我们依然在浪费时间：

最后一个搜索使用了最新的searchTerm，但依然要至少等待当前的搜索完成后才能开始。浪费了84毫秒（蓝色高亮部分）！据我所知，执行栈一旦开始就无法取消。那么我们是不是无计可施了呢？

第八篇 Web Worker阵列

如果多加一个线程的效果很好，那么加4个会怎样？

实话实说，现在这些只是出于兴趣……但说真的，最后这次优化确实在移动端上带来了人眼能察觉到的改善……

无论怎样，现在我打算用Web Worker阵列！

为了出这份报告，我用人类最快的速度输入的！

图中可以看到，顶端每个橙色的Key Character都有一个ww worker线程，能立即开始搜索（橙色条）。不再需要等待前一个搜索结束。而且每个ww在结束后就能用于下一次搜索。

这是因为我们设置了workerArray.js这个web worker作为分发器。图中看不到，因为它执行得太快了，但对于每个Key Character，workerArray都会执行一个微笑的执行栈，用来处理主线程传来的搜索请求消息，然后分发给第一个可用的ww worker。

我们成功地解决了“搜索堆”的问题。可以认为用增加车道的方式解决了交通拥堵。

为什么用4个搜索worker呢？因为我在测试时的输入速度从来没能到过需要第五个worker的速度（增加worker带来的改进非常微小）。

结果发现，从Key Character输入到search执行之间没有任何延迟。除非找到另一个更有效的搜索算法，否则我们已经成功地移除了所有性能瓶颈。

别忘了，我并没有说这是最佳的解决方案。是否每台手机都能处理4个web worker？性能改善是否值得付出这些额外的代码复杂度？是否还有其他安全方面的考量，导致代码更加复杂？

这些问题都非常重要，正是这些问题会最终引出这样的解决方案。

但至少现在，这个Web worker阵列非常优秀！我们来看看实际效果：

感谢你耐心地阅读完所有的篇节！

如果说这一系列优化有什么感想的话，那就是：

• 不要害怕尝试新事物，不要害怕不寻常的方案。

• 方案是否好用并不重要，它们带来的经验和知识才是最有价值的！

如果你有兴趣，可以看看下面Web worker阵列的代码。

课外作业

下面的代码中有个小问题。需要一个非常微小的修改才能使它更强壮，最多两行代码。你能找到问题所在并修复吗？

//searchResults.js

export default class SearchResults extends React.Component {
  constructor (props) {
    super();
    this.state = {
      searchResults: [],
    }
    //initiate the worker array:
    this.workerArray = new WorkerArrayController({
      data: props.data,
      handleResults: this.handleResults,
      arraySize: 4
    });
  }

  componentDidUpdate(prevProps) {
    const {searchTerm} = this.props;
    if(searchTerm && searchTerm !== prevProps.searchTerm) {
      this.workerArray.search({searchTerm})
    }
  }

  handleResults = (e) => {
    const {searchResults} = e.data
    this.setState({
      searchResults
    })
  }

  componentWillUnmount () {
    this.workerArray.terminate();
  }

  render () {
    return <ReactVirtualizedList searchResults={this.state.searchResults}/>
  }
}

SearchResults组件初始化WorkerArrayController。

//workerArrayController.js

export default class WorkerArrayController {
  constructor ({data, handleResults, arraySize}) {
    this.workerArray = new Worker('... path to workerArray.js');
    let i = 1;
    this.webWorkers = {};

    while (i <= arraySize) {
      const workerName = `ww${i}`;
      this.webWorkers[workerName] = new Worker(`...path to ww1.js`);

       /* Creates a MessageChannel for each worker and passes that channel's 
       ports to both workerArray dispatcher and the worker so 
       they can communicate with each other */
      const channel = new MessageChannel();
      this.workerArray.postMessage({workerName}, [channel.port1]);
      this.webWorkers[workerName].postMessage({data}, [channel.port2]);
      i++;
    }

    this.workerArray.onmessage = handleResults;
  }

  search = (searchTerm) => {
    this.workerArray.postMessage({searchTerm});
  }

  terminate() {
    this.workerArray.terminate();
    for (const workerName in this.webWorkers) {
      this.webWorkers[workerName].terminate();
    }
  }
}

WorkerArrayController用4个ww初始化workerArray web worker，并传递MessageChannel端口给它们，这样它们能够互相通信。

//ww1.js

self.importScripts('...the search engine script, provides the SearchEngine constructor');

let searchEngine;
let port;

function initiate (data, port) {
  searchEngine = new SearchEngine(data);
  port = port;
  port.onmessage = search;
}

/* search is attached to the port as the message handler so it
runs when communicating with the workerArray only */
function search (e) {
  const {searchTerm} = e.data;
  const message = {
    searchResults: searchEngine.search(searchTerm)
  };
  port.postMessage(message)
}

/* self.onmessage is the handler that responds to messages from
the main thread, which only fires during initiation */
self.onmessage = function(e) {
  const {data} = e.data;
  initiate(data, e.ports[0]);
}

workerArray初始化端口对象用于通信，并跟踪每个ww worker。它还初始化了缓存和队列，万一所有端口都被占用的情况下用来跟踪最新的searchTerm请求。

//ww1.js

self.importScripts('...the search engine script, provides the SearchEngine constructor');

let searchEngine;
let port;

function initiate (data, port) {
  searchEngine = new SearchEngine(data);
  port = port;
  port.onmessage = search;
}

/* search is attached to the port as the message handler so it
runs when communicating with the workerArray only */
function search (e) {
  const {searchTerm} = e.data;
  const message = {
    searchResults: searchEngine.search(searchTerm)
  };
  port.postMessage(message)
}

/* self.onmessage is the handler that responds to messages from
the main thread, which only fires during initiation */
self.onmessage = function(e) {
  const {data} = e.data;
  initiate(data, e.ports[0]);
}