Phát triển các ứng dụng web di động nhẹ với Dojo Mobile

Các xem xét về tối ưu hóa và hiệu năng

Dojo Mobile là một bộ tiện ích dựa trên Dojo để tạo các ứng dụng web di động. Với Dojo Mobile, bạn có thể phát triển các ứng dụng web di động nhẹ, hiệu năng cao. Trong bài này, hãy tìm hiểu xem Dojo Mobile giải quyết các vấn đề hiệu năng như thế nào và cách bạn có thể tối ưu hóa các ứng dụng người dùng dựa trên-Dojo Mobile để làm cho chúng càng nhỏ và càng hiệu quả càng tốt. [Một vài thông tin chi tiết đã được tạo ra trong bài này để phản ánh tốt hơn ý định ban đầu của tác giả].

Yoshiroh Kamiyama, Kỹ sư phần mềm, IBM

Photo of Yoshiroh KamiyamaYoshiroh Kamiyama là một kỹ sư tư vấn phần mềm tại Phòng thí nghiệm phần mềm Yamato (YSL - Yamato Software Lab), Nhật Bản của IBM. Ông làm về Gói tính năng WebSphere cho Web 2.0 và di động (WebSphere Feature Pack for Web 2.0 and Mobile) và trước đó ông đã làm về một số dự án phát triển gồm Ứng dụng Mobile Mashup (hỗn hợp di động), Lotus iNotes và Rational Portfolio Manager (Trình quản lý danh mục Rational), nhiều dự án trong số đó sử dụng Bộ công cụ Dojo. Ông là một người đóng góp ban đầu của dojox.mobile và người đóng góp hàng đầu cho Bộ công cụ Dojo (Dojo Toolkit).



13 12 2011 (Xuất bản lần đầu tiên vào ngày 18 11 2012)

Giới thiệu Dojo Mobile

Tải về và dùng thử Xem trước Công nghệ Di động của IBM

Hãy bắt đầu xây dựng các ứng dụng di động, mở rộng và tích hợp vào doanh nghiệp với Xem trước Công nghệ Di động của IBM (IBM Mobile Technology Preview). Các mẫu mã và dịch vụ trong bản xem trước này gồm có một dịch vụ thông báo RESTful; PhoneGap, một khung công tác nguồn mở để xây dựng các ứng dụng di động lai; một thời gian chạy của WebSphere Application Server (Máy chủ ứng dụng WebSphere) nhẹ; và mã mẫu để cho phép bạn xem tất cả chúng hoạt động như thế nào.

Hầu hết các điện thoại di động trên thị trường hiện nay đều có các trình duyệt web đầy đủ tính năng mà hầu như không thể phân biệt được các trình duyệt web này với các trình duyệt của máy tính để bàn. Những trình duyệt web di động này có thể xử lý hầu hết các công nghệ web gần đây như HTML5, CSS3, JavaScript, xử lý DOM và Ajax.

Dojo Toolkit đã đang phát triển ứng dụng web cho máy tính để bàn và Dojo có thể chạy trên các trình duyệt web di động. Kể từ đó Dojo đã cung cấp rất nhiều tiện ích có ích, vậy chúng ta có thực sự cần một cái gì đó riêng cho các ứng dụng di động không? Có, vì nhiều lý do:

  1. Thiết bị đầu vào khác nhau: Hầu hết các thiết bị di động không có chuột hoặc bàn phím vật lý. Thay vào đó, chúng có một màn hình cảm ứng hỗ trợ các hoạt động ngón tay. Những tương tác của người dùng trên các ứng dụng máy tính để bàn — các hoạt động kéo và thả, các hành động di chuột, các phím tắt trên bàn phím và chuyển hướng (đi ngang sử dụng phím TAB hoặc các phím mũi tên) và v.v.. — đặt ra một thách thức trên thiết bị di động. Bất kỳ các tiện ích (widget) giao diện người dùng nào cho di động cũng cần có khả năng cảm ứng.
  2. Kích thước màn hình nhỏ hơn: Màn hình của thiết bị di động nhỏ và người dùng sử dụng một ngón tay trên màn hình cảm ứng. Điều rất quan trọng là thiết kế đúng giao diện người dùng cho di động. Ngoài ra, kích thước màn hình của một thiết bị máy tính bảng lớn hơn nhiều so với một màn hình của máy điện thoại thông minh. Các ứng dụng web di động cần một giao diện người dùng có thể thay đổi theo kích thước màn hình hoặc định hướng màn hình.
  3. Các vấn đề hiệu năng: Trong khi sức mạnh của bộ xử lý của các thiết bị di động đang tăng lên nhanh chóng, các thiết bị di động vẫn có khả năng tính toán thấp hơn so với các máy tính để bàn. Ngoài ra, băng thông của mạng di động thấp hơn nhiều so với băng thông của một máy tính để bàn; đôi khi nó cực kỳ thấp. Các ứng dụng web di động có dung lượng vô cùng nhỏ và có khả năng trình diễn cao.

Hãy nhận Gói tính năng của IBM WebSphere Application Server cho Web 2.0 và Di động

Gói tính năng của IBM WebSphere Application Server cho Web 2.0 và Mobile gồm có Bộ công cụ IBM Dojo 1.7, các khối xây dựng ứng dụng Internet (RIA) phong phú và di động mới và một thành phần biểu đồ dựa trên Dojo. Với các công cụ Rational kèm theo, Gói tính năng này giúp bạn nhận được các ứng dụng WebSphere ban đầu đã phát triển cho các trình duyệt máy tính để bàn và thích ứng và triển khai chúng cho các thiết bị di động.

Dojo Mobile là một bộ tiện ích dựa trên Dojo để tạo ra các ứng dụng web di động. Nó đã được giới thiệu trong Dojo 1.5 là dojox.mobile để giải quyết các vấn đề trên. Tuy nhiên, thiết bị đầu vào và các vấn đề kích thước màn hình có thể được giải quyết bằng cách tiếp cận truyền thống, có nghĩa là, chỉ cần nâng cao các tiện ích Dojo hiện có bằng cách bổ sung sự hỗ trợ cho di động mà không cần tạo phiên bản các tiện ích mới cho di động. Nhưng rõ ràng là không thể giải quyết các vấn đề hiệu năng theo cách đó. Vì vậy, một trong những nhiệm vụ quan trọng nhất (và đầy thử thách) cho Dojo Mobile là giải quyết các vấn đề hiệu năng, đặc biệt là giảm thiểu kích cỡ mã.


Các tiện ích giao diện người dùng không dùng hình ảnh

