Tăng hiệu suất thực thi cho các ứng dụng trên J2ME

Có 2 vấn đề quan trọng khi phát triển ứng dụng trên J2ME, đó là:

• Hiệu suất(tốc độ thực thi)
• Kích thước

1.Hiệu suất

Quy tắc quan trọng về cải thiệt hiệu suất là “làm cho nó thật đơn giãn (keep it simple)”, đừng cố gắng làm cho hệ thống trở nên phức tạp, trên chiếc điện thoại, ta phải nhớ rằng mọi người muốn ứng dụng chạy nhanh và dễ dàng sử dụng.

1.1.Thread

• Trong một ứng dụng không nên tạo ra quá nhiều thread bởi sẽ có rất nhiều thiết bị không xử lý được nhiều thread và chúng sẽ bị treo. Kết nối mạng là trường hợp ngoại lệ để tạo ra một Thread mới.
• Giảm thiểu việc sử dụng  đồng bộ, có cơ chế quản lý các đoạn code đồng bộ một cách hợp lý, tránh rơi vào tình trạng Deadlock. Đồng bộ trên phương thức paint() và keyPressed() có thể chấp nhận được.
• Tránh sử dụng lớp Timer bởi nó cũng là một thread mở rộng.
• Tạo một Thread bacckground trong phương thức startApp() và tái sử dụng nó.
• Không sử dụng phương thức Display.callSerially(), bởi nó rất chậm và gây ra nhiều lỗi trên các thiết bị.
• Tránh gọi phương thức serviceRepaints() trên các thiết bị legacy khi hiệu suất là một vấn đề lớn đối với chúng.
• Cần đảm bảo thread-safe(background thread và system thread) nếu phương thức serviceRepaints() không được gọi.

Tối ưu code J2ME

Do điện thoại di động có một số hạn chế: bộ nhớ heap thấp, kích thước file jar có giới hạn, tốc độ xử lý CPU chậm nên việc tối ưu code nhằm tăng tốc quá trình thực thi cho ứng dụng là rất quan trọng.

Sau đây là một số kỹ thuật nhằm tối ưu mã nguồn nhằm giảm kích thước file jar và bộ nhớ sử dụng:

• Sử dụng các chương trình obfuscator như: Proguard hay Retroguard. Chúng có thể xóa các đoạn code không sử dụng và đặt lại tên các biến, phương thức, lớp một cách ngắn nhất nhằm giảm kích thước file jar.
• Hạn chế tạo ra các lớp không cần thiết.
• Tránh tạo ra các đối tượng không cần thiết.
• Sử dụng lại các đối tượng nếu có thể.
• Để tiết kiệm bộ nhớ, nên gán các đối tượng không còn sử dụng bằng null.
• Khi gọi System.gc để gọi Garbage Collection để giải phóng bộ nhớ có thể làm chậm tốc độ thực thi ứng dụng bở nó là một block statement.
• Sử dụng tối thiểu số lượng image để tiết kiệm không gian bộ nhớ.
• Tránh việc tạo ra quá nhiều Thread và phải sử dụng lại các đối tượng Thread một cách có hiệu quả.

1.Tránh xa việc tạo ra các đối tượng không cần thiết

Để tránh tạo ra các đối tượng không cần thiết, ta cần định nghĩa các lớp theo cách có thể sử dụng lại các đối tượng của chúng. Tránh tạo ra các loại đối tượng không cho phép sửa đổi nội dung(như String), ép buộc tạo ra các thể hiện đối của đối tượng mới để xử lý các giá trị mới. Mục đích nhằm giảm thiểu cấp phát bộ nhớ bằng cách tái sử dụng các đối tượng đã tạo ra.

Wireless Messaging API 2.0(JSR 205)

I.Giới thiệu

Wireless Messaging API 2.0 là một gói tùy chọn của J2ME. Nó được sử dụng để truy cập vào tài nguyên giao tiếp không dây như SMS(Short Message Service), CBS(Cell Broadcast Service) và MMS(Multimedia Messaging Service). Chức năng chính của nó là gửi MMS bao gồm: audio, text, image và video. Messaging API dựa trên GCF(Generic Collection Framework) được định nghĩa trong đặc tả CLDC.

Ban đầu, WMA được giới thiệu trong J2ME, đó là WMA 1.1 thuộc JSR 120. Sự khác nhau giữa bản 1.1 và 2.0 là hỗ trợ thêm Multi-part message sử dụng cho MMS.

II.Các gói hỗ trợ

javax.microedition.io: gói này bao gồm các interface network đã được sửa đổi để sử dụng platform có hỗ trợ kết nối message.

