豆瓣音乐人app的PhoneGap实践

　 　 豆瓣音乐人app在2011年开发时，便采用了基于原生与webapp混合架构的PhoneGap框架，直到今天。这也是目前豆瓣唯一一款使用 PhoneGap的app。最近我们刚发布了音乐人app的ios新版，仍然保持这一架构，在原生方面的功能上做了一些增强。PhoneGap为音乐人 app的顺利发布带来很大帮助，当然同时也造成了一些局限。

　 　 当时如何做出使用PhoneGap的决定

　 　 我们之所以在技术选型时作出这一选择，主要有以下几个方面的原因：

1. 开发效率的考虑

   尽管豆瓣音乐人的用户对app有很强的需求，但音乐人app的定位和发展方向，当时处于不断探索和快速迭代的阶段，这样的情况意味着，音乐产品线希望使用尽可能简单的方式、占用较少的人力资源进行开发，尽快在多个平台发布，并且对于迭代的需求能够快速响应。在各种因素的权衡中，优先考虑满足上述需求。

   对于原生app好还是webapp好这个问题，似乎一直有很大争议，实际上我不认为这是一个纯粹的技术问题。webapp在开发效率上的优势，原生app在性能和开发自由度上的优势，都是不言自明的，一个app是否采用混合架构，在我看来，最重要的因素还是产品定位和发展策略，如果希望尽快发布、跨平台、能快速响应可以预见的迭代，那么混合架构就很值得考虑。如果有足够的开发人员覆盖各平台、产品设计成熟度高、产品周期上可接受相对较长的开发时间，那么原生显然是更好的选择。

2. 跨平台的考虑

　 　 豆瓣音乐人会是一个以展示内容和收听流媒体音乐为主的app，那些只有原生代码才可以实现的功能，我们需要得比较少。这意味着，如果我们采用混合架构，需要实现的原生特性与需要解决的跨平台问题会较少，混合架构的优势会被放大。

　 　 即使考虑了第一个因素后认为值得使用混合架构，如果app本身的特性不适合webapp的方式，那也会显得没有这个必要。Webapp之所以开发效率高，一方面在于html+css+js能做的事情，比用原生代码做同样的事情要简单得多，另一方面在于方便跨平台。如果app里面要实现的功能，很多都没法用html做，必须用原生代码，那这两方面的优势都消失殆尽。

　 　 实际上，就在我们第一个版本发布前不久，设计方面进行了一次review，然后对app的整体外观风格和某些功能与交互做了大幅修改。但其实只用了几天，设计的修改就被完全实现了，这样的速度对web前端开发来说当然不是什么难事，但对原生app来说却是难以想象的。

　 　 App架构与开发工作流

　 　 PhoneGap只是个原生外壳，app的内核是一个完整的webapp，需要调用的原生功能将以原生插件的形式实现，以暴露js接口的方式调用。在webapp框架的选择上，我调研了当时的一些专用于webapp的js框架，几乎都不大成熟，没什么合适的，当然现在的情况已经大不一样了。由于音乐人app的规模不算大，而且在移动设备的webview中性能非常重要，我决定把一些小工具组合成一套微型框架来使用，尽可能优化执行效率。框架大致由以下小零件组成：

• jQuery；
• iScroll4（模拟app风格的滚动）；
• js模板机制；
• url分发与访问历史管理；
• 页面关系与页面切换机制；
• 基于Jsonp的带用户认证的api接口封装。

　 　 这样就简洁地实现了最小化的js框架。之所以使用jsonp的方式通信，是因为我非常希望能使用chrome进行调试，这样开发时就很方便，只需要双击本地的html文件，chrome就会成为一个完美的移动设备模拟器，我可以使用自己喜欢的任意前端开发调试工作流，这比任何移动设备模拟器都要方便得多。

　 　 有了框架，接下来只需要一个页面一个页面实现就好了，我把webapp部分作为git submodule，ios和android的仓库都包含它，打包时使用各自的编译发布流程即可。