Một trong những tính năng thú vị của Dojo Mobile là nó không sử dụng bất kỳ các hình ảnh nào để xây dựng các tiện ích giao diện người dùng. Các trình duyệt dựa trên-WebKit, là những trình duyệt phổ biến nhất trên các thiết bị di động, hỗ trợ CSS3. Các tính năng CSS3, ví dụ như các nền đổi mầu, các hộp có góc tròn và phép chuyển đổi của các phần tử DOM, có thể xử lý biểu diễn đồ họa mà không cần sử dụng các hình ảnh. Hình 1 cho thấy một số các tiện ích giao diện người dùng do Dojo Mobile cung cấp. Các tiện ích này không sử dụng các hình ảnh, thay vào đó, chúng sử dụng các phần tử DOM như <div> với các phong cách CSS để xây dựng giao diện người dùng của chúng. Việc sử dụng nhiều hình ảnh có thể làm tăng tổng dung lượng tải về và tăng số các yêu cầu HTTP đến máy chủ, gây ra sự suy giảm hiệu năng. Dojo Mobile tránh điều đó bằng cách sử dụng khả năng của CSS3 càng nhiều càng tốt.

Hình 1. Các tiện ích Dojo Mobile không dùng hình ảnh
Các tiện ích Dojo Mobile không dùng hình ảnh có các UI

Mặt khác, các ứng dụng người dùng có thể sử dụng các hình ảnh. Hình 2 cho thấy những ví dụ được cung cấp như là các tệp kiểm tra của Dojo Mobile. Như bạn có thể thấy, các nút thanh tab, các biểu tượng mục danh sách và các biểu tượng của thùng chứa biểu tượng là những hình ảnh. Việc sử dụng quá nhiều hình ảnh có thể làm suy giảm hiệu năng, nhưng đó là một sự lựa chọn cho ứng dụng. Chính Dojo Mobile không sử dụng các hình ảnh, nhưng cũng không bắt buộc ứng dụng người dùng không sử dụng hình ảnh. Hơn nữa, như bạn sẽ thấy sau này, Dojo Mobile cung cấp một số cơ chế có ích, chẳng hạn như các Nút ấn DOM và CSS sprite (một tập các hình ảnh đặt trong một hình ảnh đơn), có thể làm giảm nhu cầu về các hình ảnh và giảm số lượng các yêu cầu HTTP đến máy chủ.

Hình 2. Các hình ảnh của ứng dụng người dùng
Các hình ảnh ví dụ do các ứng dụng người dùng sử dụng

CSS Sprite

Khi không thể tránh được việc sử dụng hình ảnh, có hai cách có thể giảm thiểu suy giảm hiệu năng. Một cách là làm giảm kích cỡ tệp các hình ảnh của bạn bằng cách giảm số lượng màu hoặc tăng tỷ lệ nén. Một cách khác là làm giảm số các yêu cầu HTTP đối với các hình ảnh bằng cách gộp chung nhiều hình ảnh nhỏ thành một hình ảnh lớn. Hình ảnh lớn đã gộp lại có thể được cắt bớt và điều chỉnh bằng các thuộc tính CSS sao cho có thể sử dụng nó như là một trong những hình ảnh nhỏ. Kỹ thuật này được gọi là CSS Sprite và Dojo Mobile hỗ trợ nó.

Liệt kê 1 cho thấy một ví dụ về các mục danh sách, mỗi mục sử dụng một biểu tượng riêng. Hình 3 cho thấy kết quả. Ví dụ này tạo ra ba yêu cầu HTTP cho các hình ảnh.

Liệt kê 1. Các mục danh sách có các hình ảnh riêng
<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-1.png" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-2.png" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-3.png" moveTo="bar">Store</li>
</ul>
Hình 3. Kết quả của Liệt kê 1
Kết quả của của các mục danh sách có các hình ảnh riêng biệt

Mặt khác, Liệt kê 2 cho thấy một ví dụ có sử dụng một hình ảnh gộp chung (i-icon-all.png), được các mục danh sách chia sẻ. Bằng cách chỉ rõ các giá trị được phân cách bằng dấu phẩy (top, left, width, height) cho đặc tính iconPos của các tiện ích ListItem, bạn có thể sử dụng lại bất kỳ vùng hình chữ nhật nào của hình ảnh gộp chung. Như thể hiện trong Hình 4, có kết quả tương tự, nhưng nó chỉ tạo ra một yêu cầu HTTP với hình ảnh gộp chung đó.

Liệt kê 2. Các mục danh sách có một hình ảnh gộp chung
<ul dojoType="dojox.mobile.RoundRectList" iconBase="i-icon-all.png">
  <li dojoType="dojox.mobile.ListItem" iconPos="0,0,29,29" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,29,29,29" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,58,29,29" moveTo="bar">Store</li>
</ul>
Hình 4. Kết quả của Liệt kê 2
Kết quả của của các mục danh sách có một hình ảnh gộp chung

Cũng có thể sử dụng CSS Sprite cho các biểu tượng của thùng chứa biểu tượng (Hình 5) hoặc các nút ấn của thanh tab (Hình 6).

Hình 5. Thùng chứa biểu tượng (IconContainer) với CSS Sprite
Icon container với CSS sprite
Hình 6. Thanh tab (TabBar) với CSS Sprite
Thanh tab với CSS sprite

Nút ấn DOM

Dojo Mobile cung cấp các nút ấn đơn, các biểu tượng, các dấu/các mũi tên kiểm tra cho một mục danh sách và v.v.., như trong Hình 7. Chúng được tạo ra từ các phần tử <div> có áp dụng các phong cách CSS mà không dùng hình ảnh nào và được gọi là các Nút ấn DOM (DOM Button).

Hình 7. Các Nút ấn DOM
Các Nút ấn DOM

Lý tưởng là các Nút ấn DOM nhỏ hơn kích cỡ (tính theo) byte, do chúng được tạo ra từ CSS mà không dùng các hình ảnh nào. Bảng 1 so sánh các kích cỡ byte của các Nút ấn DOM và các hình ảnh khi sử dụng nút DomButtonGreenCircleArrow (nút thứ tư từ trên xuống, cột đầu tiên trong Hình 7) làm một ví dụ. Bạn có thể nhìn thấy một Nút ấn DOM có kích cỡ byte nhỏ hơn nhiều so với kích cỡ byte của một hình ảnh.

Bảng 1. So sánh kích cỡ byte giữa một Nút ấn DOM và một hình ảnh
TệpKích cỡ byte
DomButtonGreenCircleArrow.css (đã rút gọn & nén)392 byte
mblDomButtonGreenCircleArrow.png1.599 byte

Các Nút ấn DOM có thêm lợi thế là không cần phải thực hiện thêm các yêu cầu HTTP, vì chúng có thể được tích hợp vào một tệp CSS chủ đề bằng công cụ xây dựng. Trong tình huống này, dung lượng của một Nút ấn DOM nhỏ hơn nhiều. Bảng 2 cho thấy một kích cỡ byte của Nút ấn DOM trong một tệp CSS gộp chung. Bạn có thể thấy việc thêm tệp DomButtonGreenCircleArrow.css chỉ làm tăng thêm 155 byte mà thôi.

Bảng 2. Kích cỡ byte của Nút ấn DOM trong một tệp CSS gộp chung
TệpKích cỡ byte
base.css (đã rút gọn & nén)2.844 byte
base.css + DomButtonGreenCircleArrow.css (đã rút gọn & nén)2.999 byte
Chênh lệch155 bytes

Cấu trúc của Nút ấn DOM

