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官方的开发指南，构建一个数据驱动的应用程序，并对其进行深入的分析和调试。
为了更加清楚地说明我们的主题，我们根据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"/> |
完成上述应用之后，性能问题迅速地显现出来。系统主要在以下三方面表现出了性能的瓶颈：
1. 程序初始化的时间很长。当列表达到30个联系人条目的规模时，程序就会花费很长时间来显示整个列表。在程序装载的过程中，这些条目逐条缓慢地显示出来。而在此期间，用户几乎不可能进行任何操作。
2. 下拉框（combobox）的初始化时间长度令人难以接受。当下拉框的选项非常多时，由于控件会等待列表初始化完毕后才变为可见，这将会耗费大量的时间和内存。
3. 删除功能的表现也不尽如人意，尤其在用户尝试删除位于顶端的条目。当一个条目被删除时，在其之下的条目将会被完全地刷新。这样的重画界面也引发了严重的性能问题。鉴于以上的性能问题，我们将逐步讨论如何解决这些问题。在第三章中，我们会阐述一些能够提高性能的普遍原则，并应用到本章所演示的程序里。进一步的，第四章将描述本文所涉及的实验方法，并且向读者展现比较实验的结果。
|
在默认情况下，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> |
用户界面中，经常存在实际条目比展示给用户的条目多的列表。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所示。
列表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的属性使初始化时间变快。
假使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> |
|
最后，我们将对本文提及的实验进行性能的监测和调试。根据上文的原则，我们采用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展示了这种方法的实现代码。
<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> |
我们分别对通讯录中有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 |
|
本文为OpenLaszlo的开发者提供了一些提高程序性能的技巧，具体包括：延缓初始化的时间、惰性复制和缓存数据。我们通过扩展OpenLaszlo开发指南中的示例，向读者展示了一个略微复杂的通讯录应用。以其为场景分析了系统的性能瓶颈，将作者所总结出的技巧应用于其上。最后，我们还对每个具体的原则做了实验，比较了性能的差异。从我们的实验中可以看到，本文所提及的原则对性能的提高有着显著的作用。相应的用户体验也有了明显的提升，达到了用RIA开发的目的。
在今后的工作中，我们将进一步优化这个示例，使其成为一个能和后台Java Server进行交互的应用，并开发出相应的OpenLaszlo组件。更进一步的，我们会在此基础上为应用添加更多（诸如全球化）的特性。