Cesium 加载 ArcGIS 动态图层的方式
如果你在 Cesium 中加载过 ArcGIS 的动态图层，你会发现，Cesium 对于动态图层仍然采用类似切片图层的逻辑进行加载。也就是每个固定的瓦片 export 一张图片。
这样会造成一些问题：
- 请求量大 ，如果访问人数多，后端服务容易崩溃
- 如果动态图层中含有标注，会造成标注文字变多（ArcGIS 动态图层如果一个大图形被分割在多个 export 中，那么每个 export 回来的图片都会含有大图形对应的标注）
没找到合适的带标注的动态图层数据，这里用 ps 简单模拟一个效果
ArcGIS 4.x 三维场景加载动态图层的方式
通过查看 ArcGIS 三维场景发送的请求可以发现，ArcGIS 每次相机停止运动时，会首先给动态图层服务发送两个范围大小不一样的 export 请求。再根据请求回来的两张图片进行叠加显示。
效果大概如下（同样用 ps 模拟）
当然，如果同一个面被分割在了两个服务，一样会出现标注多的问题
在 Cesium 中实现仿 ArcGIS 三维的动态图层加载方式
要实现仿 ArcGIS 三维的动态图层加载方式，首先当然是得先获取 ArcGIS 是如何计算两个 export 参数的。
这一步没什投机取巧的办法，只能去翻 ArcGIS 的源码，把这段逻辑抽离出来。（npm 包里的 arcgis 源码，代码经过了压缩，不过大致逻辑还是能看出来的）
如果抽离的逻辑正确，那么请求的范围应该类似下面这样
抽离出两个 export 参数的计算方法之后，就该考虑如何展示了。
利用 GroundPrimitive 展示
将请求回来的两张图片通过 GroundPrimitive 展示是最简单的办法，需要做的额外操作只有在第二张大的图片中，挖去和小图片相交的部分
优点：实现简单，性能高，能实现影像贴模型的效果
缺点：无法 和其他通过 ImageryLayer 方式加载的图层交换图层顺序
编写 ImageryLayer 展示
ImageryLayer 请求方式就是 Cesium 原生的方式。它能够解决 GroundPrimitive 无法和其他图层交换顺序的问题，但是会有一些性能问题。
性能问题源自于 ImageryLayer 会按切片方案将展示的内容切割成一个个小的瓦片。而我们 export 回来的两张图片并不是严格按照切片方案请求的。
因此， 每次请求回来的图片， 都需要根据当前正在显示的瓦片进行切割， 并将切割出来的内容更新至瓦片的缓存中。（ ImageryLayer 内置缓存机制，一旦当前瓦片请求成功，则后续直接读取缓存不会再请求。实际渲染时，也是读取缓存中的内容渲染的。如果不更新缓存，那么当重新显示已缓存的瓦片时，其内容会和当前的图片对应不上 ）
更新瓦片缓存这一步相当耗时和耗内存，并且如果瓦片多，甚至会出现阻塞主线程的情况。
有的同学可能会说，是不是可以考虑采用 WebWorker 来计算每张瓦片的内容？
事实上，我尝试过，但是由于需要同时更新的瓦片比较多，就会导致 export 请求回来的两张图片都需要复制一份到各自的 WebWorker 中，这样会导致更严重的内存问题。
采用 SharedArrayBuffer 让图片在 WebWorker 之间共享？
事实上，我也尝试过，但是 SharedArrayBuffer 似乎存在一些兼容性问题，最后还是放弃了 😑。
如果各位大佬有解决方案，欢迎提供！
修改源码的方式展示
在编写 ImageryLayer 方案时，我想到，实际上我可以只向着色器传入两张纹理，和对应的四至范围。在计算 Globe 上的影像纹理时，单独为动态图层进行切割即可。
就目前而言，这个可能是最理想的方案，只是需要去对 Globe 和 ImagerLayer 相关的源码进行修改。
这个方案还有待尝试，累了...晚点再试...😑