Nút ấn DOM gồm có các phần tử <div> lồng nhau có áp dụng phong cách CSS. Như đã đề cập, bạn có thể đạt được một loạt các biểu diễn đồ họa nhờ sử dụng các khả năng phong phú của CSS3, ví dụ như các nền đổi mầu, các hộp có góc tròn và phép chuyển đổi của các phần tử DOM. Thậm chí bạn có thể vẽ một vòng tròn bằng cách điều chỉnh bán kính đường viền của một phần tử <div> vuông. Hình 8 cho thấy một ví dụ về cấu trúc của Nút ấn DOM.

Hình 8. Cấu trúc của Nút ấn DOM
Cấu trúc của nút ấn DOM

Cách sử dụng Nút ấn DOM

Nút ấn DOM chỉ đơn giản là một bộ sưu tập các phong cách CSS. Nó không đòi hỏi mã JavaScript. Có thể hiển thị nó chỉ bằng cách đặt các phần tử <div> lồng nhau và áp dụng các phong cách CSS cho chúng. Liệt kê 3 cho thấy mã mẫu tối thiểu và Hình 9 cho thấy kết quả.

Liệt kê 3. Sử dụng Nút ấn DOM không dùng mã JavaScript
<html>
  <head>
    <link href="themes/common/domButtons/DomButtonBlueCircleMinus.css" rel="stylesheet">
  </head>
  <body>
    <div class="mblDomButtonBlueCircleMinus">
      <div><div><div></div></div></div>
    </div>
  </body>
</html>
Hình 9. Kết quả của Liệt kê 3
Kết quả của Liệt kê 3

Trong Liệt kê 3, tôi đã chuẩn bị 4 mức các DIV lồng nhau bao gồm cả nút gốc của Nút ấn DOM, có một tên lớp. Tuy nhiên, số lượng các DIV, mà bạn cần chuẩn bị, sẽ thay đổi theo kiểu Nút ấn DOM. Để tự động tạo ra số lượng các DIV cần thiết, hãy sử dụng hàm dojox.mobile.createDomButton() của Dojo Mobile, như minh họa trong Liệt kê 4.

Liệt kê 4. Sử dụng Nút ấn DOM với mã JavaScript
<div id="btn1" class="mblDomButtonBlueCircleMinus"></div>
----
var node = dojo.byId("btn1");
dojox.mobile.createDomButton(node);

Tuy nhiên, Liệt kê 3 và Liệt kê 4 thường không được sử dụng. Tôi giới thiệu chúng với mục đích minh họa để cho thấy cơ chế của Nút ấn DOM. Thay vào đó, một số các tiện ích Dojo Mobile hỗ trợ các Nút DOM như dưới đây. Bạn có thể quy định các Nút ấn DOM ở vị trí của các biểu tượng hình ảnh hoặc các nút ấn.

  • ListItem: đặc tính icon, rightIcon, rightIcon2, arrowClass và checkClass (Hình 10)
  • TabBarButton: đặc tính icon1 and icon2 (Hình 11)
  • ToolBarButton: đặc tính icon (Hình 12)
  • TabBarButton: đặc tính icon (Hình 13)
Hình 10. ListItem (danh sách)
mục danh sách
Hình 11. TabBarButton (thanh tab)
nút thanh tab
Hình 12. ToolBarButton (tiêu đề)
nút thanh công cụ
Hình 13. TabBarButton (kiểm soát có phân đoạn)
nút thanh tab

Cách tạo một Nút ấn DOM tùy chỉnh

Bạn có thể tạo các Nút ấn DOM tùy chỉnh riêng của mình. Dưới đây là một số mẹo nhỏ.

  • Tên lớp của một Nút ấn DOM PHẢI bắt đầu bằng "mblDomButton". Dojo Mobile kiểm tra tên lớp để xác định xem nó có phải là một Nút ấn DOM hay không. (Mặt khác, bạn có thể chọn một tên tệp CSS và nơi đặt nó).
  • Quy định chiều rộng và chiều cao của Nút ấn DOM cho nút gốc của nó. Chúng sẽ có kích cỡ của toàn bộ Nút ấn DOM.
  • Các phần tử <div> lồng nhau, không có phần tử anh chị em. Vì vậy, bạn có thể cần áp dụng các phong cách CSS cho một nút liên quan đến nút cha mẹ của nó.
  • Để áp dụng các phong cách CSS cho một phần tử <div> cụ thể trong hệ thống phân cấp <div>, bạn có thể sử dụng một bộ chọn con (>).
  • Nếu bạn muốn hỗ trợ các trình duyệt của máy tính để bàn không theo-CSS3, bạn nên tạo ra một hình ảnh tương đương và một tệp compat css (*-compat.css).

Liệt kê 5 và Liệt kê 6 hiển thị một ví dụ về Nút ấn DOM tùy chỉnh. Hình 14 cho thấy kết quả.

Liệt kê 5. Nút ấn DOM tùy chỉnh (DomButtonMyCheck.css)
/* === Red Check Button ==*/
.mblDomButtonMyCheck {
  position: relative;
  width: 29px;
  height: 29px;
}
.mblDomButtonMyCheck > div {
  position: absolute;
  left: 0px;
  top: 8px;
  width: 16px;
  height: 6px;
  font-size: 1px;
  -webkit-transform: scaleX(0.7) rotate(135deg);
  border-width: 3px 4px 0px 0px;
  border-style: solid;
  border-color: red;
}
Liệt kê 6. Nút ấn DOM tùy chỉnh (DomButtonMyCheck-compat.css)
/* === Red Check Button ==*/
.mblDomButtonMyCheck {
	background-image: url(compat/mblDomButtonMyCheck.png);
	background-repeat: no-repeat;
}
.mblDomButtonMyCheck > div {
	display: none;
}
Hình 14. Nút ấn DOM tùy chỉnh
nút DOM tùy chỉnh

Mô đun tương thích

Dojo Mobile được tối ưu hóa cho các trình duyệt di động dựa trên-WebKit, nhưng nó cũng hỗ trợ cho các trình duyệt máy tính để bàn không theo-WebKit. Tuy nhiên, không ai muốn hy sinh hiệu năng trên các thiết bị di động để hỗ trợ cho các trình duyệt máy tính để bàn. Không cần nạp mã hỗ trợ giữa các trình duyệt khi một ứng dụng chạy trên các thiết bị di động.

Biên dịch có điều kiện

Một cách tiếp cận là biên dịch có điều kiện, cho phép bạn loại bỏ một số khối mã không cần thiết cho di động. Dojo cung cấp hai cách biên dịch có điều kiện là các pragma và has().

Các pragma là các chỉ dẫn đặc biệt, có thể được sử dụng để loại trừ/bao gồm một số phần mã như trong Liệt kê 7.

Liệt kê 7. Ví dụ về sử dụng pragma
process: function(){
//>>excludeStart("marker1", kwArgs.noIE);
    if(dojo.isIE){
        ....
    }
//>>excludeEnd("marker1");
    ....
}

Trong ví dụ trên, nếu bạn xây dựng mã với tùy chọn có điều kiện noIE=true được quy định như sau, thì khối mã được bao quanh bởi excludeStartexcludeEnd được lấy ra khỏi quá trình xây dựng.

