HT图形组件设计之道(三)

上篇我们通过定制了CPU和内存展示界面,体验了HT for Web通过定义矢量实现图形绘制与业务数据的代码解耦及绑定联动,这类案例后续文章还会继续以便大家掌握更多的矢量应用场景,本篇我们先切换个话题,谈谈模型-视图-事件之间的关系。

图形组件设计架构上主要就是在规划Data模型,View视图和Event事件之间的关系,这些年业界逐渐将各种GUI设计模式提炼成理论归类,MVC、MVP和MVVM的主要大类常被统称为MV*,有很多文章进行各种设计模式的定义和比较,本篇不打算深入展开理论的讨论,不同图形组件设计架构都会有很多差异,持续发展的组件其实每时每刻都在进行着各种设计上的改进,相信有很多不错的组件已经创新出了更多新的更实用的设计模型,只不过还未被提炼到理论高度进行归类让世人知晓,因此过细去定义什么是P,什么是VM,哪个功能应该写在哪个部分才算合理我觉得是没太大意义的,只要不断改进产品,团队能更好维护扩展,用户易学易用就够了,理论高度留给Martin Fowler这类神级大师去定义。

提到Martin Fowler因为他的《GUI Architectures》和《Presentation Model》是我较早见到将MVC和MVP理清的文章,从实现角度其实几十年前苹果用于开发Mac OS X的Cocoa Bindings技术已采用了类似的设计,并且Objective-C语言的Key-Value Coding和Key-Value Observing机制,加上XCode工具的可视化支持,可以说多年来早已让众多开发者不知不觉在享受这些设计模型能带来的开发力。Java的Swing界面一直饱受诟病,但其实很早就有JGoodies这样优秀项目,Swing本就不算大众,了解JGoodies更是小众,而更少人了解JGoodies Binding这多年前就实现得非常不错的MVP架构封装,有兴趣的读者可看看JGoodies这篇06年的PPT《Desktop Patterns and Data Binding》

Adobe的Flex和微软的Silverlight/WPF本被业界寄予厚望,没想这哥俩如匆匆过客被老东家抛弃了,但他们还是推动了MVP和MVVM设计模式的普及,如今HTML5领域的KnockoutJS、Backbone.js、AngularJS、PureMVC、Ember.js等众多MV*框架如果雨后春笋般崛起,甚至需要有人专门维护个TodoMVC的网站来:Helping you select an MV* framework!

HT本身也是一套MV*的框架,但我们培训客户时很少过细讨论设计模式,在我看来好的组件封装应该不必让用户纠结于你的设计模式,用户几个月不用你的框架后,依然能快速上手不必有一个重写学习的过程,这是我们最求的理想框架,从这个角度说目前很少有图形框架能让我们满意,相信很多人有类似痛苦的经历,一段时间不用某套框架后,要用时完全忘记如何入手,Swing老手不看老代码不知如何对JTree和JTable添加数据,Flex老手一下子想不起来invalidateProperties,invalidateSize和 invalidateDisplayList这几个自定义组件必掌握函数的细节,SL/WPF老手想不起来定义一个DependencyProperty属性除了AffectsRenderer和AffectsMeasure还有多少要考虑的因素,上段提到的一堆新兴的HTML5界MV*框架,相信更少有人敢说熟练精通,你可能在某个项目中用了好几个月甚至一两年,但一段时间不用你很容易忘记,因此对喊出精通缺乏勇气了,我觉得这不是大家不聪明不勤奋,而是目前的这些框架真还没做到足够好,我们一直努力让HT朝我们觉得满意的方向发展,以后文章我再展开讨论HT如何设计让用户不健忘的API接口。

回到今天模型-视图-事件的话题,Data和View分离后必然需要有Event事件的监听和派发机制来建立起数据绑定,我控制欲比较强不是很喜欢AngularJS那种dirty checking的机制,有事件变化我希望马上被通知到,做我该做的处理,至于有人担心性能问题那是多虑了,图形组件发展这么多年已积累无数成熟技巧来规避事件的性能问题。

