SuperMap 三维性能提问单

三维项目中，经常遇到的一个问题就是：“我这个项目数据量不大啊，为什么性能就是 慢呢？”三维要是性能慢，那肯定是没法用；虽然我们现在三维性能平台已经做了大量优化 工作，性能也有了突飞猛进的提升；不过在使用方式上还是需要掌握一些三维的原理知识和 优化技巧。
随着三维项目越来越多，研发已经无法承受对所有三维项目采用“一对一”的性能分析 和调优工作，特别是很多基础的性能优化工作，必须也应该采用一种更加“自助化”的方式 来完成。因此，特编制此《三维性能提问单》。请所有需要三维性能调优的项目，先用此提 问单自检。若仍然搞不定，再联系支持中心以及研发中心解决。谢谢大家的理解与支持！

Q 1 ：C/S 上还是 B/S 上性能差？
答复：在 C/S 性能差请继续看下面的问题；若是 B/S 上性能差，请先在 C/S 上验证并解决性 能；若 C/S 上性能 OK 了，但 B/S 上仍然不理想，请跳转到
Q 19。

Q 2：使用桌面的“场景”的“性能诊断”，结果如何？
答复：若得分较低（小于 80），请按照给出的“重要”“普通”“建议”的优先顺序逐条予以 优化；若看不懂给出的优化信息，请联系支持中心予以协助。若得分大于 80，性能仍然不 理想，请继续看下面的内容。详见：Q 3

Q 3：“性能慢”的具体表现是什么？ 答复：“性能慢”是一种感受或概要的说法，对于具体分析性能瓶颈和优化方法，需要给出 更精确的描述。请判断属于下列哪一种或某几种都存在：
1） 帧率低。在桌面“场景”“场景属性”中勾选“帧率信息”，在三维场景的左下角就能看 到“平均帧率”。一般而言，低于 10 帧就会非常卡顿，15 帧以上会好一些，20 帧以上 较为流畅，30 帧以上就非常流畅了。对于中端以上显卡，通过优化后，场景性能一般能 在 20 帧甚至 30 帧以上。优化方法可按照如下顺序进行：
a) 是否对所有数据已经制作了三维场景缓存，详见：Q 5
b) 是否已经升级到最新版本，特别是对高密度模型数据或多贴图模型数据，以及倾斜 摄影模型数据，详见：Q 8
c) 机器的配置情况如何，特别是显卡状况，详见：Q 7 d) 是否开启了水面、粒子、阴影等特效，详见：Q 10
e) 是否存在一些尚未性能优化的数据类型或表现形态，如动态物体、文字标签等，详 见：Q 14
f) 查看三角面片数量是否过大，详见：Q 11
g) 查看缓存默认设置是否合理，详见：Q 6
h) 检查模型数据制作上是否存在严重问题，详见：Q 9
i) 场景中的图层数量是否过多（超过 20 个），详见：Q 12 j) 进一步的优化办法，详见：Q 13
2） 加载速度慢。加载慢的大部分原因和“帧率低”一样，因此可先按照上述的要点进行分 析，之后再重点关注：Q 6

3） 加载的范围不够大。一般是和缓存生成的参数配置有关，请参考：Q 6
4） 操作卡顿（拖不动或会卡一下）。操作卡顿的具体原因一般可分为：
a) 数据正在加载中，导致卡顿；一般卡一下，数据加载后就流畅了。解决办法请参考：
Q 6
b) 选中了高密度模型或被损坏的对象进行操作。若选择附近的空地进行操作就没有卡 顿，就能基本判断属于这种情况。解决办法：重新导入数据并生成缓存（数据损坏 时），或提供数据给研发进行分析和优化；或选中空地进行操作。
5） 模型扭曲不更新，详见：Q 16
6） 影像模糊不刷新到原有的清晰程度。此问题是由于场景中有较高的地形图层，而平台中 计算影像层级有误造成的，和性能本身无关。研发已知晓该问题，并正在解决中。
7） 对象选中慢。一般都是模型密度较高或遇到特殊的对象造成的，建议提供数据给研发进 行性能优化。
8） 操作方式的体验不好。这个和性能本身无关，欢迎和研发联系反馈具体情况，以便研发 进一步改进操作方式。

