【Hybrid App】Hybrid App开发实战( 二 ) _应用

缺点:
虽然说你可以专注在界面以及交互开发上了，但是这页会成为一个缺点，比如说要仿造一个iOS的默认设置界面，就需要大量的html以及css代码了，而且效果不一定和上面的界面一样好；正因为这是跨平台的开发，所以还是这句话：兼容是前端的痛。了解过在机器上面的Web开发就知道这个痛了。比如前些年在设备上面写圆角，-:10px，在的设备上面会出现毛边。便于调试其实是在Web界面层的。但是实际上做 App开发的时候，你会遇到需求，进入手机的底层请求，做某些处理。比如说如果该应用有Push 服务的话，你就需要到底层，获取Push 发生时的数据，以及做相应的交互处理。当然类似这类框架，已经有很好的插件机制去帮助你解决类似的问题，当然还有Game 之类的插件，具体的话可以到去关注官方的账户，资源非常丰富；
方案二（编译转换方式）
优点：
利用自己熟悉的语言，进行应用开发，比如，就是使用Ruby语言去做iOS开发，开发起来的话，代码量是数量级地下降啊。部分开发工具提供跨平台的功能，让你的应用能够快速地发布到不同的平台上面。比如Mono社区的，就是典型的例子了。使用C#语言，能够把你的应用发布到iOS，以及市场上面；开发出来的程序运行高效。大部分这种架构的应用，其实还是非常依赖底层的东西的，而且包括界面的东西，都是使用原生的API，效率就当然要比类似于这种架构要好了；
缺点：
严重依赖于其工具厂商提供的工具包，调试的时候就要有全套的工具。当然一般来说这些厂商都会以收费的形式发布他们的工具，相应的也有客服提供技术支持。遇到系统升级，第三方sdk升级，开发工具出现bug等，那么就要等待工具厂商解决了。相当于把风险压在对方身上了，自己却要承担责任。
方案三（架构为重）
优点：
这无疑是最稳定的 App开发方式了，交互层的效率上由的东西解决了，而且架构上基本就是在App内写网页，连App Store都是采用了该种方案；开发时分工非常明确，底层的由iOS开发人员处理，上层的由Web前端开发人员处理；有效的在线参数配置方式，以便于及时在线替换界面；
缺点：
团队至少需要两个工程师，一个是Web的，一个是iOS的。当然如果开发人员会两种技术也可独立承担；还是运行效率，要权衡好多少界面采用Web来渲染，毕竟的效率会相对降低，以前就是因为Web的渲染效率低下，把整个应用改为原生的解决方案。当然这里面可以通过优化来解决。但是优化也是有限度的，如Ruby创始人Matz所说优化要恰当（包括花的时间，技巧等），而且有时候的优化达到的回报率不一定达到你自己的期望。App和 App开发对比
因为方案三中的思想基本上就是原生应用的开发思想了。这里要做的对比应该不算大，因此笔者不会做太多的阐述介绍两者的不同。但是如果是偏重Web架构的，或者是以方案二这种透过特殊工具开发的，就和原生开发有对比了。这次笔者暂时会以方案一拿来讨论。讨论中主要会以架构，代码管理上来讨论，当然也会说到部分细节。
架构讨论：
因为这是偏重于Web开发的应用，这里面就需要开发人员有很强烈的大型Web前端架构思想在里面。提到这里可能马上浮现在你脑海中的词语就是：.js，.js，sea.js，.js等。没错，这些工具都能够帮助你快速地梳理好思路，管理好你的 Web应用。对开发者最友好的，发挥空间最大的非莫属了。所以笔者就会以应用展开讨论。（因为类似也有提供方案，但是本身是一个重量级的框架，而且有自己的思想在里头，加上他本身也提供开发工具，在这里就不适合讨论了。对于开发者来说可以根据自己的需求选择好工具）