性能问题倒不用担心,毕竟这方面任务大部分情况都是交由框架实现者去考虑,但不需要用户深入了解框架的实现细节,并不意味着用户可以完全不关系基本架构脉络,框架应用者还是有必要了解模型-视图-事件之间的引用关联关系,否则容易出现内存泄露的问题,以前经历过一个客户团队设计的客户端框架,可管理所有界面的窗口,结果出现总是OOM的内存溢出,帮他们检查后发现,他们有个全局的WindowManager对象,在每个窗口创建时都会添加对窗口的引用,这样固然貌似很强大,全局都可以控制所有界面窗口,但因为绝大多数开发人员,不会在窗口关闭要销毁时主动去删除全局WindowManager对象的引用,进而导致了所有窗口都能被全局对象引用到而无法垃圾回收,因此框架的使用者还是有必要多框架的机制有所了解才能避免这类的内存泄露问题。

很多情况下内存泄露不是长期的运行也很难发觉,但对于HT的Graph3dView这种基于WebGL的3D组件问题尤为明显,因为大部分浏览器对单个页面能运行的WebGL上下文是有限制的,例如PC上的chrome或firefox也就运行十五六个,手机平板等移动终端会更受限,因此如果出现内存泄露老的上下文没关闭,超越上限时就会出现类型”Too many active WebGL contexts. Oldest context will be lost.”的异常。

以下我对《HT入门手册》的第一个例子做个扩展,对工具条增加了如下代码逻辑的三个按钮,第一个按钮一下子创建了20个新的Tab页,每个Tab页包含一个Graph3dView组件,另外两个按钮实现删除部分页签的功能。

{
    label: ‘Create 20‘,
    action: function(){
        for(var i=0;i<20;i++){
            var tab = new ht.Tab();
            tab.setName(‘tab-‘+i);
            tab.setClosable(true);
            tabView.getTabModel().add(tab);
            var g3d = new ht.graph3d.Graph3dView(dataModel);
            g3d.name = ‘g3d-‘ + i;
            window[‘g3d-‘ + i] = g3d;
            tab.setView(g3d);
        }
    }
},
{
    label: ‘Destroy 5‘,
    action: function(){
        var emptyModel = new ht.DataModel();
        tabView.remove(‘tab-5‘);
        window[‘g3d-5‘].setDataModel(emptyModel);
        delete window[‘g3d-5‘];
        this.disabled = true;
    }
},
{
    label: ‘Destroy 6-10‘,
    action: function(){
        for(var i=6; i<=10; i++){
            tabView.remove(‘tab-‘ + i);
            var emptyModel = new ht.DataModel();
            window[‘g3d-‘ + i].setDataModel(emptyModel);
            delete window[‘g3d-‘ + i];
        }
        this.disabled = true;
    }
}

点击创建20个页签的按钮分别打开页签之后系统的内存对象引用关系如下图所示:

因为dataModel作为全局对象被window应用着,而且其他新创建的页签中的Graph3dView都绑定了该数据模型,框架使用者应该了解,各种组件都对dataModel数据模型添加了事件监听,其实数据模型并不知道各种View的存在,数据模型仅遵循有数据变化后将事件正确的派发给所有消费者,而这20个Graph3dView就是其中的消费者,而Graph3dView中每个有都有一个WebGL的context上下文,因而形成了一条从全局window到dataModel数据模型,再到Graph3dView组件,最后到WebGL上下文的引用关系网,这样自然如果我们不主动断开这个关系,哪怕Tab页签被关闭销毁,Graph3dView依然还会存在系统内存的问题(这个例子我们为了测试方便其实还在window上直接引用了Tab和Graph3dView对象)。

因此由以上视频你会发现在chrome下当点击到第16个包含Graph3dView的页签后就出现了”Too many active WebGL contexts. Oldest context will be lost.”的异常,在WebGL中可通过对Canvas添加webglcontextlost的事件监听可判断自己的上下文被销毁了,并可通过添加webglcontextrestored的事件监听在浏览器资源足够时重新进行恢复。

