基於 PhoneGap 與 Java 開發的 Android 應用的性能對比

時間 2021-05-10

標籤 javascript css html 前端 html5 java jquery android 程序員 web 欄目 Java 简体版

原文原文鏈接

這次的調研的重點是針對一個Android應用的基礎需求，用phonegap與Java實現的應用在性能及開發成本等方面的對比。

開發一個應用的最基本需求應該是瀏覽性需求，而在Android開發中ListView比較經常使用的控件，普遍被用於數據列表的展示上，並且也比較靈活。因此本次選擇用phonegap和Java各自實現一個ListView的內容展示功能的應用；同時引入另一個經常使用組件GridView來實現圖片瀏覽的功能應用。

Delicious書籤定閱應用

1、應用功能描述

Delicious書籤定閱應用。進入應用首先展示訂閱的書籤源列表，點擊書籤源項，進入書籤源書籤列表頁，共展示最新的20條書籤。

數據來源由Delicious提供的JSON格式的數據。參考地址（ http://www.delicious.com/help/json）

2、應用界面截圖

一、PhoneGap delicious bookmark

二、Java delicious bookmark

3、功能測試對比

【測試機器爲 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的設計模式來解決多人協做的問題。	比較方便支持多人協做並行開發。
其它問題	一、須要經過Javascript來管理操做的歷史記錄，並保證返回鍵可以正常使用；一樣也包括選項鍵。二、不提供調用新的WebView，不能把現有的wap版的內容直接包裝到應用當中。

空間圖片瀏覽應用

1、應用功能描述

在應用中建立一個gridview方式展現的圖片列表。圖片總數 48， 16行3列。原生app使用gridview佈局和渲染。webapp使用了jquery和jquery.mobile（後者依賴前者）

2、應用界面截圖

一、PhoneGap mm100 photo viewer

二、Android Java mm100 photo viewer

3、功能測試對比

【測試機器爲 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開發的重要前提條件。