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