在我们这个案例中要让系统资源恢复,我们必须让过多的Tab页签中的Graph3dView被彻底回收,因此工具条上的另外两个按钮从代码逻辑可知,我们将Graph3dView设置了一个新的空得DataModel数据模型,使其断开了和全局window.dataModel的引用,当然Tab页签也得删除,从以上视频中也可以看得出当我们销毁了部分Tab页签后就能得到webglcontextrestored的事件恢复,因此第一个”HT for 3D Web”的页签经历了webglcontextlost和webglcontextrestored的过程。

启动初始化时只有”HT for 3D Web”的第一个页签,因此通过Chrome的Debug Profiles可查看到ht.graph3d.Graph3dView的Objects Count项只有1,通过Profiles的Retainers我们还可以清楚的掌握目前达到那些对象引用了Graph3dView对象:

当点击构建20个页签按钮后,Profiles能看到Objects Count为21:

当我们点击两个删除按钮销毁6个Tab页签后发现,Objects Count下降到了15:

最后可以发现第一个HT for 3D Web的页签浴火重生了

这个案例只是为了测试方便因此将dataModel对象作为全局变量,所以引发了一些列内存泄露的资源不足问题,一般项目应用中不用的组件不需要考虑这么复杂,例如还需要断开dataModel引用这些步骤,常规应用场景中例如一个对话框打开后,一般数据模型和视图组件都在这个对话框范围内相互引用,只要确保不出现上文提到的有全局引用能影响这个对话框内的某个对象,那么你在使用完该对话框后不需要做任何处理,那一堆的对象哪怕他们之间引用再复杂甚至互相应用,反正没有全局对象能够再引用到他们,他们统统都会被销毁。

总结下本篇的两个观点:

1、再好的封装设计也需要使用者掌握基本的架构脉络,就像再好的车你也得学会开学会基本的保养,什么都不学的话,再好的框架也会像好车一样被你开坏

2、不要惧怕MV*的事件和引用关系,理清事件机制和对象引用关系后,你可以精确掌控任何时刻的任何内部细节,这点主要针对设计框架者而言,使用者应该大胆的拥抱MV*的框架,性能和各种潜在的内存问题放心的交给框架去解决

HT图形组件设计之道(三),布布扣,bubuko.com

时间: 08-16

HT图形组件设计之道(三)的相关文章

HT图形组件设计之道

咱们号码大全经过定制了CPU和内存展示关键词挖掘工具界面,体会了HT for Web经过界说矢量完成图形制作与事务数据的代码解耦及绑定联动,这类事例后续文章还会持续以便咱们把握更多的矢量使用场景,本篇咱们先切换个论题,谈谈模型-视图-事情之间的联系. 图形组件计划架构上首要即是在计划Data模型,View视图和Event事情之间的联系,这些年业界逐步将各种GUI计划形式提炼成理论归类,MVC.MVP和MVVM的首要大类常被统称为MV*,有许多文章进行各种计划形式的界说和对比,本篇不计划深化翻开理

HT图形组件设计之道(二)

上一篇我们自定义CPU和内存的展示界面效果,这篇我们将继续采用HT完成一个新任务:实现一个能进行展开和合并切换动作的刀闸控件.对于电力SCADA和工业控制等领域的人机交互界面常需要预定义一堆的行业标准控件,以便用户能做可视化编辑器里,通过拖拽方式快速搭建具体电力网络或工控环境的场景,并设置好设备对应后台编号等参数信息,将拓扑图形与图元信息一并保存到后台,实际运行环境中将打开编辑好的网络拓扑图信息,连接后台实时数据库,接下来就是接受实时数据库发送过来的采集信息进行界面实时动态刷新,包括用户通过客户

HT图形组件设计之道(四)

