关于cesium:CesiumJS-更新日志-196-与-197-新构建工具-esbuild-体验及-Model-API-更替完成

CesiumJS 更新日志 1.96 与 1.97 – 新构建工具 esbuild 体验及 Model API 更替实现

截止发文，1.97 还未公布，但曾经在源码仓库实现了 Model API 的替换，文章会跟进。 本文着重介绍新的构建指令的用法（配套 esbuild 的应用），见第三节。

首先介绍 1.96 和 1.97 两个大版本的更新内容。

1.96 更新状况

1.96 已于 2022 年 8 月初更新；重大更新如下：

• 改用 esbuild 实现库程序的构建，并更新了一批 npm script（与之前的很不一样）；
• Model.boundingSphere 属性当初返回 ECEF（地心地固）坐标系下的坐标值，也就是世界坐标（EPSG:4978）而不是模型原来的部分坐标；
• 具备 CESIUM_primitive_outline 扩大的 glTF 模型或 Cesium 3DTiles 数据，当初能够通过管制 showOutline 属性来显示外廓线了；未来有可能退出 outlineColor 属性管制色彩；
• 应用模型 API 新架构（1.97 将正式代替旧版 Model API，下文不再反复形容）制作的点云类型 3DTiles 当初反对了款式化；
• 降级 earcut 库至 2.2.4 版本，晋升了 10% 到 15% 的性能；
• 修复新 Model API 的若干 bug，包含但不限于 draco 点云示例解体的问题、cmpt 瓦片数据示例缓存不失常的问题、具备透明度的模型示例不更新的问题、逐因素后处理（per-feature post-processing）不失效的问题、具备量化坐标的 i3dm 瓦片数据不能正确加载的问题等；

1.96 有两项过期 API 音讯：

• ModelInstanceCollection 模块中 CPU 端的实例化技术（于 1.97 破除）；
• requestAnimationFrame 和 cancelAnimationFrame 两项兼容性库实现（于 1.99 破除），因为基本上所有的浏览器都实现了这个 API。

1.97 更新状况

1.97 次要更新如下（继续更新中）：

• 把 ModelExperimental 转正，重命名为 Model，位于 Source/Scene/Model/ 目录下，齐全代替旧版的 Source/Scene/Model.js 等较为糅杂、耦合的旧模型加载架构；
• 正式反对 CustomShader API
• 正式反对 EXT_structural_metadata, EXT_mesh_features 和 EXT_instance_features 三项将来 3DTiles 1.1（以后被称作 3DTiles Next，以 1.0 的扩大存在）的个性，极大加强 3DTiles 各分层的数据语义能力；
• 正式反对 EXT_mesh_gpu_instancing 这项将来 3DTiles 1.1（同上，不赘述）的个性，此个性为 glTF 标准专门设计、扩大，以逐渐代替旧版 i3dm 瓦片格局的实例化技术；
• 正式反对 EXT_meshopt_compression 这项 glTF 的网格优化压缩扩大，与 Draco 相比各有优劣；
• 反对了跨瓦片文件的纹理贴图缓存技术；
• enableModelExperimental 配置移除，所有的 glTF 模型、3DTiles 新旧版本均应用上述新版模型架构

新版的 Model API 在公共 API 的文档和调用简直没有差距，做到了对下层利用的无缝兼容（待这两个版本测试），因而开发者简直不须要更改原来的 API 调用代码。

此外，还有几个极为重大的扭转：

• glTF 1.0 版本的反对已移除 ，请尽快转换你的数据到 glTF 2.0 版本；
• glTF 的一项扩大 KHR_techniques_webgl 已移除 ，如果你有自定义着色需要，请应用 CustomShader API
• ModelInstanceCollection 这个公有类应用的 CPU 端实例化技术已移除；
• ModelMesh 和 ModelMaterial 两个公有类已移除；
• 繁多模型的分类分级着色已反对，应用 classificationType 参数配置 Model 类即可，详见帮忙文档

总结下来就是下一代的 3DTiles 越来越近了。

新构建工具 esbuild 和大换血的构建指令应用

本段大部分资料参考自官网博客：

Build Tooling Updates Coming to CesiumJS – Cesium

1. 官网自述构建工具更新的起因

近几个月，官网团队致力于改良开发者体验，最近曾经把成绩合并到主分支，那就是应用新的代码构建工具。在 CesiumJS 的源代码开发时，曾经能取得更小体积的发行版 CesiumJS 库文件（未压缩版本体积小了 33%，压缩版小了 16%），而且速度有质的飞跃。发行版变小，使得网络加载工夫变短，速度更快。

