美丽的代码

我一直在研究一个小型应用程序，该应用程序在地图上覆盖了成千上万个复杂要素，每个面要素由10到100的单个点组成。 我已经编写了基本的应用程序框架并进行了逻辑编码，包括通过构建我之前提到的可操作转换库来实时编辑“正常工作”。

但是核心的用户体验取决于地图和叠加层渲染的性能，而单个功能的数量如此之多令人感到痛苦。 我正在使用OpenLayers API，该API提供了很多与第三方地图服务的即插即用功能。

我知道有可能使它起作用。 Web上存在这些接口的存在性证明，并且核心OpenLayers API定义了一种替代的分层技术，这种技术是我最初与之集成的一种技术，它使用切片叠加方法。 这种方法的集成更加复杂，但是提供了完成这项工作所需的控制权。 切片方法不仅可以在地图区域的可见子集中提供要素的子集，而且还可以为每个缩放级别提供不同的要素集。 在较低的缩放级别（缩小以查看更多地图和更多要素）时，您既可以剔除折叠成单个点的要素，又可以减少要素的复杂性（减少点数以使其渲染更快）。 从理论上讲，平铺和剔除特征与点的结合将使其全部起作用。

使用流行的API和格式的好处是，您可以在搜索引擎中键入一个搜索字符串，例如“在openlayers中显示数千个geojson特征”，然后立即让第二或第三篇文章使用GeoJSON-VT快速渲染大的地理数据。 —兴趣点， MapBox工程师Vladimir Agafonkin的博客文章。

上面链接的文章描述了一个由Agafonkin编写的JavaScript库，可以很容易地通过npm进行安装，正是我需要的。 这是那些罕见的“完美依赖”之一。 该代码以巧妙的方式应用了一些著名的图形技术。 它在分析过程中对几何图形进行一次注释，然后可以使用此简化数据以极快的速度通过动态设置的简化和剔除功能为每个缩放图层生成单独的图块。 它还应用了有关JavaScript性能技术的详细知识，以优化其内存使用和分配行为。

代码很漂亮—干净，简单，并且仅限于完成此集成所需的内容。 没有很多可选功能的混乱，也没有过度雄心勃勃的基础架构来执行我不需要的事情。 集成起来非常简单快捷。 它与一个简单的JSON对象接口连接，该对象易于与OpenLayers期望的内容保持一致，同时保持隔离性，并且无需创建不必要的依赖项或假设。

效果似乎很神奇-地图在视觉上看起来与我以前的版本相同，但是现在缩放和平移变得快速无缝。 一个看起来令人生畏的任务将在一两个小时内完成，该任务将确定应用程序是否可用。

这也是时间/空间性能折衷现实的有趣示例。 该库大量利用预先计算的某些数据进行剔除计算。 这是我们在谈论时间/空间权衡时通常引用的经典“利用空间节省时间”权衡。 但是任何有经验的程序员都知道，大量使用内存会直接导致时间成本的增加。

该软件包在识别它会丢弃哪些信息以最大程度地减少内存使用以及保留哪些信息时非常谨慎，以便在动态生成图块时可以提供可预测的性能。 这种技术在许多应用中很常见。 例如，文字处理器会进行详细的布局以确定对象的位置，但随后仅保留段落的高度。 仅根据需要重新生成详细的字符运行，例如，用于在屏幕上显示的有限段落上进行渲染或命中测试。

通常，您可以抽象地定义应用程序的算法和数据结构，但实际上要交付出色的高性能应用程序，需要“挖空”您保留的数据，并专注于最大限度地提高可动态生成数据的位置，并按需提供可预测的性能。 阿加丰金在这里做得非常好。

From: https://hackernoon.com/beautiful-code-d333bde82509