在<HT图形组件设计之道(二)>我们展示了HT在2D图形矢量的数据绑定功能,这种机制不仅可用于2D图形,HT的通用组件甚至3D引擎都具备这种数据绑定机制,此篇我们将构建一个3D飞机模型,展示如果将数据绑定机制运用于3D模型,同时会运用到HT的动画机制,以及OBJ 3D模型加载等技术细节,正巧赶上刚发布的iOS8我们终于能将基于HT for Web开发的HTML5 3D应用跑在iOS系统了. 首选我们需要一个飞机模型,采用HT for Web构建3D模型可采用API组合各种基础模型的方式,但今天

HT图形组件设计之道(一)

HT for Web简称HT提供了涵盖通用组件.2D拓扑图形组件以及3D引擎的一站式解决方式.正如Hightopo官网所表达的我们希望提供:Everything you need to create cutting-edge 2D and 3D visualization. 这个愿景从功能上是个相当长的战线,从设计架构上也是极具挑战性的,事实上HT团队是很保守的,我们从不贪多图大,仅仅做我们感觉自己能得更好,能给用户综合体验更佳的功能,在这样理念驱动下我们慢慢形成了这种愿景,慢慢实现了几个有意义

HTML5 例子学习 HT 图形组件

HTML5 例子学习 HT 图形组件 HT 是啥:Everything you need to create cutting-edge 2D and 3D visualization. 这口号是当年心目中的产品方向,接着就朝这个方向慢慢打磨,如今 HT 算是达到了这样的效果,谈不上用尽洪荒之力,但我们对产品结果很满意,特别是 HT 的用户手册,将例子和文档无缝融合一体,小小 10 来兆开发包居然包含了四十五份手册,数百个活生生的 HTML5 例子,还没体验过的同学可以点击 http://www.

数百个 HTML5 例子学习 HT 图形组件 – 拓扑图篇

HT 是啥:Everything you need to create cutting-edge 2D and 3D visualization. 这口号是当年心目中的产品方向,接着就朝这个方向慢慢打磨,如今 HT 算是达到了这样的效果,谈不上用尽洪荒之力,但我们对产品结果很满意,特别是 HT 的用户手册,将例子和文档无缝融合一体,小小 10 来兆开发包居然包含了四十五份手册,数百个活生生的 HTML5 例子,还没体验过的同学可以点击 http://www.hightopo.com/guide/

HT全矢量化的图形组件设计

HT一直被客户称道的就是其全矢量化的设计特色,矢量相比传统图片好处太多了: 矢量可无级缩放,界面不失真不模糊 描述矢量的文本内容远比图片小得多 目前各种window.devicePixelRatio不一致的设备,矢量可能是唯一彻底的解决方案 业务数据绑定 提起矢量一般都会想到SVG,但这是个坑人的玩意儿,这么多年就没见一个完善的实现者,浏览器实现千差万别,高级属性根本不能玩,Adobe SVG Viewer好多年前就停止更新,Flex支持SVG导入也仅供基本属性玩玩,当然SVG也不是一无是处hi

数百个 HTML5 例子学习 HT 图形组件 – WebGL 3D 篇

<数百个 HTML5 例子学习 HT 图形组件 – 拓扑图篇>一文让读者了解了 HT的 2D 拓扑图组件使用,本文将对 HT 的 3D 功能做个综合性的介绍,以便初学者可快速上手使用 HT 构建例如电信网管 3D 机房应用.水务燃气 SCADA 监控应用及智能楼宇等应用场景. HT for Web 的 3D 是完全基于 WebGL 技术实现的渲染引擎,但开发者几乎不需要了解 3D 图形数学或 Shader 渲染的底层技术,只需要掌握基本的 3D 坐标系和相机  Camera 的概念,剩下需要掌

数百个 HTML5 例子学习 HT 图形组件 – 3D 建模篇

http://www.hightopo.com/demo/pipeline/index.html <数百个 HTML5 例子学习 HT 图形组件 – WebGL 3D 篇>里提到 HT 很多情况下不需要借助 3Ds Max 和 Blender 等专业 3D 建模工具也能做出很多效果,例如  http://www.hightopo.com/guide/guide/core/3d/examples/example_3droom.html 这个 3D 电信机房监控例子整个都是通过 HT 提供的 AP