> build profile=myapp action=release noIE=true

Ngoài ra, nếu bạn sử dụng các pragma includeStart/includeEnd, khối mã bao quanh được đưa vào chỉ khi có các sự trùng khớp có điều kiện.

has() (hoặc dojo/has hoặc has.js) là một cơ chế phát hiện/kiểm tra tính năng, được giới thiệu trong Dojo 1.7. Như trong Liệt kê 8, bạn có thể sử dụng nó để kiểm tra xem có hay không có một tính năng đặc trưng tồn tại trong môi trường thời gian chạy hiện tại.

Liệt kê 8. Ví dụ về kiểm tra "has"
process: function(){
    if(has("ie")){
        ....
    }
    ....
}

Nếu bạn cấu hình mảng staticHasFeatures trong lược tả xây dựng của bạn như dưới đây, has("ie") được thay thế bằng 0 và sau đó trình tối ưu hóa của trình biên dịch phát hiện ra khối mã của nó là mã chết và khối đó được lấy ra khỏi quá trình xây dựng.

staticHasFeatures: {
  'ie': 0
}

Mô đun tương thích

Biên dịch có điều kiện cho phép bạn thực hiện một quá trình xây dựng được tối ưu hóa cho một nền tảng riêng. Tuy nhiên, quá trình xây dựng này có một vấn đề ở chỗ nó không hoạt động trên các nền tảng khác. Để hỗ trợ các nền tảng khác, bạn cần thực hiện các quá trình xây dựng khác. Để giải quyết vấn đề này, Dojo Mobile đưa ra một cách tiếp cận khác: mô đun tương thích (hoặc compat).

Mô đun tương thích (compat) bao gồm một số mã hỗ trợ các trình duyệt không theo-WebKit. Nếu mô đun tương thích được nạp, nó "ghi đè lên" một số các phương thức của tiện ích cần được sửa chữa. Việc ghi đè mã giữ cho các tên lớp của tiện ích ban đầu giống nhau và do đó không ảnh hưởng đến mã ứng dụng của người dùng. Mặt khác, việc ghi đè mã, bằng cách phân lớp con cho các tiện ích ban đầu, sẽ yêu cầu sử dụng các tên lớp của tiện ích mới được định nghĩa. Mô đun tương thích cũng tải các tệp *-compat.css, là các bản vá lỗi cho các tệp css ban đầu. Trong chế độ mô đun tương thích (compat), các kỹ thuật truyền thống được sử dụng để đưa ra các giao diện người dùng (UI) của tiện ích không theo CSS3, chẳng hạn như các hình ảnh động dựa trên JavaScript với dojo.fx, các hình ảnh nền và v.v.. Để sử dụng mô đun tương thích cho ứng dụng của bạn, hãy tải về "dojox.mobile.compat" bằng cách sử dụng dojo.require() hoặc API require (API yêu cầu).

Lưu ý rằng mô đun tương thích được chia thành hai đoạn mã là, compat.js_compat.js. _compat.js gồm tất cả mã thực hiện và compat.js là một bộ tải của _compat.js. compat.js tải _compat.js chỉ khi trình duyệt hiện tại không dựa trên-WebKit. compat.js là một đoạn mã nhỏ không ảnh hưởng đến hiệu năng di động ngay cả khi nó đang trong quá trình xây dựng. Theo cách này, trên các trình duyệt dựa trên-WebKit, hiệu năng không suy giảm do _compat.js vẫn chưa bao giờ được nạp. Trên các trình duyệt không theo-WebKit, _compat.js được nạp tự động và Dojo Mobile hoạt động trong chế độ mô đun tương thích (compat). Bảng 3 cho thấy sự so sánh kích cỡ byte giữa một quá trình xây dựng di động không có mô đun tương thích và một quá trình xây dựng di động có mô đun tương thích. Như bạn có thể thấy, hiệu số nhỏ không đáng kể: 45 byte.

Bảng 3. So sánh kích cỡ byte di động (lược tả: mobile-all.profile.js, đã rút gọn & nén)
Mô tảKích cỡ byte
Quá trình xây dựng di động không có mô đun tương thích36.594 byte
Quá trình xây dựng di động có mô đun tương thích36.639 byte
Hiệu số45 byte

Các lời khuyên về đánh giá hiệu năng

Như mô tả ở trên, trên các trình duyệt không theo-WebKit, Dojo Mobile chạy ở chế độ mô đun tương thích và tài nguyên bổ sung, chẳng hạn như các hình ảnh và/hoặc tệp * compat.css, được nạp. Vì vậy, nếu bạn muốn đánh giá các tệp nào và có bao nhiêu tệp được tải trong một thiết bị di động, bạn không nên sử dụng các trình duyệt không theo-WebKit như Firefox hay Internet Explorer. Các trình gỡ lỗi trên Google Chrome hay phiên bản máy tính để bàn của Safari là những công cụ tốt hơn để theo dõi lưu lượng truy cập mạng cho mục đích đó, do chúng dựa trên-WebKit.


Các phụ thuộc của mô đun

Dojo cung cấp rất nhiều các API có ích và chúng được đóng gói theo các mô đun, là các tệp JavaScript tương đối nhỏ. Có sẵn vô số các mô đun có ích. Tuy nhiên, việc lạm dụng chúng có thể dẫn đến một vùng lưu trữ rất lớn. Dojo Mobile được thiết kế cẩn thận để có càng ít các phụ thuộc mô đun càng tốt. Ví dụ, nó không cố ý sử dụng một số mô đun thường dùng, các mô đun có ích như dojo.query hoặc dijit._Templated. Ngoài ra, tất cả các tiện ích của Dojo Mobile kế thừa từ dijit._WidgetBase chứ không phải từ dijit._Widget. dijit._WidgetBase là một lớp cơ sở của dijit._Widget và không gồm một số mã không cần thiết cho di động, chẳng hạn như mã hỗ trợ bàn phím và nên nó nhẹ hơn dijit._Widget. Hơn nữa, nó không sử dụng dijit._base.manager, là một mô đun cần thiết cho đến Dojo 1.6; thay vào đó, nó sử dụng dijit.registry, là một tập con của dijit._base.manager.

Việc sử dụng các mô đun dojo như dojo.query hoặc dijit._Templated từ các ứng dụng người dùng dựa trên Dojo Mobile, tất nhiên, là sự lựa chọn của bạn. Tuy nhiên, bạn nên cẩn thận lựa chọn sử dụng các mô đun dojo/dijit nào dựa trên hiệu năng. Ví dụ, nếu bạn sử dụng dojo.query chỉ một lần trong ứng dụng của mình, bạn có thể thay thế nó bằng mã nhỏ hơn rất nhiều so với toàn bộ mã thực hiện của dojo.query.

