开发者社区> 技术小美> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

基于 PhoneGap 与 Java 开发的 Android 应用的性能对比

简介:
+关注继续查看

此次的调研的重点是针对一个Android应用的基础需求,用phonegap与Java实现的应用在性能及开发成本等方面的对比。
开发一个应用的最基本需求应该是浏览性需求,而在Android开发中ListView比较常用的控件,广泛被用于数据列表的展现上,而且也比较灵活。所以本次选择用phonegap和Java各自实现一个ListView的内容展现功能的应用;同时引入另外一个常用组件GridView来实现图片浏览的功能应用。
Delicious书签订阅应用
一、应用功能描述
Delicious书签订阅应用。进入应用首先展现订阅的书签源列表,点击书签源项,进入书签源书签列表页,共展现最新的20条书签。
数据来源由Delicious提供的JSON格式的数据。参考地址(http://www.delicious.com/help/json)  
二、应用界面截图
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版的内容直接包装到应用当中。

空间图片浏览应用
一、应用功能描述
在应用中创建一个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 appUI性能会比Java appUI性能差。主要原因是依赖webkit浏览器内核的渲染解析能力。同时在只有一个WebView的情况下,如何控制内存的上涨速度以无法释放内存的情况无缝地重新启动WebView从而不影响用户体验,是一个现实待解决问题。
在非大数据量且不需要频繁更新UI的情况下,基于wekit浏览器phonegap模式还是可以满足Android开发应用的需求。同时应用的实现的效率还依赖于OPOA开发模式的Javascript基础架构是否强大和高效。
对于不同分辨率的屏幕,需要通过JS或者通过要集成的框架封装来解决适配的问题。同时由于不同版本的Android所集成的webkit的版本不同,同样也需要处理不同版本的在JavaScript和CSS支持上不同的兼容性问题。还有解决开发时多人协作及方便的调试工具集成,也是进行html5 app开发的重要前提条件。

 













本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/743721,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Java开发初级6.17.2
Java开发初级6.17.2
32 0
Java开发初级6.16.1
Java开发初级6.16.1
18 0
Java开发初级6.6.2
Java开发初级6.6.2
25 0
Java开发初级6.4.1
Java开发初级6.4.1
38 0
Java开发初级6.1.2
Java开发初级6.1.2
27 0
Java开发初级5.30.2
Java开发初级5.30.2
24 0
Java开发初级5.28.3
Java开发初级5.28.3
18 0
Java开发初级5.23.1
Java开发初级5.23.1
31 0
Java开发初级5.22.1
Java开发初级5.22.1
15 0
Java开发初级5.19.2
Java开发初级5.19.2
17 0
+关注
6819
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载