posts - 431,  comments - 344,  trackbacks - 0
本文对如何开发高效的OpenLaszlo应用展开了深入的讨论。结合官方的开发指南,笔者对如何获得满意的性能给出了自己的最佳实践。这些建议主要涵盖了延缓初始化时间、惰性复制数据、缓存数据等三方面内容。

作为当今主流的Rich Internet Application应用平台,OpenLaszlo为用户界面开发人员提供了强大的API来创建基于Flash的富客户端程序。虽然OpenLaszlo拥有简洁、快速的开发方式,但是我们仍然需要投入大量精力来关注数据驱动的OpenLaszlo应用的性能。本文对如何开发高效的OpenLaszlo应用展开了深入的讨论。结合官方的开发指南,笔者对如何获得满意的性能给出了自己的最佳实践。这些建议主要涵盖了延缓初始化时间、惰性复制数据、缓存数据等三方面内容,并以具体的试验数据来说明它们的有效性。

1. OpenLaszlo简介

在Web应用越来越关注用户体验的今天,传统的HTML应用已经不能满足开发人员和终端用户的需求。OpenLaszlo作为当今主流的RIA(Rich Internet Application)的应用平台,在进入开源社区之后显示出了更大的活力。Laszlo的技术基于XML和JavaScript来构建RIA程序,为Web开发人员提供了一种简洁快速的编程模式,并且给终端用户以更加动态的交互式体验。

OpenLaszlo的SDK(Standard Development Kit)由一个用Java编写的编译器、一个运行时的JavaScript库和一个可选的Java Servlet构成,如图1.1所示。开发OpenLaszlo的步骤非常简单:编辑、保存和刷新源文件即可。开发人员可以使用任何文本编辑器来编辑源文件,并且将其对应的URL键入浏览器。OpenLaszlo服务器自动地将文件编译成一个Flash文件,然后浏览器将其展示出来。


图1.1 Laszlo服务器的总体架构
图1.1 Laszlo服务器的总体架构

OpenLaszlo应用由LZX的文件组成。LZX是一种标准驱动的XML和JavaScript描述性的语言,它使得上述声明式的(declarative)、基于文本的开发流程变为可能。列表1.2展示了一段简单的OpenLaszlo程序代码,它定义了一个按钮,用户在按下之后该按钮的位置会向右移动一段固定的距离。


列表1.2 一个简单的OpenLaszlo应用
<canvas height="30">
  <button onclick="animate('x', 100, 1000, true)">
    Move me
  </button>
</canvas>

在下一章,我们将根据OpenLaszlo官方的开发指南,构建一个数据驱动的应用程序,并对其进行深入的分析和调试。







2. 开发数据驱动的应用程序

2.1 一个典型的应用场景

为了更加清楚地说明我们的主题,我们根据OpenLaszlo的官方软件开发指南[1],扩展了其中通讯录的示例。这个应用提供了一个功能齐全的联系人列表,它列出了所有的联系人,并允许用户对联系人添加、删除和更新。唯一不同的是,我们的程序为用户提供了更多的选项,包含了更多的数据。图2.1展示了该程序的界面。


图2.1 一个通讯录的应用
图2.1 一个通讯录的应用

由于联系人的功能和教程上的基本相同,我们使用了和OpenLaszlo指南中相同的方法来实现它。列表2.2描述了应用中一个类contactview的部分代码。


列表2.2 联系人视图(contactview)的源代码
<class name="contactview" extends="view" visible="false" x="20"
height="180">
    <simplelayout axis="y" spacing="5" />
    <view layout="axis:x; spacing: 10">
        <text y="10">First Name:</text>
        <edittext name="firstName" datapath="firstName/text()" y="10"/>
        <text y="10">Last Name:</text>
        <edittext name="lastname" datapath="lastName/text()" y="10"/> 
		
    </view>
    <view>
        <text x="0" y="10">Gender:</text>
        <radiogroup layout="axis: x" x="80" y="12" datapath="gender" >    
           <attribute name="genderv" type="string" value="$path{'text()'}"
		   />
           <method event="ondata">
              this.selectItem(this.getAttribute('genderv'));
           </method>            
           <radiobutton value="'M'" text="Male" />
           <radiobutton value="'F'" text="Female"/>
        </radiogroup>
        <text x="195" y="10">Country:</text>
        <mycombobox x="275" y="10" width="105" 
            datapath="country/text()">
            <textlistitem value="${this.text}" 
                datapath="timedata:/time/day/item/text()"/>
        </mycombobox>
    </view>
</class>

