为了解决用户使用过程中的体验问题,我们团队进行了走访用户调研,在调研过程中发现:在一些配置较差的机器上存在拖动模型异常卡顿的情况。
从以上的交互动图中可以观察发现,在已经实现的功能中,家具拖动过程中包含有几种交互:
为了解决用户使用过程中的体验问题,我们团队进行了走访用户调研,在调研过程中发现:在一些配置较差的机器上存在拖动模型异常卡顿的情况。
从以上的交互动图中可以观察发现,在已经实现的功能中,家具拖动过程中包含有几种交互:
我最近主要在定位、解决当前项目中的一些性能相关问题。
在反馈的问题中,比较严重的问题之一是在户型预览编辑过程,电脑的 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 统一。
Update your browser to view this website correctly. Update my browser now