Q 4：对于例如倾斜摄影模型、点云数据等的性能如何优化？
答复：7C sp2 版本，已经对倾斜摄影模型进行了优化，性能已经非常优异。详情请咨询支持 中心，或参考《超图倾斜摄影解决方案》技术白皮书。
对于点云数据，7.1 版本正在做优化。先对导入后的点数据集创建空间索引，然后生成 osgb 缓存，这样可以支持到百万级别的点数据。更大数据量已经做了部分优化；具体请和 研发中心联系。

Q 5：所有图层数据是否已经制作好缓存？ 答复：对三维性能优化而言，最重要的就是缓存、缓存和缓存。“无缓存，不性能”。缓存的 作用是把适合用来进行数据库管理的模型和矢量等各类数据，按照便于显卡进行三维渲染来 进行重新组织和优化。推荐数据库的数据进行管理和查询，缓存数据进行渲染和服务发布。
若缓存都没有制作，就质问：“为什么三维的性能不好”，那真是只能无言以对、默默流 泪了。

Q 6：检查缓存参数是否正确，包括：缓存版本，缓存层级，LevelWidth 等？ 答复：在生成缓存时，各种参数设置产品本身都会给出一个默认值，但这些系统计算给出参 数不一定对于各类数据情况都是最适合的，根据实际数据情况和使用要求进行调整，会使得 性能更好，或者解决存在的问题。几个需要重点关注的参数包括：
1） 检查缓存版本；打开缓存数据目录下的 scv/sct/sci3d 等文件，查看sml:Version标签中 的值。若为 2.0 或 2.1（及以上），说明是 7C 及其后续版本生成的。当前最新 7C sp2 版 本，模型缓存的版本为 2.1，地形、影像等其他数据缓存版本为 2.0。若版本过低，说明 是之前的老版本生成的缓存，建议用最新版本重新生成，很多问题就自然解决了；详见：
Q 8
2） 检查缓存层级（只对模型和矢量缓存有效）；打开缓存数据目录下的 scv 文件，查看
sml:Level标签中的值。一般而言，城市建筑大多为 16 较为合适，非常密集的建筑或 BIM 数据，17-18 较为合适。对于较为稀疏的建筑或矢量线面数据，14-15 较为合适。另 一个判断的方法为在场景中加载该缓存数据：若感觉每块数据（缓存是按照层级来切块） 加载太慢，说明数值太小，缓存生成时应该设置+1 或+2；若一块块的缓存加载起来很快， 但感觉每块太小，最后显示的帧率又比较低，则缓存生成时应该设置为-1 或-2；直到取

得一个最理想的平衡值。
a) 需要说明的是：当前版本在整个场景生成缓存时，并没有开放对单个图层的缓存层 级设置；但可以通过单独对数据集生成缓存来修改默认缓存层级设置，然后替换原 来缓存目录即可。
另外一点：模型生成缓存时，需要占用大量内存进行计算，若缓存层级数值过小（小于 16），32
位程序有生成失败或结果不对（可能导致：
b) Q 16）的可能。这时，可换用 64 位程序生成，或者加大缓存层级数值。
3） 检查缓存的 LevelWidth（只对模型和矢量缓存有效）；打开缓存数据目录下的 scv 文件， 查看sml:LevelWidth标签中的值。LevelWidth 是用来控制场景加载缓存的块数的，场景 在加载某层缓存时，会读取 LevelWidth 值，并只加载距离场景视点（相机位置）最近的
LevelWidth* LevelWidth 块缓存。LevelWidth 的设置和缓存层级（Level）有很大关系，若 Level 数值小，说明每块缓存的范围就大，因此 LevelWidth 的值就可以设置相对较小； 反之亦反。简单来说，首先确定合理的 Level 值，然后在场景中加载该缓存，若希望看 到更大的范围，则把 LevelWidth 改大；若加载后场景的三角面片数量过多（详见：Q 11） 或者帧率过低（详见：Q 3），则把 LevelWidth 改小，当然，改小后，能看到的范围就缩
小了。
a) 需要说明的是：LevelWidth 无需是 N 的倍数，即可以是任意正整数，场景加载的是
LevelWidth*LevelWidth 块 缓 存 ； 另 一 点 是 ： 可 以 直 接 修 改 scv 文 件 中 的
sml:LevelWidth，关闭场景再打开就 OK，而无需重新生成缓存