因为精简了代码资源、移除无关的空格和正文，失去了更小的构建版本的库文件，这也有利于进步浏览器加载速度

这样做还有额定的益处，就是解决了一个在 Linux 零碎中 Chrome 浏览器长期存在的问题

2. 抉择应用 esbuild

CesiumJS 我的项目启动之初，它所用的辅助开发工具基本上都是同类我的项目中的“陈腐玩意儿”，比方，RequireJS 就是过后最突出的依赖管理工具，1.62 版本之前的模块机制都是异步模块定义（AMD）。后来自 1.63 版本齐全为 ESModule 后，就改用 Rollup 来构建了。

到目前为止，CesiumJS 在构建时是存在没有轻量化、最小化等故障的。CesiumJS 最重要的环节，即把所有源代码模块合并到一个主文件（以不便散发），官网并没有在这个过程中对代码进行重大转换，因为须要思考到兼容性问题。

由 ESModule 多个模块文件合并到繁多文件，这个繁多文件我个别叫它库文件

当初的 JavaScript 工具曾经越来越快、越来越好用了，开发者们更习惯走打包的路线，所以是时候评估构建工具的更新了。

官网抉择应用 esbuild 来代替 Rollup 来实现“ESModule -> 库文件”这个最重要的环节。

• 首先，esbuild 足够快（译者注，参考 vite，速度引人注目），这能满足疾速开发的要求；
• 其次，Rollup 尽管有很多插件，然而相比拟之下这些插件很多 esbuild 都是开箱反对的，例如从 node_modules 中主动打包第三方库、代码转换、代码压缩等；
• 最初，esbuild 还能进一步减小构建进去的主库程序文件的大小（无论压缩版还是未压缩版本），更有利于浏览器加载提速。

3. 对于 WebWorker 遗留问题

WebWorker 是浏览器后盾运行的独立脚本，在 CesiumJS 中，它们宽泛用于创立几何图形和数据解码工作。

Firefox 仍未在 worker 中反对 ESModule，这意味着必须应用 iife 或者 amd 模块化机制来加载 worker 文件；但 esbuild 只反对 ESModule 的代码宰割，如果不进行代码宰割，worker 文件大小就会显著增大。

为了防止这个问题，只能临时持续用 Rollup 和 RequireJS 来解决 worker 的问题。直到 Firefox 反对之后，能力齐全切换到 esbuild 来。

4. 重头戏之旧构建指令移除与新指令用法

除了用上 esbuild 之外，官网还借此机会从全局重新考虑了构建过程，包含构建脚本负责的工作的粒度问题。

最大的变动是开发时的构建办法，因为 esbuild 的减速（尤其是疾速增量构建），当初曾经不须要提前构建（即旧版的 combine 指令）能力进行本地开发了（npm run build）。当初，源代码的开发调试只须要装置依赖，就能够间接启动服务器：

npm run install && npm run start

CesiumJS 多年的积攒，相干工具减少、配置的减少，导致 gulp 中增加了很多指令，他们命名仿佛有点乱。当初官网从新评估了这些指令，从新设计如下（次要）：

• 移除 combine、combineRelease、minify、minifyRelease、build-specs、convertToModules 指令；
• 重命名 startPublic 为 start-public，性能不变；
• 保留 build 指令，但与之前意义不同，下文细说；
• 保留 release 指令，但与之前意义不同，下文细说；
• 重命名 generateDocumentation 指令为 build-docs，下文细说；
• 重命名 makeZipFile 指令为 make-zip 指令，性能不变；
• 重命名 buildApps 指令为 build-apps 指令，须要构建版本的示例利用（而不是应用源代码的版本）可调用此指令；
• 保留 build-ts 指令，但与之前意义不同，下文细说；

移除的指令不再赘述，请读者自行查阅互联网上的材料。上面着重介绍 build、build-ts、build-docs、release 四个最重要的新增 / 变动指令。

我应用了两台电脑比照运行工夫，一台标记为 A，应用桌面 i7 12700 CPU；一台标记为 B，应用 AMD r7 4800U。

其中，build 指令外部会调用 esbuild 来实现 ESModule、iife、commonjs 三种格局的库文件的打包。表格不够具体的，见下文：

