性能优化之事件响应与相交算法
故事背景
为了解决用户使用过程中的体验问题，我们团队进行了走访用户调研，在调研过程中发现：在一些配置较差的机器上存在拖动模型异常卡顿的情况。
从以上的交互动图中可以观察发现，在已经实现的功能中，家具拖动过程中包含有几种交互：
* 家具移动
* 框选多个家具移动
* 与周围家具吸附交互
* 与墙体吸附交互
* 与墙体碰撞功能（在家具未完全移动出墙体时，保持模型在房间内）
* 与其他家具叠放
* 实时计算显示家具周围标注（实现模型周边感应功能）
在这么多交互同时运行中，肯定会出现一些计算过程，那么如何能够在不影响原有交互的基础上，实现更加高效低耗的实现过程呢？
发现问题
一个命名引发的性能问题
故事背景
我最近主要在定位、解决当前项目中的一些性能相关问题。
在反馈的问题中，比较严重的问题之一是在户型预览编辑过程，电脑的 CPU 占用率高，及时什么都不做的情况下，CPU 占用也非常的高。
同样的，利用 Chrome 提供的 Performance 录制 ⏺ 了无任何操作的 JavaScript 调用火焰图，发现 Pixi 内部会利用浏览器的requestAnimationFrame接口，执行自身的 render 方法进行 2D 场景的绘制渲染。
发现问题
初步定位，CPU 占用只可能与 2D 场景中 PIXI 的 render() 有关系，使用 Performance 分析事
Pixi 1px线段性能优化
故事背景
随着图满意项目的不断迭代，功能的不断叠加，时不时会有一些用户反馈卡顿，甚至页面崩溃的情况出现。
为了解决和定位问题，我们特意做了用户调研，以及尝试做一些性能监控捕获异常。在调研过程中，我们发现在用户配置较低的电脑上对于 2D 下的一些缩放事件会出现明显的卡顿现象，帧率大概下降到 20fps。
需求
在 2D 界面中，有一个背景网格一直在页面中显示。它的交互要求是：不论界面如何缩放，网格的线段粗细始终保持不变，否则将会出现非常不好看的粗线条以及细线条等。
除了 2D 网格需要此交互，项目中任意物体的描边也同样需要次交互需求，如：墙体描边，门窗描边，标注线等。
问题发现
在之
Tumax-复合状态管理（显隐问题）
故事点介绍
在 Tumax 项目中，作为编辑器存在非常多的“视图交互”，其中关于显隐就是一块状态复杂、由多重因素影响的交互重灾区。
技术难点
随着项目的不断迭代，业务需求的不断增多，隐藏的交互事件也逐渐增多（墙体隐藏，吊顶隐藏，地面模型隐藏，硬装下隐藏，选择房间后隐藏，挂墙、门窗跟随隐藏，不同路由显隐不同），这么多显隐逻辑混在一起，逐渐发现我们以前原有的显隐逻辑变得异常混乱。
举个简单的例子：
在户型导航的逻辑中，要求对选中的房间以外的所有模型数据都隐藏，当我们执行这样的操作后，表现正常
在墙体隐藏的逻辑中，要求遮挡观察实现的墙体全部隐藏，当不遮挡视线后再恢复显示
1. 选择单
Tumax-H5数据流向及解析
说明
相信很多 同事在刚刚接触图满意项目时，对项目中的数据流向和数据解析过程都很模糊， 不清楚数据到底是如何从一份 JSON 数据变为我们使用的数据对象。
这篇文章将会为你 介绍图满意项目中，数据的解析还原及数据流向，为你揭开这一神秘面纱。
通过这篇文章，你将会明白数据是如何通过接口返回的 JSON 一步步变为我们可以拿来使用的 Model，同时我会介绍为什么需要这样处理，如果不这样处理带来的 弊端是什么。
当阅读完文章后，需要对图满意项目有明确的数据流向认知，清晰 明了的了解 dataObject、ModelData 及 Model 的区别。后续开发业务代码需要
实现模型周边感应功能
需求目标
需要在模型移动过程中感知到模型一个“十”字形的范围内的所有模型，如有相交则标注相隔距离，如果没有感知到阻挡模型，则显示到墙体的距离。
方案思路
一开始，当我拿到这个需求的时候，我的第一想法就是在模型的周围做四条射线，如果和其他模型有相交点，则以相交点的位置 做连线。
下一秒就产生了一个问题，如图。
在这样的情况下，标注线应该标注最近的那一个模型，但是却标注到了另外一个模型。
但有一点是母庸质疑的，那就是他需要有四条标注线，要分开来一条一条处理。
接着，拿其中一条边来说，是否应该要找到最近的一个模型？
这两种情况都证明了上面这种思路的问题所在，要考虑方向
Tumax-H5设计要点
H5 项目中数据与视图的同步响应
Vuex 中不能解决的问题
使用 Vuex 更贴合 Vue 项目，Vuex 支持响应 Vue 内部的响应事件，比如：当某状态改变时 Vue 会同时触发改变 computed,render 等。
但缺点是在其他库中缺无法观察响应 Vuex 中的变化，比如：当 Vuex 中的一个状态值改变，需要对应的触发响应到 ThreeJS 和 PIXI 中去改变摄像机的位置，则需要在某个在生命周期范围内的组件去处理响应事件，并通知到 ThreeJS 和 PIXI 中去改变响应数据。这样整个过程就变得十分麻烦。
另外，当 ThreeJS 中有任何数据改变，反过来如果要触
Tumax-开发规范与说明
引言
为什么我们要做那么多工程化架构上的事情？
这里我引用任正非的一段话：
“软件工程”和“质量工程”需要依靠架构技术，而不是依靠 CMM 和 QA 管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。
必要软件
开发过程中环境 Host 过多，请下载安装 SwitchHosts Tumax DIY 版 ，进行 Host 统一。
在 DIY 版 SwitchHosts 中，已经预制了项目中所需的各个环境，并有定时更新。后续如有 host 变动，会直接在服务器修改，软件会自动同步。
下载地址：http://192.168