Q 7：所采用的电脑设备情况如何，特别是显卡的状况？ 答复：我们会努力降低三维对电脑设备包括显卡的要求，但毕竟三维渲染最终是交由电脑和 显卡完成的。因此也必须关注电脑和显卡的状况以进一步提升三维性能。具体需要关注：
1） 显卡的状况如何。
a) 若配置的是双显卡，是否已经设置了三维程序采用独立显卡。
b) 显卡驱动是否正常运行，驱动程序是否已经升级到最新版本
c) 推荐游戏显卡，而非专业显卡（又贵又慢）。
d) 对于集成显卡而言，由于其没有显存，因此只能占用内存来充当显存，因此会提高 程序整体对内存的占用。性能也会比独立显卡明显降低。
e) 更多详细内容，请参考《常用显卡一览表及推荐》
2） 内存大小；对于 32 位程序，4GB 已经足够，再大也是浪费；对于 64 程序，则多多益善
（一般配置到 16-32GB）。对于服务端则更是如此。
3） 硬盘；重点是保证客户端机器的系统盘空间足够，不够会导致下载的缓存无法存储。另 外需要关注磁盘碎片不要太多，否则会影响系统读写文件的性能。若用固态硬盘是最好， 但内部测试发现，三维性能的瓶颈一般不在于硬盘读写速度。
4） CPU；能用 i7 是最好，i5 或同等性能的 CPU 也足够用。

Q 8：所采用的平台产品，是否已经升级到最新版本（7C sp2）？ 答复：三维产品的每个版本，甚至 sp 之类的小版本，都会在某些方面进一步优化提升性能。 因此，及时更新升级版本，并用新版本重新制作缓存，对于性能优化能起到非常重要的作用。 以下列出最近几年的各个版本对各类数据的优化情况：
1） 6R(2012) sp2 版本：大幅度提高模型性能
2） 6R(2012) sp3 版本：大幅度提高地下管线、矢量线面、海量影像等的性能
3） 7C 版本：增加模型 LOD，大幅度优化模型的性能；优化影像缓存的性能；

4） 7C sp1 版本：大幅度提高高密度模型（BIM、电力塔、炼化厂等）以及多贴图模型（反 映城市现状模型）的性能
5） 7C sp2 版本：彻底优化倾斜摄影模型的性能 由于在针对各类数据进行性能优化时，也会同时优化三维渲染内核的性能，因此对未列
入上表的数据性能也会有所提高。因此建议保持同步升级，采用最新版本并重新制作缓存， 很多性能问题自然就得到解决了。
在兼容性、稳定性、操作体验等多方面，产品的每个版本都在持续提高，因此升级版本 也能同时解决这些方面的诸多问题。更具体的内容，请参考产品帮助文档的 what’s new 说 明。

Q 9：模型制作的状况如何？
答复：Max 中制作的模型，其质量好坏会严重影响三维浏览的性能。一般而言，特别需要关 注的方面包括：
1） 尽可能用少的三角面片去构建模型骨架。例如高楼的一面墙，不要每层楼都勾画线，而 是用贴图的方式体现出楼层来；看不到的地方应删除掉，等等。
2） 用尽可能少的贴图数量。例如相近的墙面可以共享贴图；细碎的纹理拼接为一个图等
3） 贴图大小不要太大。一般建议控制在 10241024 之内，最大不要超过 20482048；太大 了显卡有可能不支持，或占用显存过大，从而影响性能。
4） 除非必要，采用单面渲染，而非双面渲染；从而避免无谓的性能损失。
5） 尽可能独立的建筑物作为一个单独的对象，不要把相邻的建筑物合并为一个对象，也不 要把一个建筑物拆分为 N 多个对象，如门、窗、墙都是单独的对象（除非是制作 BIM 模 型）；对后续平台生成 LOD 的效果很有帮助。
更多内容，请参考《模型制作注意事项》

Q 10：场景中开启了多少三维特效，如：水面、粒子、阴影等？ 答复：各类三维特效，都会或多或少的影响三维性能，因此正确的选用特效是非常重要的。 首先要判断该三维特效是否导致了性能瓶颈，方法是关闭该图层的可见性，看性能变化情况。 然后采用针对性优化方法，具体来说：
1） 水面特效需要关注矢量面对象的个数，以及节点数；若能用一个节点最少的多边形来勾 画水面是最好不过的了。还可以通过图层高度来控制在一定高度下看到水面，更高的位 置，通过 gif 或颜色来表达水面。
2） 粒子特效重点关注粒子的个数，建议只在需要的时候开启粒子图层，不需要时就让该图
层不可见
3） 阴影效果推荐用 Max 烘焙来完成，平台提供的实时阴影对性能影响还是很大的；建议只 在需要的时间予以展示，作为一个功能来使用，使用完毕时即时关闭。

Q 11：三维场景中加载的三角面片数量是多少？
答复：首先看 Q 3 中的描述，在开启“帧率信息”时，同时显示出当前绘制的三角面片数量。 虽然我们在性能上已经做了大量优化，但最终仍然需要显卡来绘制，而显卡绘制的就是三角 面片。不同档次显卡所能绘制的三角面片数量是有限的。一般而言，集成显卡最好控制在
100 万以下，低端显卡控制在 300 万以下，中端显卡控制在 500 万以下，高端显卡控制在
800 万以下。 若当前绘制的三角面片数量接近或超过了所使用显卡的极限，性能自然会大幅度下降。
而若不能更换更高端的显卡，则需要通过其他优化方式来减少所绘制的三角面片数量。一般

是从数据本身和减少所见范围两个角度来进行，分别详见：Q 9 和 Q 13。

Q 12：查看场景中的图层数量是否较多（20 或更多）？ 答复：由于我们采用分层管理数据的方式，能带来业务应用、管理和更新等多个方面的灵活 性；但渲染时，每个图层都会占用一定资源，并且调度时也会带来一定损耗。因此，不建议 场景中的图层数量过多。最好控制在 20 之内，多了也不要 50。可以采取以下方式减少图层 数量：
1） 合并同类型的图层，例如模型可按照：建筑、地板、树木、小品等分为 5-8 层即可，不 同区域的建筑可先在数据集中合并后再生成缓存
2） 通过图层可见高度控制同时可见的图层数量，详见：Q 13

