西西河

主题:【原创】新时代新潮流WebOS 【1】 -- 邓侃

共:💬594 🌺1902
全看分页树展 · 主题 跟帖
家园 【讨论】有几点看法

1. 只要有风吹草动的事件发生,XML DOM Tree就要不厌其烦地一遍又一遍搜索发生事件的节点。如果XML DOM Tree结构比较大,那么搜索的成本就很高。

2. 在确定谁去处理事件,什么时候处理的过程中,需要从根节点沿capture path一路访问到目标节点,再沿bubbling path一路返回根节点,事件处理的过程很长。

如果换用链表结构,执行效率会提高很多。

邓兄此处的结论有点绝对了。

第一、数据结构方面,树搜索O(logN)要比链表搜索O(N)快将近一个数量级

第二、树状结构能够更有效的组织UI的各个元素。管理起来综合成本其实是偏低的

第三、链表不过是树结构的一种特例(单叉树),很多毛病还是继承下来了。

譬如在Figure 1中,共有5个characters。在浏览器渲染页面的时候,可以同时生成一个bitmap。页面中每个character对应bitmap中一个剪影,这样bitmap中有5个剪影。当用户移动鼠标时,鼠标所在剪影的光素的值,对应着这个character的depth。这样只需要O(1)的成本,就可以确定事件发生在哪一个character上。

这里似乎概念不太清晰。前面的种种讨论都是局限于Object Model,这里讨论的其实是Presentation Layer。Tree一样可以照此办理,而且结果只会比List快,因为可以砍掉完全无关的子树,最终得到的bitmap只怕还要薄上两分。

当然,速度提高的代价是占用更多内存空间,也就是bitmap占用的空间。不过减少 bitmap尺寸的办法很多,譬如一个简单的办法是把原图像中相邻的四个光素合并成一个光素,这样就缩小了3/4的空间占用,如Figure 1中右图所示。这样做的后果,是当鼠标移动到characters边缘时,事件触发的精度不够高,但是对于绝大用户而言,事件触发的精度可能不需要太高。

为了优化UI而引入Bitmap, 为了减小内存的占用反而又去牺牲UI的可用性,这个Tradeoff不划算啊。

2. 链表可以支持多个characters处理同一个事件。譬如事件发生于Figure 1中左边人物,但是作为响应,不仅左边人物有相应动作,而且脚下阴影也随之变化。实现这个关联动作的办法很简单,在左边人物处理完事件以后,主动调用阴影的相关动作,而不需要沿capture path和bubbling path访问一圈。

这个并不是List带来的好处,而是Bitmap Z轴带来的好处,可以跟上面的观点合并。

我觉得现在的UI系统已经在各个方面做了很大的优化,考虑了方方面面的情况。既要易用,又要防止WCET爆炸,还要兼顾扩展性。这里扩展性既是extensible也是scalable。想要进一步优化不动动用户的奶酪(用户体验)怕是不行啊。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河