javax.wireless.messaging: gói này định nghĩa các API cho phép các ứng dụng gửi và nhận message. Gói này bao gồm các interface và class sau:

BinaryMessage: giao diện sử dụng cho message nhị phân.

Message: đây là giao diện cơ bản để các giao diện các kế thừa.

MessageConnection: giao diện sử dụng để gửi và nhận tin nhắn.

MessageListener: giao diện này sử dụng để thông báo khi có các message đến.

MultipartMessage: giao diện này sử dụng cho các message multipart.

TextMessage: giao diện sử dụng cho message text.

MessagePart: lớp này được sử dụng để thêm vào instance của MessagePart vào MultipartMessage.

1.Giao diện Message

Là kiểu cơ bản cho tất cả các message giao tiếp sử dụng WMA 2.0 – một Message chứa: địa chỉ nguồn, địa chỉ đích và payload.

Một số phương thức dùng để nhận và thiết lập địa chỉ nguồn và địa chỉ đích của message, và nhận timestamp của nó.

• String getAddress();
• void setAddress(String address);
• Date getTimestamp();

WMA 2.0 định nghĩa 3 giao diện con của Message:

2.BinaryMessage

Giao diện con BinaryMessage đại diện cho một message với một payload binary, và có thể được gửi như là một SMS. Giao diện này khai báo các phương thức để nhận và thiết lập payload nhịn phân như là một mảng byte.

• byte[] getPayloadData();
• void setPayloadData(byte[] bytes);

Location API(JSR 179) trên J2ME – Phần 2

IV.Mốc ranh giới(Landmark)

Landmark là một vị trí vật lý với tên đại diện cho vị trí tới người dùng cuối. Location API cho phép người dùng tạo ra, thêm, lưu trữ, lấy ra hay xóa các Landmark. Hai lớp Landmark và LandmarkStore cung cấp các chức năng kể trên. Lớp Landmark đại diện cho thông tin của mốc ranh giới, các thông tin đó bao gồm: tên, mô tả, các thông tin địa chỉ và các tọa độ. Thông tin địa chỉ chính là lớp AddressInfo.

Landmark(String name, String description,
              QualifiedCoordinates coordinates, AddressInfo addressInfo)

Ví dụ: cách tạo ra một Landmark

...
AddressInfo textAddress = new AddressInfo();
textAddress.setField(AddressInfo.COUNTRY , "UK");
textAddress.setField(AddressInfo.CITY , "London");
 Landmark landmark =
  new Landmark("My Restaurant”,” My Restaurant best in  the world",
                       new QualifiedCoordinates(11.289496608768690, 34.59678880927362,460, 31.32, 45.000)
                       , textAddress);
...

LandmarkStore là một vùng được chia sẽ để lưu trữ, chỉnh sữa và xóa Landmark. Thông tin Landmark có thể được lưu trữ trong data store và có thể được sử dụng sau này khi ứng dụng cần nó.

Location API(JSR 179) trên J2ME – Phần 1

I.Giới thiệu

JSR 179 là một gói tùy chọn javax.microedition.location được cung cấp để truy cập các thông tin dựa trên vị trí. Location API cung cấp một chuẩn cho các developer viết các ứng dụng di động dựa trên vị trí. Location API cung cấp thông tin về vị trí địa lý hiện tại của thiết bị. Nó có thể được sử dụng với nhiều profile J2ME.

1.Tính toán vị trí(Expressing Location)

Vị trí có thể được thực hiện trong điều kiện không gian hay mô tả text. Vị trí không gian được thực hiện theo dạng hệ thống tọa độ: vĩ độ(latitude) – kinh độ(longitude) – độ cao. Vĩ độ được tính 0-90 độ bắc hay độ nam của đường xích đạo, ngược lại kinh độ được tính 0-180 độ đông hay độ tây của kinh tuyến chính, đi qua Greenwich, Anh. Độ cao được tính bằng mét so với mực nước biển. Mô tả text được tính thông qua địa chỉ đường, thành phố, mã vùng…

2.Vị trí thiết bị(location device)

Ứng dụng có thể sử dụng các phương pháp sau đây để tính toán vị trí thiết bị:

• Cell ID(sử dụng mạng điện thoại): phương pháp Cell ID tính toán dựa trên xác định các trạm BTS(Base Transceiver Station) kết nối với thiết bị. Độ sai số của cách tính này phụ thuộc vào kích thước của cell của thiết bị di động kết nối với BTS.
• Hệ thống định vị toàn cầu GPS(Global Positioning System)(sử dụng vệ tinh): việc xác định bằng GPS thường là phương pháp chính xác nhất, tuy nhiên nó có một số nhược điểm, đó là nó đòi hỏi phần cứng(hardware) cao, tốn pin khi sử dụng và đòi khỏi thời tiết đẹp hay để thiết bị ở những nơi thoáng đảng để có thể kết nối với vệ tinh.
• Bluetooth(xác định vị trí trong phạm vi hẹp): việc định vị bằng Bluetooth được thực hiện trong các phạm vi hẹp, chừng 10m, độ chính xác cao, tuy nhiên phương pháp này đòi hỏi thiết bị phải có hỗ trợ Bluetooth.

Bluetooth API – JSR 82 – Phan3

VI.Bluetooth Communication

Ứng dụng Bluetooth đã thực hiện các phần sau đây để giao tiếp: khởi tạo stack, thiết lập chế độ discovery, discovery thiết bị, decovery dịch vụ và kết nối.

1.Khởi tạo stack

Trong các thiết bị Bluetooth, stack Bluetooth được sử dụng để điều khiển thiết bị. Vì vậy, nó nên được khởi tạo đầu tiên trước khi bắt đầu. Sau khi được khởi tạo, các thiết bị sẽ sẵn sàng để sử dụng.

Đặc tả JSR 82 cung cấp lớp LocalDevices. Lớp này được gọi như là một entry point cơ sở, và nó giúp khởi tạo stack. Điều này cũng được sử dụng để kiểm soát các cài đặt Bluetooth cục bộ. Lớp LocalDevice cung cấp mức thấp nhất để truy cập vào stack Bluetooth, ngoài ra nó còn câp cấp khả năng truy cập thông tin về thiết bị Bluetooth của riêng bạn.

Để khởi tạo stack, ta đơn giãn chỉ cần gọi phương thức tĩnh LocalDevice.getLocalDevice().

2.Chế độ Discovery

Để thiết lập chế độ Discovery, ta chỉ cần gọi phương thức LocalDevice.setDiscoverable(int mode). JSR 82 hỗ trợ các kiểu sau:

• DiscoveryAgent.GIAC
• DiscoveryAgent.LIAC
• DiscoveryAgent.NOT_DISCOVERABLE

Một thiết bị Bluetooth có thể chứa nhiều thiết lập chế độ Discovery. Ví dụ, một thiết bị có thể cấu hình để không bị discovery, lúc này các thiết bị Bluetooth khác trong phạm vi cho phép không thể phát hiện ra thiết bị Bluetooth này. Mặc khác, một thiết bị Bluetooth có thể cấu hình để được discovery bởi các thiết bị khác, và trong trường hợp này, chế độ Discovery chính là GIAC(General Unlimited Inquiry Access Code).

Một thiết bị Bluetooth cũng có thể cấu hình để có thể được discovery “limited” bởi những thiết bị Bluetooth khác bằng cách sử dụng một limited inquiry. Bằng cách này,        chế độ discovery được thiết lập sử dụng Limited Dedicated Inquiry Access Code(LDIAS).

Bluetooth API – JSR 82 – Phan2

III.Cấu trúc Bluetooth API

Mục đích của bản đặc tả đã được xác đinh là một chuẩn API có tính mở, không độc quyền và có thể được sử dụng bởi tất cả các thiết bị hỗ trợ JavaME. Vì vậy, nó sử dụng chuẩn API và Java ME CLDC / MIDP ‘s Generic Connection Framework(GCF). Các đặc điểm quan trọng:

• Đặc tả này cung cấp hỗ trợ cơ bản cho các giao thức và profile Bluetooth. Nó không bao gồm các API cụ thể cho tất cả các cấu hình Bluetooth đơn giản chỉ vì số lượng profile là ngày càng tăng.
• Đặc tả này kết hợp các các giao thức truyền thông(communication)OBEX, L2CAP, và RFCOMM trong JSR 82 API, chủ yếu bởi vì tất cả các profile Bluetooth hiện tại được thiết kế để sử dụng các giao thức truyền thông.
• Đặc tả JSR 82 địa chỉ hóa  Generic Access Profile, Service Discovery Application Profile, Serial Port Profile, và Generic Object Exchange Profile.
• Giao thức Service Discovery cũng được hỗ trợ. JSR 82 định nghĩa đăng ký dịch vụ một cách chi tiết để chuẩn hóa quy trình đăng ký cho các lập trình ứng dụng.

