行動電話通訊應用用戶端軟體開發實踐簡介

網路應用與用戶端軟體

說到移動網路應用，前幾年大家首先想到的就是WAP應用。最近隨著市場上手機的可程式化能力越來越強，手機軟體開發平台和產業鏈的逐漸成熟，手機上的網路應用軟體逐漸多了起來，如移動QQ、PICA、掌訊通等等。這些用戶端軟體憑著豐富的應用、以使用者為中心的體驗、良好的業務感知度逐漸成為WAP業務之後的又一類重要網路應用。目前的移動軟體開發已經逐漸從傳統的嵌入式開發中相對獨立出來, 主要指手機上的上層應用軟體開發，最近也成為了軟體行業的新興熱點。

作為業務運營的行動電話通訊應用用戶端軟體要求能夠部署到大量的手機終端，並注重和網路伺服器端業務的結合，目前這方面的開發參考資料還比較少。本文以手機報項目為基礎，簡單探討一下行動電話通訊應用用戶端軟體開發實踐中的幾個關鍵問題，希望對新進入者有所協助。假設我們需要開發一個高可用的行動電話通訊應用用戶端軟體，用於線上定購和閱讀電子報刊業務，覆蓋目前移動夢網使用者中佔有率最高的幾十款手機，下面結合KJava開發介紹一下我們的一些實踐心得。

使用者介面設計

問題：目前很少有人有手機用戶端軟體的使用者介面（UI）的設計經驗，UI設計開發的原則和流程是怎麼樣的？

手機用戶端軟體的UI設計和開發在整個軟體開發過程佔據相當重要的比重，對於沒有相關積累的團隊來說，我們估計，軟體UI開發占軟體全部工作量的40％左右。和其他面向終端使用者的軟體一樣，用戶端軟體UI設計的原則是：以人為本，保證簡單易行的操作方式，同時相容最大範圍的手持功能。目前的手機使用者介面主要分為兩類：通過導航鍵單手操作方式和觸控螢幕方式。這兩者在操作方式上有著較大區別，但實際項目中如果軟體的UI不是太複雜，出於開發成本考慮，UI設計可以主要針對方向鍵操作的手機，在此基礎上再稍做改動以相容觸控螢幕手機，這樣也是可以接受的。除此之外，手機用戶端軟體的UI開發還有如下幾點經驗：

程式開發人員早期介入

目前市場佔有率較高的手機大部分還只提供KJava開發介面，它的進階UI控制項很難滿足我們的要求，如果要達到設計的效果一般需要直接使用底層API自己實現。在UI設計開發的流程上，對於沒有UI開發經驗積累的團隊，建議在需求階段以後先進行原型介面開發，一是為了確認使用者的體驗需求；二是通過開發人員早期介入確保UI設計人員的設計效果是可以在確定的時間內實現的。第二點很重要，在手機這樣一個資源和能力都受限的平台上如果僅僅從UI人員的角度去設計介面，很容易導致無法按時實現或者在真機上的效果太差。UI介面開發階段一般的流程是這樣的：先由UI工程師和開發人員自由討論，定義出UI元素和大致操作流程，接下來是由開發人員進行實現，最後再由UI人員在已經實現的基礎上進行美學創作。

建議制定一個適合項目實際情況的UI設計開發流程，注意和UI相關的功能一定要在真機上多測試。

程式介面的有限設計原則

我們的用戶端軟體不是瀏覽器，這點要時刻牢記。用戶端軟體所能處理的伺服器端的內容和商務程序都是相對受限的，也正是因為用戶端應用軟體對於其他環節的限制要求，才能保證用戶端應用相對於瀏覽器應用更好的使用者體驗。例如，在實踐中無論是伺服器傳回的內容格式，還是用戶端介面層次層級，都是可以要求確定的，其他如軟體報刊閱讀介面上的字型大小、間距、可下拉螢幕的最大長度等都是可以在需求的時候就確定下來的。

支援多款手機平台

問題：KJava平台上的程式離“一次編寫，到處運行”還差得很遠：不同手機的螢幕大小相差很大，程式需要重新調整介面；不同終端的能力層次不齊；即便是同樣的功能，不同型號手機在具體支援程度和方式上也有差別；有些手機終端還有自己特有的BUG。如何讓我們的程式支援這幾十款手機？

一般在開發的時候我們先基於SUN公司的標準WTK或者是某款非常典型而且移植性比較好的手機（一般是Nokia）來開發一個基礎版本，然後在此基礎上按照目標終端的大類做移植，再在大類的基礎上做更細的移植，移植的過程如一顆樹狀展開，最後達到支援所有目標手機終端的目的。以下是一些開發和移植過程中的心得。

MVC設計模式 模型－視圖－控制器（Model-View-Controller，MVC）設計模式及其派生無疑是UI模型的最佳實務，手機應用軟體上更是如此。不同手機的螢幕大小差異非常大，在手機用戶端應用程式移植的過程中最大的困難就來自於UI介面的移植，MVC設計模式可以很好地使UI介面和程式的資料、控制相分離，從而把後期應用程式的移植這個難題基本控制在介面移植這個範圍之內。 MVC設計模式這裡就不介紹了，要注意的是整個應用程式大小的限制可能會約束設計模式的實現，即使是最小的類也會使整個應用程式的尺寸增大200位元組。實際中可能需要減少類的層次來保持JAR檔案在一個合理的大小範圍之內，也盡量不要使用單獨的類或者匿名類來做控制器，我們的實踐中使用一個控制器類來處理所有的商務邏輯，雖然這個類看起來有點臃腫，但是在這種限制條件下，有時候不得不做這種讓步。

建立裝置庫資料庫

所謂磨刀不誤砍材功，對於開發跨平台的應用來說，建立一個目標手機裝置資料庫非常重要，其中至少要包含我們的應用軟體所要用到的各種終端能力特性。網上能查到各種手機終端所支援的Java API等資料，這很方便但是除了螢幕大小外有時候有些參數不可*，而手機裝置的一個錯誤的參數或者BUG會耽誤我們開發調試過程中大量的時間。根據我們的用戶端應用程式所要用到的終端能力，可以做一個測試程式，用來測試各款手機終端對於這些能力的支援情況，例如：KJava平台的RMS儲存限制、最大記憶體限制、程式所能使用的螢幕大小、支援本地播放的多媒體內容類型、支援網路線上播放的多媒體類型、對連網能力的支援、程式運行時系統對電話呼入的處理以及對Push Registry程式自啟動的支援情況和表現等等。我們可以通過自己的測試載入器來建立目標終端上的這些屬性的資料庫，並不斷擴充。注意，以真機上啟動並執行結果為準，很多時候模擬器的表現和真機的表現是不一致的，基本上模擬器普遍都存在“缺陷”。

規範使用資源檔

為了方便移植，可以將所有的UI介面的圖片、提示文字等元素都抽取為資源檔，採用資源檔可以使得資源和代碼相分離。在設計階段注意制定UI元素資源的命名規範，這樣移植的時候就可以方便地替換。這種“Skin”的方式，也便於後期方便地更換程式的介面風格。對UI元素資源的規範也有利於UI開發人員的素材積累。