基于 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开发的重要前提条件。
这次对比主要集中在对大量数据通讯下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开发的重要前提条件。

 

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程