作为当今主流的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文件，然后浏览器将其展示出来。

OpenLaszlo应用由LZX的文件组成。LZX是一种标准驱动的XML和JavaScript描述性的语言，它使得上述声明式的（declarative）、基于文本的开发流程变为可能。列表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展示了该程序的界面。

由于联系人的功能和教程上的基本相同，我们使用了和OpenLaszlo指南中相同的方法来实现它。列表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的客户端从远程的服务器中获得数据的情景。

<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描述了具体的代码。

<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的视图。

<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所示。

<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。

<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展示了实验的具体配置。

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

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

参考资料

• Software Engineer's Guide to Developing Laszlo Applications, Chapter 33: Building Data-Driven Applications.
  
  
• Software Engineer's Guide to Developing Laszlo Applications, Appendix A. Understanding Instantiation.
  
  
• developerWorks 中国网站 XML 专区：http://www.ibm.com/developerworks/cn/xml