jquery mobile + sae开发手记

Jquery mobile无疑是一个优秀的JS框架，但到现在为止，还是没有看到基于jqm在移动平台上让人眼前一亮的应用，大家都在观望，到底webApp在移动平台上的定位如何。

这个月，基于SAE提供的移动平台开发了一个在线看漫画的应用，采用jquery mobile，实际体验了一把webApp的潜力及限制。

网站地址:http://kukubird.sinaapp.com

代码地址:https://github.com/memoryboxes/kukubird

系统架构:

SERVER:sae新建一个项目，用REST接口提供server端服务(我用了python+webpy，非常简洁):

为前端提供漫画名称、类别、卷/话等数据
为前端提供漫画地址解析
提供用户认证，浏览历史记录

CLIENT:sae新建一个移动项目，采用JQM提供前端浏览界面

采用CS分离的做法有几个优点：

SERVER端的漫画录入，修改是不会影响前端的，想要添加一部漫画，只要在后台加一下地址就可以了。
为扩展提供可能性，事实上，我们现在就是利用SERVER端的接口，写个脚本就一键将刚收录的漫画下载到本地了，目前网上不少漫画下载器就是这个道理。
前端的数据交互都用Ajax完成，完全是JS+CSS+HTML5完成，可以方便的用phoneGap打包。另外SAE也为移动项目提供了打包功能，什么本地环境也不用配，就可以拿到apk包及ios调试包了。
系统资源消耗是非常少的，server端开启memcache后，目前80个用户一天2个云豆就可以。当然图片的流量需要独立服务器支持。

系统细节:

让我们看一下一个完整的交互过程:

热门漫画浏览:

用户打开页面-->前端Ajax发送消息-->SERVER端跨域回应-->前端接受热门漫画列表-->重载pageshow事件，用listview渲染-->结束

漫画卷/话数浏览:

用户点击单一漫画-->前端Ajax发送消息-->SERVER端跨域回应-->前端接受漫画卷列表-->重载pageshow事件，用listview渲染-->结束

漫画页浏览类似

这样看来，没有什么了不起的，不过是将原来动态数据请求的部分，从直接操作数据库转移到Ajax方式而已。剩下的就是稳定性和前端的表现了。就我一点点测试来看，40W条数据内，SAE负担绰绰有余。数据量变大后，只要做好索引及表拆分，sae是绝对可以胜任的。

一点经验:

一般一个jqm应用由几个页面组成，不同页面间需要一些数据传递，有以下两个办法:

采用url写入data-xxx的传递办法，这里有比较详细的讨论。这个适用于点击一个连接传递给另一个页面数据的场景。

采用html5的本地存储接口:localStorage，这个方法很简洁，适用于多个页面共享同一数据的场景。

页面强刷的问题，有时候前台更新了数据，需要重载整个页面，我在jqm1.1.0中试验了很多方法，最终是reload比较靠谱，详见我上一篇博文。

在IOS系统中的优化，IOS系统中，safari对webApp的支持还是比较给力的，添加到主屏幕后，像这种漫画应用，浏览体验同原生的差不多。具体办法参考这里。

目前的缺陷:

如果对应用的UI要求比较苛刻的话，基本上后期就变成了改造jqm+重写CSS+自写效果的痛苦历程，我认为jqm暂时还不能胜任。对于非前端人员，还是老老实实用默认主题好了。

运行速度还是有待提高，在一些低配的手持设备上，还会卡，但在ipad之类设备上面，基本上流畅了。

最致命的问题，目前据我的实验，所有的OAUTH认证接入，都需要弹窗，浏览器访问webApp就罢了，但是在IOS系统中，添加到主屏幕，全屏访问你的webApp时，OAUTH认证便不能跳转回你指定的回调地址了，phoneGap打包的应用亦然，也就是说，你没法完美实现"用QQ号登录"这样的功能。目前我没有找到解决办法，如果大家有类似的需求，在使用jqm之前，需要好好考虑。

总体来说，目前的JQM是可以实现一些比较简单的数据交互网站，但如果你需要UI复杂，数据量巨大的交互应用，还是得原生App，当然，像 m.oschina.net这样的资讯类应用，JQM完全可以胜任。

ps:我对于前端开发并不熟悉，javascript也只是刚学习1个月而已，以上都是个人的主观感觉，仅供参考，不当的地方还请大家拍砖。