Liệt kê 9 cho thấy các mô đun mà cơ sở Dojo Mobile phụ thuộc trực tiếp hoặc gián tiếp vào chúng. Bạn có thể nhận thấy nó có ít các phụ thuộc hơn trên các mô đun dojo/dijit so với các trường hợp sử dụng của máy tính để bàn điển hình. Nó chỉ phụ thuộc vào 11 mô đun dojo/_base trong số 25 mô đun và không có phụ thuộc nào vào các mô đun dijit /_base. Nếu bạn sử dụng các mô đun bổ sung không được hiển thị trong Liệt kê 9, việc đó sẽ làm tăng thêm vùng lưu trữ của ứng dụng của bạn. Khi bạn sử dụng các mô đun như vậy, bạn nên chọn chúng một cách cẩn thận.

Liệt kê 9. Các mô đun phụ thuộc
dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic

Xây dựng

Để tối ưu hóa hiệu năng thời gian tải, xây dựng là một quá trình quan trọng. Dojo có một hệ thống xây dựng mạnh mẽ, trong đó nén tất cả các mã JavaScript và CSS vào số tệp ít hơn và tạo ra một phiên bản hiệu quả của ứng dụng của bạn để phát hành. Hình 15 và Hình 16 cho thấy sự so sánh các tệp được chuyển giao giữa một ứng dụng (mã nguồn) chưa xây dựng và ứng dụng đã xây dựng. Bạn có thể thấy có một sự khác biệt rất lớn giữa số lượng các yêu cầu và tổng kích cỡ được chuyển giao. Phần tiếp theo thảo luận xây dựng Dojo Mobile.

Hình 15. Số lượng các yêu cầu và kích cỡ tải về (chưa xây dựng)
Số lượng các yêu cầu và kích cỡ tải về (chưa xây dựng)
Hình 16. Số lượng các yêu cầu và kích cỡ tải về (đã xây dựng)
Số lượng các yêu cầu và kích cỡ tải về (đã xây dựng)

Xây dựng customBase

Xây dựng Dojo có một tùy chọn tên là customBase. Xây dựng Dojo tiêu chuẩn bao gồm hầu hết các mô đun cơ sở Dojo trong một quá trình xây dựng, do các mô đun cơ sở Dojo luôn có sẵn mà không cần yêu cầu rõ chúng. Tuy nhiên, nếu bạn thực hiện một quá trình xây dựng với tùy chọn customBase đã kích hoạt, chỉ các mô đun trong chuỗi phụ thuộc thực tế mới được đưa vào trong quá trình xây dựng đó. Dojo Mobile được thiết kế để có càng ít phụ thuộc của mô đun cơ sở Dojo càng tốt. Vì vậy, để được lợi từ thiết kế này, việc sử dụng tùy chọn customBase rất quan trọng. Liệt kê 10 cho thấy cách chỉ rõ tùy chọn customBase trong lược tả xây dựng của bạn.