此外,虽然应用的数据存储在本地机器的XML文件中,但如列表2.3所示,我们对数据集的type和request属性做了设置,使应用程序在运行时才能够得到数据。在这种情况下,我们能够模拟OpenLaszlo的客户端从远程的服务器中获得数据的情景。


列表2.3 数据集的设置
<dataset name="countrydata" request="true" type="http" src="countries.xml"/>

2.2 系统瓶颈

完成上述应用之后,性能问题迅速地显现出来。系统主要在以下三方面表现出了性能的瓶颈:

1. 程序初始化的时间很长。当列表达到30个联系人条目的规模时,程序就会花费很长时间来显示整个列表。在程序装载的过程中,这些条目逐条缓慢地显示出来。而在此期间,用户几乎不可能进行任何操作。

2. 下拉框(combobox)的初始化时间长度令人难以接受。当下拉框的选项非常多时,由于控件会等待列表初始化完毕后才变为可见,这将会耗费大量的时间和内存。

3. 删除功能的表现也不尽如人意,尤其在用户尝试删除位于顶端的条目。当一个条目被删除时,在其之下的条目将会被完全地刷新。这样的重画界面也引发了严重的性能问题。鉴于以上的性能问题,我们将逐步讨论如何解决这些问题。在第三章中,我们会阐述一些能够提高性能的普遍原则,并应用到本章所演示的程序里。进一步的,第四章将描述本文所涉及的实验方法,并且向读者展现比较实验的结果。






3. 优化OpenLaszlo程序的原则

3.1 延缓初始化时间

在默认情况下,OpenLaszlo会在加载页面时对所有的元素全部进行初始化。无论这些元素是可见或不可见的,它们都会被实例化。同时,OpenLaszlo提供了initstage属性来控制何时执行节点的init方法以及发送oninit事件的时机。initstage是LzNode的属性,换言之,它几乎可以被所有的元素继承并使用,它有五种可选的属性值[2]:

  • immediate
    除非该实例的所有子节点被创建,否则其他代码都不得运行。也就是说,初始化是实例化的最后一个阶段。
  • early
    在视图(view)和它的子节点被创建后,立即调用init方法。
  • normal
    系统缺省值。Init方法在初始化父节点的工作完成后被调用。
  • late
    在系统空闲时(idle)初始化节点。用户可以通过检查isinited属性来确认节点是否被初始化完毕。如果想在某一时刻强制节点初始化,可以调用completeInstantiation方法。
  • defer
    在该设置下,除非用户显式地调用completeInstantiation,否则节点将不会被初始化。

不难看出,使用late和defer的节点,在执行init方法以及发送oninit事件时,并不一定被初始化完毕。因此,它们非常适用于延缓OpenLaszlo节点的初始化时间。对一些在页面初次加载时不可见的节点,我们可以使用initstage = defer来抑制初始化,在触发其可见的事件上按需调用completeInstantiation。这样既可以减少页面初始化的时间,又可以减少很多不必要的初始化。因为对用户而言,很多不可见的元素是不需要被加载进系统的。

具体到我们的通讯录应用中,显示联系人细节的视图(contactview)完全符合上述的条件。于是,我们将其initstage的属性设为defer,并且重写了其父节点的onclick事件,使得只有在用户点击了条目后,细节视图才会占用系统的资源,按需地被初始化。列表3.1描述了具体的代码。


列表3.1延缓初始化时间的代码
<view id="newEntryView">
    <text text="New Entry..." > 
        <method event="onclick">
                parent.newContactView.setVisible(!parent.newContactView.visible);
                //在点击时完成初始化
                parent.newContactView.completeInstantiation(); 
        </method>
</text>
<contactview name="newContactView" 
     datapath="newcontact:/contact"
     initstage="defer"> <!--在页面初次加载时不初始化contactview-->
     <button width="80" x="300" text="Add" />
</contactview>

3.2 惰性复制数据

用户界面中,经常存在实际条目比展示给用户的条目多的列表。OpenLaszlo为这种情况在baselist、basecombobox等节点中定义了dataoption属性。当dataoption取lazy值时,列表的条目(listitem)将会使用惰性复制,即只复制需要显示的条目。通讯录中表示国家的下拉框有近200个选项,就属于这种情况。在列表3.2中,我们自定义了一个下拉框类,并附上了它的使用示例。这样,即使有200个数据项,系统也只复制了5个textlistitem的视图。


列表3.2 使用惰性复制的下拉框
<class name="mycombobox" extends="combobox" editable="false"
      shownitems="5" 
      dataoption="lazy" />
<mycombobox id="country" x="275"
      width="105" 
      datapath="country/text()">
<textlistitem datapath="countrydata:/countries/country/text()" 
          value="${this.text}" />
</mycombobox>