JSR 82 đòi hỏi stack Bluetooth nằm bên dưới thực thi JSR 82 đủ tiêu chuẩn cho Generic Access Profile, Service Discovery Application Profile, và Serial Port Profile. Stack phải cũng cung cấp quyền truy cập vào Service Discovery Protocol; các tầng(layer) RFCOMM và L2CAP.

Các API được thiết kế theo cách sao cho các nhà phát triển có thể sử dụng ngôn ngữ lập trình Java để xây dựng profile Bluetooth mới trên đỉnh của API này miễn là các đặc tả lớp lõi(core layer) không thay đổi. Để thúc đẩy sự linh hoạt và mở rộng này, bản đặc tả không bị giới hạn bởi các API cài đặt các profile Bluetooth. JSR 82 bao gồm các API cho OBEX và L2CAP để trong tương lai các profile Bluetooth có thể được cài đặt trong Java. Hình 1 cho thấy các API được định nghĩa trong đặc tả phù hợp với kiến trúc của CLDC/MIDP.

Tìm hiểu Bluetooth với J2ME

Trong bài này, chúng ta sẽ tìm hiểu các chuẩn giao tiếp đơn giãn của Bluetooth và cách thức để tạo ra một class đơn giãn bao đóng được công nghệ Bluetooth.

Công nghệ không dây

Hiện nay, trên thế giới có các công nghệ không dây nổi tiếng như: infraree(hồng ngoại), wifi, bluetooth và zigbee. Hồng ngoại là công nghệ được sử dụng phổ biến trong điều khiển tivi từ xa hoặc điều hòa không khí điều khiển từ xa, nơi mà giao tiếp được trỏ đến các thiết bị đích. Công nghệ wifi thì được sử dụng rộng rãi trong các lĩnh vực truyền thông và công nghệ thông tin. Zigbee là công nghệ mới nhất, nó rẻ hơn tất cả các phương tiện truyền thông không dây khác. Công nghệ Bluetooth là công nghệ được sử dụng hầu hết trong các thông tin liên lạc tạm thời, đặc biệt là bên trong các thiết bị di động, palm,pocket PCi, vv. Nó có thể được sử dụng để trao đổi các đối tượng, các gói tin, hoặc một stream đơn giản.

Các loại giao tiếp Bluetooth

Có 3 loại giao tiếp trong công nghệ Bluetooth:

• OBEX: Viết tắt bởi “Object Exchange” giao thức giao tiếp được sử dụng để trao đổi dữ liệu vật lý như các tập tin, hình ảnh, và kể cả các định dạng nhị phân.
• L2CAP: Viết tắt bởi “Logical Link Control and Adaptation Protocol” được sử dụng để gửi các gói dữ liệu giữa máy chủ và máy khách.
• RFCOMM: Viết tắt bởi ” Radio Frequency COMMunication” được sử dụng cho luồng dữ liệu đơn giản.

Canvas API

I.Giới thiệu

Trong J2ME, người dùng tương tác với MIDlet thông qua các thành phần giao diện. Có 2 loại giao diện:

• Giao diện cấp cao(High level API)
• Giao diện cấp thấp(Low level API)

Giao diện cấp cao

Giao diện cấp cao có tính linh động rất cao, được sử dụng để tương tác với người dùng cuối. Tuy nhiên hạn chế của nó là các control rất ít, và đặc biệt là xây dựng các giao diện đồ họa phức tạp thì không thể đáp ứng.

Giao diện cấp thấp

Giao diện cấp thấp được sử dụng trong các ứng dụng đòi hỏi có đồ họa phức tạp và truy cấp đến các sự kiện mức thấp. Nó cung cấp các phương thức để xử lý các sự kiện phím, game và màn hình cảm ứng. Các API của nó được dùng để vẽ các image, thực hiện các chuyển động, cuộn hay xoay màn hình. Nó được sử dụng mạnh mẽ trong game hay các ứng dụng đòi hỏi tính đồ họa phức tạp.

Sơ đồ tổng quát của nó như sau:

Tạo Menu Sử dụng LayerMananger

Sau đây, tôi xin giới thiệu tới các bạn một kỹ thuật tạo menu cho game bằng hình ảnh sử dụng các class LayerManager và Sprite trong gói javax.microedition.lcdui.game. Lưu ý, trong ví dụ này, tôi giả định rằng, độ rộng màn hình bằng 240, chiều cao màn hình 308(đây là chiều rộng và chiều cao mặc định trong emulator của Sun Wireless Toolkit). Giao diện của nó như sau:

Ứng dụng bao gồm 2 class: MenuScreen và MenuMidlet, lớp MenuScreen như sau: