为了解决用户使用过程中的体验问题，我们团队进行了走访用户调研，在调研过程中发现：在一些配置较差的机器上存在拖动模型异常卡顿的情况。

从以上的交互动图中可以观察发现，在已经实现的功能中，家具拖动过程中包含有几种交互：

我最近主要在定位、解决当前项目中的一些性能相关问题。

在反馈的问题中，比较严重的问题之一是在户型预览编辑过程，电脑的 CPU 占用率高，及时什么都不做的情况下，CPU 占用也非常的高。

同样的，利用 Chrome 提供的 Performance 录制 ⏺ 了无任何操作的 JavaScript 调用火焰图，发现 Pixi 内部会利用浏览器的requestAnimationFrame接口，执行自身的 render 方法进行 2D 场景的绘制渲染。

随着图满意项目的不断迭代，功能的不断叠加，时不时会有一些用户反馈卡顿，甚至页面崩溃的情况出现。

为了解决和定位问题，我们特意做了用户调研，以及尝试做一些性能监控捕获异常。在调研过程中，我们发现在用户配置较低的电脑上对于 2D 下的一些缩放事件会出现明显的卡顿现象，帧率大概下降到 20fps。

在 2D 界面中，有一个背景网格一直在页面中显示。它的交互要求是：不论界面如何缩放，网格的线段粗细始终保持不变，否则将会出现非常不好看的粗线条以及细线条等。

在 Tumax 项目中，作为编辑器存在非常多的“视图交互”，其中关于显隐就是一块状态复杂、由多重因素影响的交互重灾区。

随着项目的不断迭代，业务需求的不断增多，隐藏的交互事件也逐渐增多（墙体隐藏，吊顶隐藏，地面模型隐藏，硬装下隐藏，选择房间后隐藏，挂墙、门窗跟随隐藏，不同路由显隐不同），这么多显隐逻辑混在一起，逐渐发现我们以前原有的显隐逻辑变得异常混乱。

相信很多  同事在刚刚接触图满意项目时，对项目中的数据流向和数据解析过程都很模糊， 不清楚数据到底是如何从一份 JSON 数据变为我们使用的数据对象。

这篇文章将会为你  介绍图满意项目中，数据的解析还原及数据流向，为你揭开这一神秘面纱。

通过这篇文章，你将会明白数据是如何通过接口返回的 JSON 一步步变为我们可以拿来使用的 Model，同时我会介绍为什么需要这样处理，如果不这样处理带来的  弊端是什么。

需要在模型移动过程中感知到模型一个“十”字形的范围内的所有模型，如有相交则标注相隔距离，如果没有感知到阻挡模型，则显示到墙体的距离。

一开始，当我拿到这个需求的时候，我的第一想法就是在模型的周围做四条射线，如果和其他模型有相交点，则以相交点的位置  做连线。

使用 Vuex 更贴合 Vue 项目，Vuex 支持响应 Vue 内部的响应事件，比如：当某状态改变时 Vue 会同时触发改变 computed,render 等。

但缺点是在其他库中缺无法观察响应 Vuex 中的变化，比如：当 Vuex 中的一个状态值改变，需要对应的触发响应到 ThreeJS 和 PIXI 中去改变摄像机的位置，则需要在某个在生命周期范围内的组件去处理响应事件，并通知到 ThreeJS 和 PIXI 中去改变响应数据。这样整个过程就变得十分麻烦。

为什么我们要做那么多工程化架构上的事情？
这里我引用任正非的一段话：

“软件工程”和“质量工程”需要依靠架构技术，而不是依靠 CMM 和 QA 管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。

开发过程中环境 Host 过多，请下载安装 SwitchHosts Tumax DIY 版 ，进行 Host 统一。