基于PhoneGap與Java開發的Android應用的性能對比
作者：佚名
此次的調研的重點是針對一個Android應用的基礎需求，用phonegap與Java實現的應用在性能及開發成本等方面的對比。本次選擇用phonegap和Java各自實現一個ListView的內容展現功能的應用；同時引入另外一個常用組件GridView來實現圖片瀏覽的功能應用。
此次的調研的重點是針對一個Android應用的基礎需求，用phonegap與Java實現的應用在性能及開發成本等方面的對比。
開發一個應用的最基本需求應該是瀏覽性需求，而在Android開發中ListView比較常用的控件，廣泛被用于數據列表的展現上，而且也比較靈活。所以本次選擇用phonegap和Java各自實現一個ListView的內容展現功能的應用；同時引入另外一個常用組件GridView來實現圖片瀏覽的功能應用。
Delicious書簽訂閱應用
一、應用功能描述
Delicious書簽訂閱應用。進入應用首先展現訂閱的書簽源列表，點擊書簽源項，進入書簽源書簽列表頁，共展現***的20條書簽。
二、應用界面截圖
1、PhoneGap delicious bookmark
2、Java delicious bookmark
三、功能測試對比
【測試機器為 Google Nexus One G5】
| Android應用類型 | Html5 (phonegap) | Java |
| 功能實現 | Html + jQuery基礎庫 | ListView組件 |
| 文件大小 | 159KB | 23KB（只用了系統的原生界面） |
| 內存占用 | 45.37MB(RSS) | 27.02MB(RSS) |
| 數據通信 | Ajax | Apache http Java功能包 |
| 啟動速度 | 打開相同訂閱源2.7秒 | 打開相同訂閱源2.3秒 |
| 操作響應速度 | 正常操作速度流暢，頻繁操作響應會變慢 | 操作速度流暢 |
| Monkey注入5萬個事件測試結果 | Events injected: 50000:Dropped: keys=17 pointers=43 trackballs=0 flips=0 ## Network stats: elapsed time=1108130ms (0ms mobile, 1099670ms wifi, 8460ms not connected)
// Monkey finished
|
Events injected: 50000:Dropped: keys=28 pointers=53 trackballs=0 flips=0 ## Network stats: elapsed time=1216977ms (0ms mobile, 1216977ms wifi, 0ms not connected)
// Monkey finished
|
| 穩定性 | 在Monkey測試注入大約4萬個事件時，整個應用已經處于空白無響應狀態。有連接超時情況發生。手動頻繁操作會引起，響應速度變慢，webkit的WebView不能很好釋放內存，甚至會引起應用的crash。 | 能較好處理Activity切換延時等待。運行較為流暢。Monkey測試時書簽列表頁切換時有時候會出現黑色背景，然后再載入列表，比正常速度稍慢。能夠比較好的釋放內存，沒有出現過應用crash的情況。 |
| 資源占用 | 對于頻繁操作時，內存釋放不夠理想，導致內存占用上升。 | 內存占用相對比較穩定。 |
| 開發成本 | 運用html + css + javascript開發，適合前端人員開發。由于webkit在不同的終端機發行版本不一樣，所以需要針對不同的機型進行適配。同時對于不同屏幕大小在適配上也只能通過Javascript進行控制實現。 | 適合有Java開發經驗的程序員，可以充分利用Android提供的組件進行開發。但是開發學習成本較高。 |
| 開發難度 | 目前phonegap只使用一個WebView，開發時需要使用OPOA(One Page, One Application)的模式，對代碼的組織方式及開發方式有較高要求。同時介于手機的資源有限，對如何管理和分配內存提出了要求。目前phonegap可以在控制臺輸出簡單的JS調試日志，但是并不方便。 | 需要有Java開發經驗，同時對Android開發體系有較深入的了解。 |
| 多人協作 | OPOA模式并不利于多人協作并行開發，只能通過基礎的javascript的設計模式來解決多人協作的問題。 | 比較方便支持多人協作并行開發。 |
| 其它問題 | 1、需要通過Javascript來管理操作的歷史記錄，并保證返回鍵能夠正常使用；同樣也包括選項鍵。2、不提供調用新的WebView，不能把現有的wap版的內容直接包裝到應用當中。 |
#p#
空間圖片瀏覽應用
一、應用功能描述
在應用中創建一個gridview方式展示的圖片列表。 圖片總數 48， 16行3列。 原生app使用gridview布局和渲染。webapp使用了jquery和jquery.mobile（后者依賴前者）
二、應用界面截圖
1、PhoneGap mm100 photo viewer
2、Android Java mm100 photo viewer
三、功能測試對比
【測試機器為 Google Nexus One G5】
| Android應用類型 | Html5 (phonegap) | Java |
| 功能實現 | jQuery與jQuery Mobile基礎庫 | GridView組件 |
| 文件大小 | 220KB | 72KB |
| 內存占用 | 40.6MB(RSS) | 29.9MB(RSS) |
| 啟動速度 | 約7秒（js大小會直接影響速度） | 約3秒 |
| 操作響應速度 | 在內容比較多的時候，都不是很流暢。調用外部交互：彈窗提示為例，會比原生大約有1s的延遲。 | 在內容比較多的時候，都不是很流暢。調用外部交互：原生app基本上瞬間響應。 |
| Monkey注入5萬個事件測試結果 | Events injected: 50000:Dropped: keys=20 pointers=72 trackballs=0 flips=0 ## Network stats: elapsed time=1460305ms (0ms mobile, 1440448ms wifi, 19857ms not connected)
// Monkey finished
|
Events injected: 30002:Dropped: keys=7 pointers=10 trackballs=0 flips=0 ## Network stats: elapsed time=230436ms (0ms mobile, 230436ms wifi, 0ms not connected)
** System appears to have crashed at event 30002 of 50000 using seed 0
|
| 穩定性 | 由于交互深度較淺，所以整個Monkey測試過程較為流暢，但是還測試完畢后還是存在WebView內存無法釋放的情況。 | 整個Monkey測試過程較流暢。 |
| 資源占用 | Webapp占用內存約40.6M，占用應該主要是由于webapp是基于瀏覽器的，并且加載了一個java庫所致。所以資源占用應該不是線性的。 | 占用內存約29.9M，內存占用相對比較穩定。 |
| 開發難度 | 對于比較簡單的應用，在同樣具備完善基礎庫的條件下，兩者開發難度基本一致。 | |
| 其它問題 | 1.內存優化：webapp因為是基于瀏覽器的，而瀏覽器自身是進行了相應的優化的，所以在圖片顯示上很不錯。 原生app如果在一頁中顯示比較多的圖片的時候，必須比較細致完善的進行內存優化工作，否則極易出現因為圖片資源過大而引起的崩潰問題。
2.圖片縮放裁切 webapp一般情況下通過js和css來進行縮放裁切。在進行圖片動態縮放的時候，頁面顯示情況不是很正常（抖動，跳躍）。***的辦法是后端服務器對圖片處理后再發送給手機端。
原生app可以直接通過java來對圖片進行處理。
3.布局 原生app可以利用android提供的特殊技術方案，來自動適應多種分辨率的屏幕。如9png 和 多drawable目錄。 相當簡單方面。 但是在交互方面，原生app的開發量會比較大。
webapp就比較杯具一些了，需要開發者比較多的關注。 可以通過js來動態的獲取屏幕尺寸進行資源調整和加載（開發幾套不同的ui，然后根據分辨率js動態加載），這個會花費比較多的時間。
4.調試
webapp js調試不太方便，特別是調用外部應用的時候。如果是本應用內部，可以通過firebug進行調試。
|
|
總結
此次對比主要集中在對大量數據通信下web app UI性能。通過與Java app相比較，web app的UI性能會比Java app的UI性能差。主要原因是依賴webkit瀏覽器內核的渲染解析能力。同時在只有一個WebView的情況下，如何控制內存的上漲速度以無法釋放內存的情況無縫地重新啟動WebView從而不影響用戶體驗，是一個現實待解決問題。
在非大數據量且不需要頻繁更新UI的情況下，基于wekit瀏覽器phonegap模式還是可以滿足Android開發應用的需求。同時應用的實現的效率還依賴于OPOA開發模式的Javascript基礎架構是否強大和高效。
對于不同分辨率的屏幕，需要通過JS或者通過要集成的框架封裝來解決適配的問題。同時由于不同版本的Android所集成的webkit的版本不同，同樣也需要處理不同版本的在JavaScript和CSS支持上不同的兼容性問題。還有解決開發時多人協作及方便的調試工具集成，也是進行html5 app開發的重要前提條件。
此次對比主要集中在對大量數據通信下web app UI性能。通過與Java app相比較，web app的UI性能會比Java app的UI性能差。主要原因是依賴webkit瀏覽器內核的渲染解析能力。同時在只有一個WebView的情況下，如何控制內存的上漲速度以無法釋放內存的情況無縫地重新啟動WebView從而不影響用戶體驗，是一個現實待解決問題。
在非大數據量且不需要頻繁更新UI的情況下，基于wekit瀏覽器phonegap模式還是可以滿足Android開發應用的需求。同時應用的實現的效率還依賴于OPOA開發模式的Javascript基礎架構是否強大和高效。
對于不同分辨率的屏幕，需要通過JS或者通過要集成的框架封裝來解決適配的問題。同時由于不同版本的Android所集成的webkit的版本不同，同樣也需要處理不同版本的在JavaScript和CSS支持上不同的兼容性問題。還有解決開發時多人協作及方便的調試工具集成，也是進行html5 app開發的重要前提條件。
【編輯推薦】
責任編輯：佚名
來源：
百度搜索研發部博客
