服务购

　　Hybrid App开发怎么办？小编为大家带来三个Hybrid App开发方案，快来找找灵感吧。

　　方案一（Web架构为重）

　　优点：

　　全Web开发，一定程度上有利于Web前端技术人员快速地构建页面样式；

　　有利于在不同的平台上面展示同一个交互层；

　　便于调试，开发的时候可以通过浏览器的方式进行调试，工具丰富。

　　缺点:

　　虽然说你可以专注在界面以及交互开发上了，但是这页会成为一个缺点，比如说要仿造一个iOS的默认设置界面，就需要大量的html以及css代码了，而且效果不一定和iPhone上面的界面一样好；

　　正因为这是跨平台的开发，所以还是这句话：兼容是前端的痛。了解过在Android机器上面的Web开发就知道这个痛了。比如前些年在Android设备上面写圆角，border-radius:10px，在Android的设备上面会出现毛边。

　　便于调试其实是在Web界面层的。但是实际上做Hybrid App开发的时候，你会遇到需求，进入手机的底层请求，做某些处理。比如说如果该应用有Push Notification服务的话，你就需要到底层，获取Push Notification发生时的数据，以及做相应的交互处理。当然类似PhoneGap这类框架，已经有很好的插件机制去帮助你解决类似的问题，当然还有Game Center之类的插件，具体的话可以到Github去关注PhoneGap官方的账户，资源非常丰富。

　　方案二（编译转换方式）

　　优点：

　　利用自己熟悉的语言，进行应用开发，比如RubyMotion，就是使用Ruby语言去做iOS开发，开发起来的话，代码量是数量级地下降啊。

　　部分开发工具提供跨平台的功能，让你的应用能够快速地发布到不同的平台上面。比如Mono社区的Xamarin，就是典型的例子了。使用C#语言，能够把你的应用发布到iOS，Android以及WinPhone市场上面；

　　开发出来的程序运行高效。大部分这种架构的应用，其实还是非常依赖底层的东西的，而且包括界面的东西，都是使用原生的API，效率就当然要比类似于PhoneGap这种架构要好了。

　　缺点：

　　严重依赖于其工具厂商提供的工具包，调试的时候就要有全套的工具。当然一般来说这些厂商都会以收费的形式发布他们的工具，相应的也有客服提供技术支持。遇到系统升级，第三方sdk升级，开发工具出现bug等，那么就要等待工具厂商解决了。相当于把风险压在对方身上了，自己却要承担责任。

　　方案三（Native架构为重）

　　优点：

　　这无疑是最稳定的Hybrid App开发方式了，交互层的效率上由Native的东西解决了，而且架构上基本就是在App内写网页，连App Store都是采用了该种方案；

　　开发时分工非常明确，底层的由iOS开发人员处理，上层的由Web前端开发人员处理；

　　有效的在线参数配置方式，以便于及时在线替换界面；

　　缺点：

　　团队至少需要两个工程师，一个是Web的，一个是iOS的。当然如果开发人员会两种技术也可独立承担；

　　还是运行效率，要权衡好多少界面采用Web来渲染，毕竟WebView的效率会相对降低，以前Facebook就是因为Web的渲染效率低下，把整个应用改为原生的解决方案。当然这里面可以通过优化来解决。但是优化也是有限度的，如Ruby创始人Matz所说优化要恰当（包括花的时间，技巧等），而且有时候的优化达到的回报率不一定达到你自己的期望。