冰浪

      說到移動網絡應用，前幾年大家首先想到的就是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相關的功能一定要在真機上多測試。

   程序界面的有限設計原則

         我們的客戶端軟件不是瀏覽器，這點要時刻牢記?？蛻舳塑浖芴幚淼姆掌鞫说膬热莺蜆I務流程都是相對受限的，也正是因為客戶端應用軟件對于其他環節的限制要求，才能保證客戶端應用相對于瀏覽器應用更好的用戶體驗。例如，在實踐中無論是服務器傳回的內容格式，還是客戶端界面層次級別，都是可以要求確定的，其他如軟件報刊閱讀界面上的字體大小、間距、可下拉屏幕的最大長度等都是可以在需求的時候就確定下來的。

     支持多款手機平臺

      問題：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開發人員的素材積累。

         關注投入產出比

         客戶端軟件開發面對眾多不同的手機平臺不是一個理想的平臺，因此也很難有一個理想的結果，我們所能做的是在可以接受的范圍內尋找一個最佳的投入產出比。按照我們前面提到的移植思路，第一次移植按照程序可以使用的屏幕大小分類，選擇五個大類手機進行針對性的開發和移植就可以了，如果一款手機離這五個大類差距都比較大而又不是非常流行的話，不如放棄算了。

        代碼移植

        通常我們需要使用一些針對于手機終端特性的程序代碼來創建優化的應用程序。例如在只支持Nokia-UI API的手機上播放midi格式聲音的方式和支持MMAPI的手機上播放midi格式聲音的方式是不同的，后者上可以運行的代碼到前者就無法運行。又如某一款手機上通過接口獲取的字體高度和實際顯示的字體高度是不一致的，同樣的代碼在不同的手機上就會出現美丑不一的UI界面，這意味著我們不得不在程序中針對終端特性或者缺陷編寫一些代碼。怎么來完成這個任務？兩款手機屏幕的大小相差兩倍都不止，如何來做UI界面的代碼移植？以下分析幾種方法：

        1. 每款手機或者每類手機都各自維護一套代碼 這種方法可以最好地發揮程序的性能，也可以避免無用的代碼導致編譯后的程序大小膨脹。但是將來如果要添加一個新的程序功能，就不得不在每套代碼中都實現一遍。后期的版本跟蹤和維護是一件非常困難的事情。

         2. 利用編譯器優化來調整代碼 通過使用帶有static final 變量的if else 語句，Java編譯器在編譯的時候可以去除那些永遠也不可能被執行到的代碼。例如使用if (Configuration.IS_SUPPORT_XXXX)，來表示后面是針對支持XXXX特性的手機的代碼，否則編譯時這段代碼就會被精簡掉。這個方法不錯，但是每款手機都要維護一個Configuration源代碼文件，隨著支持設備的增多，某些情況下又要對Configuration文件進行分類合并，另外一個問題是，不能“動態”地import類，也不能“動態”使用類變量類方法，在開發過程中的開發環境不能針對于某個具體的手機類型。

         3. 第三方預編譯工具 這種方法和上面一種方法有點類似，在代碼中加入判斷的預編譯指令，所不同的是它在程序編譯之前就對代碼做了修改，這樣可以實現“動態”地使用類和類的變量、方法。這種方法對于每一款手機也需要一個設備的配置文件，里面描述我們關注的一些設備的能力和參數，和上面的方法不同的是它的配置文件不需要作為源代碼導入，可以保存為XML格式的文件，通過將各種手機終端設備配置文件匯聚起來，就是前面提到的設備資料庫，一般是XML形式組織，隨著項目的進行代碼管理的復雜度不會增加。我們實踐中使用的一個第三方工具J2MEPolish就是使用了使用預處理標記來區分不同手機的代碼，使用預處理器對代碼進行處理，使得其生成針對某一款或某一類機型的特定代碼，然后再由編譯器進行編譯。

          智能網絡客戶端

           手機的網絡條件目前還是不樂觀的，一方面是速度慢，另一方因為手機信號原因，不能保證網絡的穩定，用戶的一次網絡交互可能需要等待很長時間返回或者根本不會返回。如果采用瀏覽器的方式，必然導致用戶體驗的大幅下降?？蛻舳酥宰罱鼤d起，其中一個原因就是客戶端可以更智能，可以在離線和在線狀態之間切換，并且在離線情況下仍然有一定的可用性。要改善用戶的移動網絡業務的體驗必須要在這個環節下功夫。

            微軟的Smart Client架構是這方面一個非常強大的架構，在我們的手機報實踐中，借鑒了Smart Client的思路和部分設計模式，使得用戶的網絡服務請求和界面操作獨立開來，通過合理的服務調用流程，可以讓用戶獲得最佳的體驗：用戶無需花時間等待任何網絡服務請求操作，在網絡服務器請求完成以后以最合理的方式通知用戶而不打擾用戶使用手機報?；诳蛻舳说膽眠€有一個好處就是可以接收服務器Push的消息，這也使它看起來更“智能”。可以通過短信等方式將客戶端軟件遠程喚醒并傳遞消息。這些功能都是傳統瀏覽器應用所不具備的。可以預見，服務器端也需要針對于智能客戶端的新特性提供新功能。

            下面列出一些智能客戶端環節需要關注的一些問題：

           如何緩存用戶操作數據，以應對網絡異常，并保證用戶體驗？

          用戶的網絡操作返回以后，如何判斷是否要提醒用戶？

          如何檢測網絡狀態，以改變客戶端的工作狀態？

          如何針對運營商網絡優化應用層通信協議，選擇數據包的大小，保證通訊效率的同時保證成功率？

      小結

        前面簡單介紹一下基于KJava的手機網絡應用客戶端軟件開發實踐中的幾個關鍵問題上的心得，在實際程序開發、調試過程中還有很多關于開發環境、各種終端以及網絡的非常規的問題，只能*自己在實踐中去體會。另外因為KJava平臺和手機終端本身的限制，有些問題在上層應用開發層面是沒有辦法解決的。最近“智能手機”的興起，大多給了開發者提供了除JavaME平臺以外的選擇，發揮的舞臺也更大，將來的趨勢也是手機的可開發性越來越好，限制越來越少，但目前的移動終端和移動網絡相比于PC和互聯網都是相當受限的。

         回到手機的網絡應用上來看，客戶端軟件可以提供更好的用戶體驗，但是和服務器還是一個整體，一般業務的核心是還都是在服務器端。在客戶端基本功能完善以后，剩下的就是如何完善針對于客戶端應用的服務器的功能，這一塊相比之下更值得挖掘，意義更大。我相信這是未來最具潛力的軟件架構之一，基于客戶端的移動互聯網應用才剛剛拉開帷幕。