Q 13：查看是否设置了图层上的各类优化参数，如：图层可见高度、对象可见距离，精细纹理距 离，LOD 距离等？ 答复：还可以通过图层上的各类参数设置，进一步优化整个场景的性能。具体包括：
1） 场景中的每个图层都可以设置最大和最小可见高度，例如：不同分辨率重叠在一个区域 的影像，就可以用这种方式来优化显示效果和性能；在高空，也可以不显示建筑物、树 木等，只显示地板模型，再高则可以换用影像代替等等
2） 模型和矢量图层，可以设定该图层最远的可见距离，超过该距离的物体将不被显示；例 如一般的建筑模型显示 3000-5000 米比较合适，而树木、小品等有 500 米就 OK。通过这 种方式，可以有效降低需要渲染的三角面片数量，以提高性能。
3） 模型图层，可设置精细纹理距离和 LOD 距离。精细纹理距离是控制模型贴图清晰层到抽
稀层的距离，默认距离为 200 米；LOD 距离是模型贴图抽稀层到模型骨架抽稀层（LOD） 的距离，默认距离为 800 米。可以通过减少两个距离值，使得比较近距离就显示贴图或 骨架的抽稀层，从而减少渲染的数据量，以辅助优化性能。对于 BIM、炼化厂等高密度 模型，甚至可考虑把精细纹理距离设置为 0，LOD 距离设置为 50-100 米。

Q 14：是否有以下数据类型，包括：动态物体、大量文字标签、点数据，或者 kml、跟踪层中有 大量数据等？ 答复：三维性能是和它所承载的数据类型密切相关的，不同的数据类型，都有其针对性的优 化措施。在某种数据类型的优化措施尚未完成之前，加载该类型数据，即便数据量不大，也 有可能导致整个场景的性能急剧下降。具体包括：
1） 动态物体，如动态刷新位置的飞机、车辆等。加载几十个不是问题，但再多性能就是瓶 颈了
2） 文字标签，当前的性能加载几十个不是问题（通过图层高度设置，距离设置，文字避让 等可以大大有效减少同时显示的文字数量）；成千上万的文字标签性能将在 7.1 版本中予 以优化
3） 点数据，缓存后当前的性能加载几万个不是问题（若不缓存，直接加点对象，则性能会 极为糟糕）；百万级别的点加载 7.1 版本将通过转换为 osgb 格式缓存来优化性能；更大 数据量的点云尚未确定支持时间。
4） Kml 或跟踪图层中放置大量数据。6R sp2 之前的版本 kml 和缓存的性能相当，而 kml 由 于全内存模式，不少项目习惯于把模型数据放到 kml 中；但随着缓存性能逐步提高，现 在缓存性能早已甩出 kml 几条大街了，还用 kml 存放大量数据性能自然极为低下。Kml 的作用更多是放置少量临时性的或动态变化的数据。跟踪图层则是放置一些临时的信息， 如量算结果等，也不适合存放大量数据。

Q 15：有时三维场景忽然不更新加载数据，是怎么回事？
答复：三维场景忽然不更新加载数据，可能出现问题的环节包括：
1） 场景的更新线程崩溃；看起来三维场景拖动没有问题，但不再加载新的数据， 在关闭场景或程序时程序崩溃。这种情况，往往是由于数据被损坏所造成的，重新处理 数据即可解决。数据可能出问题的原因详见：Q 6、
2） Q 16 和 Q 24。
3） 当前系统资源不够，一般等待一段时间即可恢复。可能的资源问题详见：Q 7 和 Q 17。

Q 16：用 7C（或 7C 后续）版本生成的模型缓存，加载后发现模型扭曲了，是怎么回事？
答复：7C 版本开始，模型缓存时提供了自动生成 LOD 的功能，默认是开启的，简化率为 10%
（简化率为只留下 10%的数据，用户可自行设置百分比），因此 LOD 层的模型是会有一些扭 曲。但由于 LOD 层在图层中默认设置为 800 米之外才显示，故而看起来效果还是不错的。 出现扭曲一般是由于过程中某个环节出问题了，具体说来可能出问题的地方包括：
1） 原始模型制作方面。详见：Q 9
2） 和缓存生成的参数配置有关，详见：Q 6
3） 程序的数据更新线程问题，详见：Q 15

Q 17：如何减少三维场景对内存的占用？ 答复：三维场景的内存占用过高，不是一件好事，会导致很多问题。详见：Q 25。解决的办 法包括：
1） 升级软件到最新版本，版本升级时，一方面是提升性能，同时也会减少对内存的占用。 详见：Q 8
2） 通过修改缓存配置参数来控制数据加载。详见：Q 6
3） 通过修改图层配置来进行控制。详见：Q 13
4） 通过升级显卡来减少对于内存的占用。详见：Q 7
5） 以上办法若仍然无法满足需要，请和支持中心、研发中心联系。

Q 18：客户端机器，对三维性能的影响有多大？应如何应对？ 答复：三维渲染不同于二维。二维若动态出图，是在服务端上渲染出图片，然后传输到客户 端，客户端机器只负责在浏览器中显示图片即可。而三维服务发布和渲染的流程是服务端负 责提供三维缓存数据并传输到客户端进行缓存，渲染的工作都是在客户端完成的。因此客户 端对机器的性能要求和 C/S 架构下是完全一致的（同一套内核和代码），并且由于浏览器也 要占用部分资源和损耗，因此还会比 CS 下稍慢一点（一般帧率低 3-5 帧）。
因此，在有条件的情况下，建议客户端也配置较好的独立显卡，以及 CPU、内存等。若 客户端机器较差且无法更改，那么建议先在 C/S 上用同等机器进行调优（详见：Q 2），待性 能达到可接受程度后，再进行 B/S 发布。

Q 19 ：若 C/S 性能不错，B/S 性能就是差，瓶颈在哪里？
答复：瓶颈一般可能会出在这几个方面：
1） 所发布的数据，是否先通过桌面或组件制作好缓存；详见：Q 20
2） 网络发布，特别是外网发布，对网络带宽会有一定要求；详见：Q 21
3） 客户端机器，特别是显卡的状况如何；详见：Q 18
4） 服务器和客户端的版本是否一致；详见：Q 22

5） 若性能问题解决，但存在 C/S 稳定性还不错，但 B/S 上经常崩溃的问题；详见：Q 23

Q 20：为什么推荐先生成缓存再发布三维服务？
答复： 因为缓存的生成过程是一个较为复杂且耗时的过程，而客户端所渲染的，必定是缓 存数据（可参考 Q 18 说明）。因此，若不实现生成缓存，则即便网络带宽 OK，也会有较长 的等待时间，导致性能体验很差。另外，由于缓存生成过程需要占用大量资源，在服务正在
运行的情况下生成缓存，也存在不稳定因素。故而推荐先用桌面或组件生成缓存，再发布三 维服务。

Q 21：网络带宽对 B/S 项目的影响有多大？如何计算所需要的带宽？
答复：从 Q 18 中可以看出，三维 B/S 中，所有需要在三维客户端中渲染的数据，都是必须 先通过网络传输到客户端。虽然产品已经做了优化，保证先传输下载客户端所见范围内的数 据，下载之后就会在客户端缓存下来，下次浏览不用重新下载；但毕竟仍然有一个下载的过 程。特别是对数据量大且并发数量多时，对服务器出口带宽是一个严重的考验。
对一般的模型数据而言，屏幕中出现 2MB 以上的数据，会感觉加载比较宽；简单换算，
2MB 数据若用 2mb 的网络传输（网络传输用的是 bit，而非 byte，两者差 8 倍），需要 10 秒 左右；这个加载速度往往是不够理想的。电话线的 ADSL（一般的拨号上网），虽然理论上能 到 8mb，但实际中往往只有 2-4mb 甚至更低，因此用这种方式上网作为客户端的话，确实 需要一些耐心。而若用 10mb 或更快的宽带网络，则只需要 1-2 秒就可以出来，感受就比较 流畅。
而对于服务端的出口带宽，则还需要计算并发下载的数量。由于数据传输到客户端后，
客户端会缓存下来，下次访问不需要再到服务端请求和下载数据，因此实际对网络的需要并 不是把客户端带宽要求并发数，而是低一些。简单而言，可以按：客户端带宽要求并发数
/5 来计算。