Liệt kê 10. Tùy chọn customBase trong một tệp lược tả
dependencies = {
  stripConsole: "normal",

  layers: [
    {
      name: "dojo.js",
      customBase:
                    true,
      dependencies: [
        "dojox.mobile.parser",
        "dojox.mobile",
        "dojox.mobile.compat"
      ]
    },
  ....

Trình biên dịch đóng kín

Có hai trình biên dịch (hoặc trình nén), có thể được sử dụng để tạo thành công cụ xây dựng Dojo là Shrinksafe và Google Closure Compiler (Trình biên dịch đóng kín Google). Shrinksafe là trình biên dịch mặc định của Dojo. Hàm đóng kín (Closure) đã được đóng gói với Dojo kể từ phiên bản 1.7. Bảng 4 cho thấy sự so sánh kích cỡ xây dựng di động giữa Shrinksafe và Hàm đóng kín. Như bạn có thể thấy, tỷ lệ nén của hàm đóng kín tốt hơn so với tỷ lệ nén của Shrinksafe và kích cỡ của quá trình xây dựng Hàm đóng kín là thấp hơn 20% so với quá trình xây dựng Shrinksafe, ít nhất là trong ví dụ này.

Bảng 4. So sánh kích cỡ xây dựng di động giữa Shrinksafe và Hàm đóng kín
Mô tảKích cỡ byte
Xây dựng di động (Shrinksafe, đã nén)44.826 byte
Xây dựng di động (Closure, đã nén)36.639 byte

Dojo Mobile đã được kiểm tra dựa vào những gì đã được xây dựng với Hàm đóng kín. Hàm đóng kín được khuyến nghị sử dụng với quá trình xây dựng di động, do đầu ra của nó nhỏ hơn.

Cách xây dựng Dojo Mobile

Dojo Mobile cung cấp hai tệp lược tả mẫu: mobile-all.profile.js và mobile.profile.js, trong thư mục dojo/util/buildscripts/profiles. Để dễ dàng xây dựng với các lược tả này, hãy sử dụng các tệp bó (batch) đơn giản có sẵn trong thư mục dojox/mobile/build.

Từ dòng lệnh, bạn có thể chạy tệp bó. Sử dụng build.bat cho Windows hoặc build.sh cho Linux.

Liệt kê 11. Cách sử dụng tệp bó build
  > build
  Usage: build separate|single [webkit]
    separate  Create mobile.js that includes only dojox.mobile
    single    Create a single dojo.js layer that includes dojox.mobile
    webkit    Enable webkitMobile=true option (Loses PC browser support)

separate (chia tách) sử dụng tệp mobile.profile.js và tạo ra tệp mobile.js CHỈ gồm các mô đun cơ sở dojox.mobile. Nó không có các mô đun cơ sở dojo hay cơ sở dijit. Tệp _compat.js cũng được tạo ra để hỗ trợ cho trình duyệt máy tính để bàn. Ngoài ra, tệp dojo.js được tạo ra, nhưng đó là một quá trình xây dựng cơ sở dojo bình thường, không phải là một quá trình xây dựng customBase.

Lưu ý rằng "cơ sở dojox.mobile" không gồm tất cả các tiện ích Dojo Mobile. Ví dụ, ScrollableView, Carousel, SpinWheel, các điều khiển dạng mẫu, v.v.. không có trong cơ sở đó. Nếu muốn có chúng trong quá trình xây dựng của mình, bạn có thể chỉ cần thêm chúng vào mảng các phụ thuộc trong một tệp lược tả. Liệt kê 12 cho thấy tất cả các mô đun được gói vào quá trình xây dựng cơ sở dojox.mobile, là mobile.js.

Liệt kê 12. Các mô đun trong mobile.js
dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

single (đơn) sử dụng tệp mobile-all.profile.js và tạo ra một tầng dojo.js đơn có chứa cơ sở dojox.mobile và tất cả các mô đun dojo/dijit phụ thuộc. Tệp _compat.js cũng được tạo ra để hỗ trợ cho trình duyệt máy tính để bàn. Quá trình xây dựng này cho phép tùy chọn customBase. Vì vậy, chỉ có các mô đun cơ sở dojo/dijit tối thiểu có trong dojo.js kết quả. Liệt kê 13 cho thấy tất cả các mô đun được gói vào quá trình xây dựng đơn này.

Liệt kê 13. Các mô đun trong dojo.js
dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic
dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/parser
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

webkit cho phép tùy chọn xây dựng webkitMobile=true, lấy ra các đoạn mã không cần thiết cho các trình duyệt di động dựa trên-Webkit. Ví dụ, loại bỏ mã riêng của Internet Explorer hay mã riêng của Firefox ra khỏi quá trình xây dựng này. Điều này làm giảm tổng dung lượng mã, nhưng mô đun đã xây dựng này sẽ không tiếp tục làm việc trên các trình duyệt của máy tính để bàn ngay cả với mô đun tương thích (compat.js).

Cũng lưu ý rằng tùy chọn này đã làm giảm một lượng mã đáng kể trong Dojo 1.6, nhưng trong Dojo 1.7, việc phát hiện/kiểm tra tính năng được chuyển cho dojo.has và nên tùy chọn webkitMobile không còn có nhiều tác dụng về giảm dung lượng mã nữa.


Gộp chung CSS

Dojo Mobile có một gói các tệp CSS trong thư mục themes (các chủ đề). Có một tệp CSS cho mỗi tiện ích và chúng có sẵn cho mỗi chủ đề, Android, Blackberry, Custom và iPhone. Ngoài ra, có các tệp CSS cho các Nút ấn DOM hoặc các hình ảnh động chuyển tiếp. Để giúp bạn dễ dàng đưa các tệp CSS cần thiết vào ứng dụng của mình, một số tệp CSS của điểm mục nhập sẽ gộp chung một số tệp CSS liên quan:

  • Tệp chủ đề tất cả-trong-một (ví dụ: themes/iphone/iphone.css)
    Gồm tất cả các tệp CSS phổ biến và các tệp CSS chủ đề.
  • Tệp chủ đề cơ sở (ví dụ: themes/iphone/base.css)
    Gồm các tệp CSS chủ đề cho các mô đun cơ sở dojox.mobile.
  • Các Nút ấn DOM (themes/common/domButtons.css)
    Gồm tất cả các Nút ấn DOM.
  • Các chuyển tiếp (themes/common/transitions.css)
    Gồm tất cả các hình ảnh động chuyển tiếp.

Việc sử dụng tệp chủ đề tất cả-trong-một là dễ nhất, vì nó bao gồm mọi thứ. Tuy nhiên, điều đó có nghĩa là có thể gồm cả các tệp CSS không sử dụng và điều đó có thể làm tăng dung lượng không cần thiết. Trong trường hợp đó, một cách tiếp cận là sử dụng tệp chủ đề cơ sở và các tệp CSS riêng lẻ không có trong tệp chủ đề cơ sở.

Các tệp CSS của điểm mục nhập nói trên là một bộ sưu tập chỉ dẫn @import (nhập khẩu@). Nếu bạn thực hiện quá trình xây dựng Dojo, các câu lệnh @import đều được nội tuyến và do đó các tệp CSS đã tham chiếu được kết hợp với nhau trong tệp CSS của điểm mục nhập. Vì vậy, việc sử dụng một tệp CSS điểm mục nhập chỉ đưa ra một yêu cầu HTTP, nếu nó được xây dựng. Tuy nhiên, nếu bạn đã liệt kê các tệp CSS trong ứng dụng của mình bằng cách sử dụng <link> hoặc @import như trong Liệt kê 14, các yêu cầu HTTP sẽ được tạo ra cho từng tệp CSS.

Liệt kê 14. Các thẻ link trong html (userApp.html)
<head>
  <link href="../themes/iphone/base.css" rel="stylesheet">
  <link href="../themes/iphone/TabBar.css" rel="stylesheet">
  <link href="../themes/common/SpinWheel.css" rel="stylesheet">
  <link href="../themes/common/domButtons/DomButtonBlueCircleArrow.css" rel="stylesheet">
  ....

Để giảm số lượng các yêu cầu, hãy tạo tệp CSS của điểm mục nhập riêng của bạn, có các tài liệu tham chiếu đến các tệp CSS cần thiết tối thiểu bằng cách sử dụng chỉ dẫn @import như trong Liệt kê 15. Nếu bạn thực hiện một quá trình xây dựng Dojo, nó sẽ là một tệp CSS nội tuyến không cần tài liệu tham khảo bên ngoài. Bạn có thể sử dụng nó từ ứng dụng của mình như trong Liệt kê 16.

Liệt kê 15. Một tệp CSS để gộp chung (myStyles.css)
@import url("../themes/iphone/base.css");
@import url("../themes/iphone/TabBar.css");
@import url("../themes/common/SpinWheel.css");
@import url("../themes/common/domButtons/DomButtonBlueCircleArrow.css");
Liệt kê 16. Một thẻ link duy nhất trong html (userApp.html)
<link href="myStyles.css" rel="stylesheet">

Như mô tả ở trên, bạn có thể làm giảm số lượng các yêu cầu HTTP cho các tệp CSS bằng cách tạo ra tệp CSS của điểm mục nhập của bạn và thực hiện quá trình xây dựng Dojo.


Tạo động và tải rất chậm

Tải rất chậm — một kỹ thuật để tải các mô đun chỉ khi chúng được tham chiếu lần đầu tiên — cải thiện hiệu năng khởi động của ứng dụng. Chính Dojo Mobile sử dụng kỹ thuật tải rất chậm này ở bên trong.

Tạo một khung nhìn động

Với đặc tính url của _ItemBase, bạn có thể tạo động một khung nhìn mới ngay lập tức trước khi thực hiện một quá trình chuyển tiếp khung nhìn. Liệt kê 17 cho thấy một ví dụ sử dụng đặc tính url. Nội dung của khung nhìn có thể hoặc là một đoạn HTML (Liệt kê 18) hoặc là dữ liệu JSON (Liệt kê 19).

Liệt kê 17. Ví dụ về đặc tính url
<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" url="view1.html">
    External View #1 (sync)
  </li>
  <li dojoType="dojox.mobile.ListItem" url="view2.json" sync="false">
    External View #2 (async)
  </li>
</ul>
Liệt kê 18. Một đoạn mã HTML cho một khung nhìn động (view1.html)
<div dojoType="dojox.mobile.View">
  <h1 dojoType="dojox.mobile.Heading" back="Home" moveTo="foo">view1.html</h1>
  <ul dojoType="dojox.mobile.EdgeToEdgeList">
    <li dojoType="dojox.mobile.ListItem">
      Jack Coleman
    </li>
    <li dojoType="dojox.mobile.ListItem">
      James Evans
    </li>
    <li dojoType="dojox.mobile.ListItem">
      Jason Griffin
    </li>
  </ul>
</div>
Liệt kê 19. Dữ liệu JSON cho một khung nhìn động (view2.json)
{
  "dojox.mobile.View": {
    "dojox.mobile.Heading": {
      "@back": "Home",
      "@moveTo": "foo",
      "@label": "view1.json"
    },
    "dojox.mobile.EdgeToEdgeList": {
      "dojox.mobile.ListItem": [{
        "@label": "Jack Coleman"
      }, {
        "@label": "James Evans"
      }, {
        "@label": "Jason Griffin"
      }]
    }
  }
}

Một lựa chọn khác là tìm nạp nội dung khung nhìn theo lập trình và chèn nó vào khung nhìn đích. Liệt kê 20 cho thấy một ví dụ.

Liệt kê 20. Ví dụ về tải nội dung vào một khung nhìn hiện có và thực hiện một quá trình chuyển tiếp
<li dojoType="dojox.mobile.ListItem" moveTo="#" onclick="myAction2(this)">
  Load and Move (async)
</li>
----
function myAction2(li){
   var view2 = dijit.byId("view2"); // destination view
   var listItem = dijit.byNode(li);
   var prog = dojox.mobile.ProgressIndicator.getInstance();
   dojo.body().appendChild(prog.domNode);
   prog.start();
   view2.destroyDescendants();

   var url = "http://..."; // or var url = listItem.url;
   dojo.xhrGet({
       url: url,
       handleAs: "text",
       load: function(response, ioArgs){
           var container = view2.containerNode;
           container.innerHTML = response;
           dojo.parser.parse(container);
           prog.stop();
           listItem.transitionTo("view2");
       }
   });
}

Xem dojox/mobile/tests/test_list-actions.html để biết các chi tiết và nhiều ví dụ hơn nữa.

Tải-rất chậm bằng IconContainer

IconContainer (Thùng chứa biểu tượng) có thể có nhiều biểu tượng, mỗi biểu tượng đại diện cho một ứng dụng con. Các ứng dụng con có thể có một hoặc nhiều tiện ích Dojo. Việc tải tất cả các mã ứng dụng con lúc khởi động có thể làm chậm thời gian khởi động của ứng dụng chính. Để cải thiện hiệu năng thời gian khởi động, bạn có thể chỉ rõ tham số lazy="true" trên các IconItem (các mục biểu tượng). Sau đó trình phân tích cú pháp bỏ qua việc tạo các tiện ích bên trong IconItemIconContainer tải động các mô đun nội dung biểu tượng đó và chỉ tạo chúng khi lần đầu tiên mở một biểu tượng.

Liệt kê 21 là một ví dụ về việc tải rất chậm các nội dung biểu tượng. Lưu ý rằng bạn không phải yêu cầu rõ các mô đun nội dung biểu tượng (dijit.CalendarLite trong ví dụ sau). Cũng lưu ý rằng, trong Dojo 1.7, việc tải rất chậm chỉ được hỗ trợ trong chế độ bộ tải (loader) đồng bộ, do việc tải rất chậm được thực hiện đồng bộ khi sử dụng dojo.require.

Liệt kê 21. Ví dụ về tải rất chậm của IconContainer
<ul dojoType="dojox.mobile.IconContainer">
  <li dojoType="dojox.mobile.IconItem" label="Calendar" lazy="true">
    <div id="cal" dojoType="dijit.CalendarLite"></div>
  </li>
  ....
Hình 17. IconContainer
icon container

Tải rất chậm với TabBar

Nếu cần các ô cửa sổ tab có thể nạp rất chậm, bạn có thể sử dụng tiện ích TabBar và các kỹ thuật tương tự như được mô tả trong "Tạo một khung nhìn động." Đối với các ô cửa sổ tab, bạn cũng cần một thủ thuật nhỏ cho ô cửa sổ tab đầu tiên, vì không có quá trình chuyển tiếp khung nhìn nào lúc khởi động. Bạn cần tạo một quá trình chuyển tiếp khung nhìn theo lập trình từ một khung nhìn rỗng giả đến ô cửa sổ tab đầu tiên lúc khởi động để tải các nội dung bên ngoài vào ô cửa sổ tab đầu tiên. Liệt kê 22 và Liệt kê 23 cho thấy các ví dụ tương tự; Liệt kê 22 là một ví dụ đồng bộ, Liệt kê 23 là một ví dụ không đồng bộ.

Liệt kê 22. Ví dụ về các ô cửa sổ tab rất chậm (chế độ đồng bộ)
  <script src="../../../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
    dojo.require("dojox.mobile");
    dojo.require("dojox.mobile.parser");
    dojo.require("dojox.mobile.compat");
    dojo.require("dojox.mobile.TabBar");
    dojo.ready(function(){
      setTimeout(function(){
        dijit.byId("tab1").onClick();
      }, 0);
    });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton" url="view1.html">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton" url="view2.html">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton" url="view3.html">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>
Liệt kê 23. Ví dụ về các ô cửa sổ tab rất chậm (chế độ không đồng bộ)
  <script src="../../../dojo/dojo.js" djConfig="async: true, parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
  require([
    "dojo/_base/kernel",
    "dijit/registry",
    "dojox/mobile",
    "dojox/mobile/compat",
    "dojox/mobile/parser",
    "dojox/mobile/TabBar"
  ], function(dojo, registry){
    dojo.ready(function(){
      setTimeout(function(){
        registry.byId("tab1").onClick();
      }, 0);
    });
  });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton"
        url="view1.html" sync="false">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton"
        url="view2.html" sync="false">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton"
        url="view3.html" sync="false">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>

Yêu cầu các mô đun động

Việc yêu cầu các mô đun động trong thời gian chạy là một ý tưởng tốt, vì nó có thể cải thiện hiệu năng thời gian khởi động. Nhưng có một vấn đề tiềm ẩn mà bạn cần phải biết rõ. Hãy xem trong Liệt kê 24; Liệt kê này hiển thị việc tải một mô đun Dojo theo lập trình. Nó vẫn hoạt động, nhưng nếu bạn xây dựng Liệt kê 24, thì công cụ xây dựng tự động sẽ chọn mô đun cần thiết và gói nó vào một quá trình xây dựng và do đó dojo.require không làm gì trong thời gian chạy kể từ khi đã tải mô đun đó lúc khởi động.

Liệt kê 24. Tải một mô đun Dojo theo lập trình (ví dụ SAI)
myHandler: function(e){
  dojo.require("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

Để tránh vấn đề đó, bạn có thể viết dojo["require"] thay vì dojo.require như trong Liệt kê 25.

Liệt kê 25. Tải một mô đun Dojo theo lập trình (ví dụ ĐÚNG)
myHandler: function(e){
  dojo["require"]("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

Nếu ứng dụng của bạn đang sử dụng bộ tải không đồng bộ, cú pháp sẽ khác như được hiển thị trong Liệt kê 26. Nhưng đây không phải là một ví dụ tốt, do công cụ xây dựng bất ngờ chọn mô đun đã quy định nếu bạn viết mã theo cách này.

Liệt kê 26. Tải một mô đun Dojo theo lập trình (ví dụ SAI)
myHandler: function(e){
  require(["dijit/CalendarLite"], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

Bạn có thể tránh các vấn đề xây dựng bằng cách gán tên lớp cho một biến như trong Liệt kê 27.

Liệt kê 27. Tải một mô đun Dojo theo lập trình (ví dụ ĐÚNG)
myHandler: function(e){
  var cls = "dijit/CalendarLite"; // assign to a variable so as not to be in the build
  require([cls], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

Chế độ không đồng bộ

Trong Dojo 1.7, một bộ tải AMD (Asynchronous Module Definition - Định nghĩa mô đun không đồng bộ) được cung cấp ngoài bộ tải truyền thống Dojo. Các tiện ích Dojo Mobile được viết bằng cú pháp AMD mới. Để tải bất kỳ các mô đun Dojo nào, bạn có thể sử dụng hoặc dojo.require truyền thống (Liệt kê 28) hoặc API require mới (Liệt kê 29).

Liệt kê 28. Ví dụ về dojo.require (truyền thống)
<script src="../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
<script language="JavaScript" type="text/javascript">
  dojo.require("dojox.mobile");
  dojo.require("dojox.mobile.parser");
  dojo.require("dojox.mobile.compat");
</script>
Liệt kê 29. Ví dụ về require (cú pháp AMD)
<script src="../dojo/dojo.js" djConfig="async:true, parseOnLoad:true"></script>
<script language="JavaScript" type="text/javascript">
  require([
    "dojox/mobile",
    "dojox/mobile/parser",
    "dojox/mobile/compat"
  ]);
</script>

Liệt kê 28 tải đồng bộ các mô đun, trong khi Liệt kê 29 tải nó không đồng bộ. Trong các trường hợp ở đó tải rất nhiều các tệp JavaScript, hy vọng rằng việc tải không đồng bộ sẽ thực hiện tốt hơn so với tải đồng bộ. Tuy nhiên, nếu các tệp JavaScript được kết hợp lại với nhau thành một tệp xây dựng đơn lẻ, thì có thể không có nhiều sự khác biệt giữa tải đồng bộ và tải không đồng bộ.

Tuy nhiên, có một sự khác biệt lớn hơn mà bạn cần biết rõ. Hình 18 cho thấy các tệp được chuyển giao khi mở tệp test_iPhone Animation.html để tải các mô đun theo cách của Liệt kê 28 và Hình 19 cho thấy các tệp được chuyển giao khi mở tệp test_iPhone-Animation-async.html để tải mô đun theo cách của Liệt kê 29. Như hiển thị trong Bảng 5, ở chế độ đồng bộ, có nhiều hơn 17 tệp, với tổng dung lượng là 26KB, được tải thêm. Điều này là do chế độ đồng bộ làm việc trong chế độ tương thích ngược và do đó phải tải một số mô đun cần thiết để duy trì khả năng tương thích ngược. Dựa vào vào test_iPhone-Animation-async.html hoạt động mà không có các mô đun bổ sung đó, rõ ràng là chúng không được sử dụng và vẫn chưa được tải. Vì vậy, ngay cả khi bạn lựa chọn cẩn thận các mô đun cần sử dụng và tối ưu hóa quá trình xây dựng của mình bằng cách sử dụng tùy chọn customBase, việc sử dụng dojo.require() có thể làm hỏng nỗ lực của bạn. Bạn nên sử dụng API require chứ không phải là dojo.require() để tối ưu hóa hiệu năng ứng dụng của mình.

Hình 18. Tải đồng bộ (test_iPhone-Animation.html)
Synchronous loading
Hình 19. Tải không đồng bộ (test_iPhone-Animation-async.html)
Asynchronous loading
Bảng 5. So sánh giữa tải về tài nguyên giữa chế độ đồng bộ và chế độ không đồng bộ
TệpSố lượng các yêu cầuTổng kích cỡ
test_iPhone-Animation.html2369,15 KB
test_iPhone-Animation-async.html643,54 KB

Ngẫu nhiên là, ngay cả khi bạn sử dụng cú pháp AMD như Liệt kê 29, nếu bạn không chỉ rõ async:true (giá trị mặc định là false), ứng dụng của bạn sẽ chạy trong chế độ tương thích và các mô đun bổ sung sẽ được nạp.


dojox.mobile.parser

dojox.mobile.parser là một tập con nhỏ của dojo.parser. Nó đã được phát triển chỉ để làm giảm kích cỡ mã. Nó không có các tính năng bổ sung đặc trưng di động nào so với dojo.parser, vì vậy không có lý do nào buộc bạn phải sử dụng dojox.mobile.parser để thay cho dojo.parser, bạn có thể chọn một cái bạn thích. Một số tính năng nâng cao của dojo.parser, chẳng hạn như <script type="dojo/method"> và <script type="dojo/connect">, không có trong dojox.mobile.parser. Nhưng dojox.mobile.parser có dung lượng nhỏ hơn.

Như hiển thị trong Bảng 6, dung lượng của dojox.mobile.parser khoảng 0,7KB (đã rút gọn và đã nén), trong khi dojo.parser (cộng với các mô đun phụ thuộc của nó mà cơ sở dojox.mobile không yêu cầu) là 6,5KB. Nếu dung lượng của dojox.mobile.parser là đủ cho ứng dụng của bạn, thì việc sử dụng nó có thể làm giảm dung lượng mã của ứng dụng của bạn.

Bảng 6. So sánh dung lượng giữa dojox.mobile.parser và dojo.parser
Mô tả Kích cỡ byte
dojox.mobile.parser734 bytes
dojo.parser + các mô đun phụ thuộc6.507 byte

Tóm tắt

Bài này đã cho thấy cách xây dựng các ứng dụng web di động nhẹ bằng cách sử dụng Dojo Mobile và cách áp dụng các kỹ thuật tối ưu hóa hiệu năng của nó cho các ứng dụng của bạn.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

  • Tải về Dojo 1.7 mới nhất từ trang tải Dojo Toolkit.
  • Tải về và dùng thử Xem trước Công nghệ di động của IBM, một tập các mẫu mã và các dịch vụ để giúp bạn bắt đầu xây dựng các ứng dụng di động để mở rộng và tích hợp vào doanh nghiệp. Bài xem trước này gồm có một dịch vụ thông báo RESTful; PhoneGap, một khung công tác nguồn mở để xây dựng các ứng dụng di động lai; một thời gian chạy của WebSphere Application Server nhẹ; và mã mẫu để cho bạn xem tất cả hoạt động thế nào.
  • Gói tính năng WebSphere Application Server cho Web 2.0 và Di động của IBM gồm có Bộ công cụ Dojo 1.7 của IBM, các khối xây dựng ứng dụng Internet phong phú (RIA) và di động mới và một thành phần biểu đồ dựa trên Dojo. Với các công cụ Rational kèm theo, Gói tính năng này giúp bạn nhận được các ứng dụng WebSphere ban đầu được phát triển cho các trình duyệt máy tính để bàn và thích ứng và triển khai chúng cho các thiết bị di động.
  • Đánh giá các sản phẩm của IBM theo cách phù hợp với bạn nhất: Tải về nó để dùng thử, dùng thử nó trực tuyến, sử dụng nó trong một môi trường đám mây hoặc dành một vài giờ trong SOA Sandbox để tìm hiểu cách thực hiện kiến trúc hướng dịch vụ có hiệu quả.

Thảo luận

  • Hãy tham gia vào cộng đồng developerWorks. Kết nối với những người dùng developerWorks khác trong khi khám phá các blog, các diễn đàn, các nhóm và các wiki dựa vào nhà phát triển.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Nguồn mở
ArticleID=846574
ArticleTitle=Phát triển các ứng dụng web di động nhẹ với Dojo Mobile
publish-date=12132011