此次的调研的重点是针对一个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开发的重要前提条件。
【编辑推荐】