Q 22：服务器和客户端的版本是否需要一致，为什么？ 答复：由于三维技术发展很快，每个版本（包括 sp 这样的小版本）我们都可能在某些方面 提升性能；而性能提升的法宝是修改缓存的存储格式，以便显卡可以更快的加载和渲染。因 此，若缓存生成的桌面、发布缓存的服务器和实际渲染的客户端版本若不一致，则会出现某 个产品不认识缓存格式的情况，请则效率低下或效果错误，重则崩溃。
在兼容性方面：高版本的软件自然可以读取低版本的数据，但这样一来，高版本软件也 只能按照低版本数据的情况来渲染，自然也无法达到高版本所带来的性能提升。故而建议桌 面、服务器和客户端的版本必须保持一致，同步升级。
待未来三维的性能已经足以满足需要，我们无需再升级缓存格式时，服务器和客户端的 版本就能有办法实现脱离，即一端的升级不影响另一端的正常工作了。

Q 23：CS 上比较稳定，但 BS 上稳定性明显有差距，原因可能是什么呢？ 答复：一个简便易行的方法，用桌面打开 iServer 发布的三维服务，看稳定性如何。若稳定 性不错，那说明问题很可能出在浏览器方面，具体包括：

1. 对于 7C sp1 之前版本，IE 的版本是否过高；详见：Q 8
   

2. 浏览器版本、服务器版本是否一致，详见：Q 22
   

3. 请观察崩溃时浏览器所占用的内存，详见：Q 25
   

4. 请确认客户端机器的 C 盘（系统盘）有足够的空间，详见：Q 24
   

5. 请确认已经清理了服务端和客户端的缓存数据，详见：Q 24
   

若桌面打开 iServer 的三维服务，稳定性也很差，则说明问题很可能出在服务端方面， 具体包括：

1. 确认所有要发布的数据已经生成缓存，而非动态发布；详见：Q 20

Q 24：版本升级或出问题后，是否清除了服务端和客户端的缓存？ 答复：在服务发布过程中，服务端会自动在\webapps\iserver\output 目录下缓存原始格式的 缓存数据，客户端会在当前用户目录的 AppData\LocalLow\SuperMap\Cache （ 可 先输 入%temp%，再往上找两级目录）自动缓存传输过来的数据。若不清除它们，它们就会作为 已经存在的缓存数据而被使用。若版本升级、数据升级或者出问题后，这些数据很可能成为 “垃圾”甚至受损的数据，并影响正确数据的下载。因此清除这些数据就很可能解决了所引 发的一系列“疑难杂症”。

Q 25：三维程序崩溃，占用了多大的内存？ 答复：由于三维渲染采用的是动态调度的方式，即看到的数据会即时加载到内存中，看不到 的数据会很快卸载掉，因此程序会频繁的内存分配和释放。若内存占用过高，则若遇到较大 块的数据，就可能导致内存分配失败，从而引发不稳定因素。虽然我们在程序中已经做了一 些限制措施，当内存占用已经较高时，优先卸载数据而非加载数据，但这个仍然是一大隐患。
一般而言，我们建议 PC 上 32 位程序最大内存占用量不超过 1GB；iOS 上内存占用不超 过 400MB；安卓设备看物理内存大小，不超过 400MB-1GB。而浏览器中由于浏览器自身还 要占用一定内存，因此可用内存更加有限。
若我们发现当浏览器中运行三维崩溃，而此时浏览器占用内存已经达到或超过 1GB，则
应先在同等机器环境下，用 C/S 程序中重新配置场景，当内存占用减少到 1GB 以下后，再 予以发布；详见：Q 17
64 位的程序则在内存方面会宽松很多，但由于浏览器一般默认开启的都是 32 位程序， 因此建议需要做 BS 发布的三维场景，仍然通过 32 位桌面予以配置。