基于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、非常easy实现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，不要问偶为什么- -

关于开发中遇到的各种问题，请看下一篇

參考文献

豆瓣音乐人app的PhoneGap实践

移动Web单页应用开发实践——页面结构化

web app自适应屏幕方案探讨