值得一提的是,我们在<textlistitem>中直接定义了datapath属性,因此它继承了父节点dataopiton = lazy的特征。如果在<textlistitem>下单独定义datapath元素,那么我们还必须将其replication属性设为lazy,如表3.3所示。


列表3.3 单独声明datapath的textlistitem
<mycombobox >
<textlistitem value="${this.text}" >
    <datapath xpath="countrydata:/countries/country/text()" 
         replication = "lazy" />
</textlistitem>
</mycombobox>

事实上,OpenLaszlo使用惰性复制的列表使用LzLazyReplicationManager而不是缺省的LzReplicationManager来控制视图。后者在视图的datapath和多个datanode匹配时,为每一个匹配都创建一个视图;而前者出于显示数据的考虑,只创建足够数量的视图。本文的例子中,通讯录的条目过多时(如超过100条),也可以考虑使用lazy的属性使初始化时间变快。

3.3 缓存数据

假使OpenLaszlo应用使用了数据复制,而且这些数据在运行时改变的话,默认的LzReplicationManager会将数据改变所对应的视图销毁,然后重新创建它们。显而易见,如果数据集非常大,这样的调整策略会导致用户界面严重的反应迟缓。如第二章所述,我们的通讯录应用在删除位于列表顶端的记录时,就会出现明显的延迟。

为了解决上述问题,我们可以将匹配多个数据节点的datapath中的pooling属性设为true。设置之后,LzLazyReplicationManager只是将改变了的数据重新指向已经被创建的视图。这样用户界面所反映出的数据更新速度会明显加快,具体的应用见列表3.4。


列表3.4 使用pooling属性
<view>
    <datapath xpath="dset:/phonebook/contact" pooling="true" />
    <simplelayout axis="y" />
    <view name="list" >
      <!-- more... -->
    </view>
</view>





4. 性能比较和分析

4.1 测试方法和模型

最后,我们将对本文提及的实验进行性能的监测和调试。根据上文的原则,我们采用OpenLaszlo 3.3.3,对性能优化前后的结果进行比较。表4.1展示了实验的具体配置。


表4.1 实验环境的配置
CPU 内存大小 Total paging space 浏览器类型
1698MHz 512MB 1.22GB Mozilla Firefox 1.5.0.4

测量OpenLaszlo代码的性能分为两种:加载时间和响应时间。前者说明了OpenLaszlo的应用在多久之内被初始化,而后者则是衡量程序能够响应用户动作的敏捷程度,比如在通讯录应用中完成"删除"功能的时间长度。对于这两种时间,我们都在程序开始和结尾记录时间,然后将两者相减,得到最后的结果。列表4.2展示了这种方法的实现代码。


列表4.2 测量响应时间
<button width="80" text="Delete">
    <method event="onclick">
        var pre = (new Date).getTime(); //记录开始执行时间
        parent.parent.parent.datapath.deleteNode();
        var cur = (new Date).getTime(); //记录结束时间
        debug.write(cur - pre); //输出
    </method>
</button>

4.2 测试结果

我们分别对通讯录中有3条、9条和30条记录的情况做了比较。我们逐项应用上述的原则:所有表示时间的实验数据单位为毫秒(ms)。最后的结果由10次操作的平均时间得到。首先,我们将 "initstage = defer"前后的初始化时间的比较列在表4.3。可以看到,在联系人的细节视图不被加载的时候,初始化的时间有了明显的加快。


表4.3使用defer的性能比较
记录数目 initstage = defer(ms) initstage = normal(ms) 降低幅度(%)
3 268.4 3277.8 91.82
9 433.6 10816.8 95.99
30 955.2 54734.7 98.25

其次,表4.4展示了在使用"pooling"前后的响应时间。


表4.4 使用pooling的响应时间比较
记录数目 pooling = true(ms) pooling = false(ms) 降低幅度(%)
3 28.00 136.14 79.43
9 77.00 728.00 89.42
30 467.67 3079.25 84.81

最后,本文描述"lazy"选项的效果,如表4.5所示。不难看出,"lazy"选项与上述的选项不同,没有随着记录的增多而对性能有显著的改善。显然,这是因为"lazy"针对的是单个更新视图的初始化时间,和总体记录的条数没有明显的关系。


表4.5 使用lazy的性能比较
记录数目 dataoption = true(ms) dataoption = none(ms) 降低幅度(%)
3 838 7213.6 88.38
9 852 7344.5 88.40
30 961.4 8587.1 88.80






参考资料

posted on 2007-01-30 23:02 周锐 阅读(424) 评论(0)  编辑  收藏 所属分类: RIA

只有注册用户登录后才能发表评论。


网站导航: