《BREW進階與精通——3G移動增值業務的運營、定製與開發》連載之87——面向BREW平台的移植

在移植之前，要確定移植的目標即該應用可能採用的商業模式，判定哪些內容需要移植，是應用的演算法還是資料結構，是商業邏輯還高層網路邏輯，或者是使用者介面。

            在移植之前的另一件事情是確定哪些是平台獨立的介面屬性，哪些是特定平台的介面屬性。看一看有沒有使用C的標準庫函數，有沒有依賴於特定平台的函數，最好是對這些宏和函數進行封裝而不是簡單的替代他們。明確運行時的限制同樣非常重要，例如記憶體，線程，同步介面，位元組對齊等等。對於原來基於多線程的應用，在移植到BREW平台上的時候，一般要採用回調機制來實現（AEECallback）。

            在移植的開始時最好建立一個自己的測試環境來檢驗應用移植層關鍵的API以及應用中重要的API，並提供對記憶體和資源使用狀況的跟蹤。採用OEM層類似的方法，可以建立一個應用移植層的參考實現，將與平台相關的屬性在這一應用移植層實現，這樣會使將來的應用調試非常簡便。

            在將應用移植層建立之後，需要在自己的測試環境進行檢驗，首先是單元測試，然後在模擬器運行，最後在手機上運行測試，同時檢測記憶體的使用狀況和演算法執行的效能。在測試完應用移植層外，就可以將目標應用平台獨立代碼和應用移植層整合起來了。這時可能會合并或者建立自己的使用者介面，接下來就是測試整個應用，然後認證（一般是商用測試TBT）並且發布移植的應用了。

            將一個PC上的應用移植到BREW上時，要特別關注記憶體模型，一般要重寫演算法和資料結構，考慮一個單獨的記憶體 Clerk，同時要注意運行時的效能。從其他手機平台向BREW平台移植可能會簡單一些，通常要特別注意檔案組織圖和使用者介面。在移植的時候要牢記，不要讀寫應用中的資料區段，BREW中不建議全域和靜態變數，注意位元組對齊和高地位的位元組順序以及非同步通訊方式。在移植的時候最好能夠獲得更多的編譯器警告，通常到Level 4 的警示，可以把這些警示當做是移植時產生的錯誤。在定義依賴於平台的介面時，以及在手機上運行時，要剖析記憶體和CPU的效能。