基于phonegap开发app的实践
app开发告一段落,期间遇到不少问题,写篇文章记录一下。
为虾米要用phonegap
开发app,至少要考虑android和ios两个版本吧,android偶可以应付,ios表示完全木有接触过,于是时间成本、开发成本上去了。phonegap则解决了这个问题,而且对po主而言,用web开发的方式来搞app很爽啊有木有!
当然,用之前还是要调研下,基于phonegap的app有木有成功案例。大公司里腾讯的qq邮箱ios版,豆瓣的豆瓣音乐人都是基于phonegap。重点看了看豆瓣音乐人,很无耻的反编译了一下apk,居然代码都木有压缩过 ,正好方便了偶研究。
豆瓣音乐人的实践
从体验上讲,豆瓣音乐人和native的app还是有差距,首先,点击tab有明显的延迟,另外,豆瓣音乐人整个页面只有一个view,即下图中的frame(view可以理解为app的一个界面,每个app看成是由很多个视图界面组成的),视图之间的切换效果,是先在frame下面再创建一个新frame,里面是将要切换进来的视图代码,然后用css3 transform做视图切换动画,动画结束之后,把原来的frame删除。也就是,在页面中保证只存在一个frame。
这么做应该是基于性能考虑,但是牺牲了部分体验,比如一个列表,滚动到第3屏,点到列表详情,再返回,视图不是停留在点进详情页之前的位置,而是回到了顶部。
豆瓣音乐人其实还是以浏览为主的app,功能比较轻,而我们的app则是包含了发帖、传图片等功能,表示鸭梨很大,但值得尝试。
技术方案
整体技术方案是:
phonegap负责和底层OS通信,调用摄像头、获取网络状态等
backbone+underscore做路由以及视图渲染
iscroll做布局
css3做动画效果
路由及视图管理
整个app其实是个single page application(SPA),对于SPA来说,路由和视图的管理很重要,我用了backbone+underscore来做这个事情。
通过backbone的router实现不同hash值对应不同视图,视图里用到的模版用underscore。
app布局
典型的app布局如下图,header和footer固定,中间内容可以滚动,第一个想到的就是用position:fixed,但是po主google一下,android 2.x,ios5以下不支持position:fixed,然后po主看到了业界比较推荐的 iscroll,试了些demo,po主就决定用iscroll了。
用iscroll有以下几点好处:
1、很容易实现app的布局,而且每个视图是用的绝对定位,这样做视图切换动画的时候很方便
2、下拉刷新,上拉加载也一并实现了
3、iscroll自带左右滑动的手势功能
弊端:
1、滚动区域里图片多了,低端机卡爆- -
2、iscroll引发的“ fake click”问题
其他倒没有什么弊端了
视图切换
考虑到体验问题,没有采用豆瓣的做法, 其实本来我是想用angularJs而不是backbone+underscore,但是angularJs的视图切换原理也是先append一个frame,动画结束再删掉这个frame,这种做法一是无法保留原有视图的状态,第二视图渲染是需要时间的,导致动画切换时,下一个视图会有很短暂的空白时间。
所以我的做法是,多个视图并存,要展示哪个视图就加上current,并调用计算视图相对位置和滑动动画的函数。
屏幕大小及分辨率适配
屏幕大小:布局要自适应不同的屏幕大小,所以固定宽度神马的尽量少用,改用百分比
屏幕像素密度:主要影响到css里引用的图片,以及页面中展示的图片(即img标签的图片),豆瓣音乐人的做法是对不同密度提供不同的图片,但是po主比较懒,只针对像素密度为2的做了一套,比如有个叫icon的div,我们可以这样
.icon{
width:20px;
height:20px;
background: url(‘../images/icon.png’) no-repeat 0 0;
background-size: contain;
}
icon.png的大小其实是40*40,这样虽然有点浪费资源,但是减轻了工作量啊有木有
对于页面中的img标签,提供的图片也是2倍展示宽度的,这个倒是浪费部分用户流量了- -
其他
dom操作和事件还是用的jquery,不要问偶为什么- -
关于开发中遇到的各种问题,请看 下一篇