• build：做了 4 件事，①转换 Source/Shaders 下所有 .glsl 格局的文件成 ESModule 文件，导出着色器代码字符串常量；②生成 Source/Cesium.js 这个 ESModule 进口文件，导出所有 CesiumJS 的模块、常量、类等，无论公开或公有；③生成 Build/CesiumUnminified 文件夹，并调用 gulp 配置文件中的 build 工作，生成 ESModule、iife、commonjs 三种格局的单文件 CesiumJS 库，含 source-map 映射文件；④复制 Source/ 目录下的四个动态文件夹到 Build/CesiumUnminified 下；这个指令有 esbuild 的参加，也有 rollup 的参加（解决 Firefox 仍旧无奈在 worker 中应用 ESModule 的问题）
• build-ts：调用 jsdoc，把源码中的 jsdoc 正文生成 Source/Cesium.d.ts
• build-docs：调用 jsdoc，生成离线帮忙文档页面，以便开发者页面或部署的 API 帮忙文档可能应用；
• release：这是个复合指令，会程序执行 ①调用 gulp 配置文件（gulpfile.cjs）中的 build 工作，build 指令实际上用的就是 build 工作（一个 JavaScript 函数，被 gulp 称作工作），生成无 TypeScript 类型定义文件和源代码映射文件的 Build/Cesium 和 Build/CesiumUnminified 两个版本的库程序，前者会压缩，后者与 build 指令理论差不多；②调用 build-ts 指令；③调用 gulp 配置文件内的 generateDocumentation 工作，实际上也就是 build-docs，生成离线帮忙文档

留神，build-apps 依赖于 build，有先后顺序

有两个小技巧，

• 依据 npm 指令的规定，想为某个指令的外部调用持续传递参数的，须要接两个横线，例如生成离线文档时想生成公有模块的文档，则应用 npm run build-docs -- --private，那么 --private 就会传递给 build-docs 外部理论调用的 jsdoc
• 想查看开发者示例程序必须再次调用 build 指令，release 指令一旦执行会清掉开发者示例程序，也就是 Sandcastle 中的 Development 分页的示例

5. 收益

就官网的说辞和笔者本人的体验来看，build 指令比起之前的速度，几乎就是做了火箭，本来同一台电脑进行 minifyRelease 可能要 4 分多钟，当初 release 只需 1 分半左右。

而且最显著的，无论是压缩版（Build/Cesium）还是未压缩版（Build/CesiumUnminified）的三种格局的库程序，其库文件大小均比原来小不少，加上 gzip 的加持还能更小（请读者自测），基本上全库加载能做到从黑场景到出地球只需 2 秒左右。

• 压缩版，4.3MB → 3.3MB（基于 1.97，GZIP 后 900+ KB）
• 未压缩版，12.5MB → 8.0MB（基于 1.97）

CDN 上的 Cesium.js 主文件传输体积，基于 HTTP2 甚至能做到 700+ KB，显著晋升场景加载速度。

6. 之后的改良方向

可能之后有思考转向 TypeScript；一旦 Firefox 的 worker 能够加载 ESM，那么现实状态下能够齐全移除 RequireJS 和 Rollup，进一步减速构建速度和减小公布版本的库代码。

7. 开发者如何应用新的构建成绩

我没有间接翻译官网的表述，这里我给一个更合乎思考逻辑的倡议：

• 如果你打算在你的工程中用打包器加载 CesiumJS 源代码模块，那么你间接应用 import {} from 'cesium' 即可，这种用法将会减少你的工程打包工夫，然而能够利用 ESModule 的 Tree-Shaking 个性减小构建产物的大小；
• 如果你打算应用官网构建进去的 ESModule 单库文件，请应用 Build/Cesium/index.js 或 Build/CesiumUnminified/index.js，看你须要压缩或未压缩的版本；
• 如果你在 CommonJS 模块中应用 CesiumJS，那么持续应用 const cesium = require('cesium') 即可导入，默认会指向 Build/Cesium/index.cjs 或 Build/CesiumUnminified/index.cjs；
• 如果你打算应用官网构建进去的 iife 格调的单库文件，请持续应用 Build/Cesium/Cesium.js 或 Build/CesiumUnminified/Cesium.js

当前有趣味能够写文讲讲如何最优地在你的我的项目中引入 CesiumJS，我认为 CDN 引入是一个不错的减速伎俩，尽量避免让利用打包器再次打包 CesiumJS，Tree-Shaking 对于这种级别的 3D 地球库来说可能收益甚微。