前言
近年来随着移动设备类型的变多，操作系统的变多，用户需求的增加，对于每个项目启动前，大家都会考虑到的成本，团队成员，技术成熟度，时间，项目需求等一堆的因素。因此，开发App的方案已经变得越来越多了。曾经有一段HTML5的小浪潮，无数的人参与或者看到过一个讨论：原生开发还是混合开发，又或者是Web开发？到底最佳实践是怎样的，笔者认为只有实践过的人才会知道。尤其是在这个充满各种变数的移动互联网时代。
--- InfoQ 李秉骏 《Hybrid App开发实战》
我们可以注意到，文章发布的时间为2013年，距现在整整两年多时间过去了，整个无线端技术领域发生了哪些翻天覆地的变化？用户手中的设备发生了哪些变化？Hybrid方案成熟了吗？HTML5的性能表现可以满足产品需求了吗？引用中的那个讨论，现在有结论了吗？......带着这些疑问，在开始我们正式的主题之前，我们先来聊聊现状。
现状
作为移动端WEB开发人员，由于移动端高度统一的webkit内核的存在，我们基本上不需要考虑其他内核的兼容问题。但是我们仍然不得不面临安卓的严重碎片化问题，各种国产内核给我们带来的心灵和肉体的伤害。咦，等等，ios呢？嗯，苹果总是能给我们带来惊喜，不是吗？但是苹果设备的视网膜屏幕适配，ios7的诡异表现就够让你忙活一阵的了......
笔者引用腾讯2015年移动互联网用户白皮书的部分数据，以折射出一些关于设备、系统、移动端浏览器的现状：
图一
图二
图三
图四
可以看到：
安卓用户持续增长
安卓碎片化现象仍然十分严重，不幸中的万幸的是：随着安卓4.4版本(KitKat)的普及，Web前端开发终于可以开始大胆地在项目中引入一些务实可靠的新特性，比如布局类的flex，比如标签类的datalist等，因为在KitKat版本之后，系统webkit的webview实现已经被替换为基于Chromium的webview实现。
图片数据来自于 http://caniuse.com
国产浏览器市场占有率很高，这一点值得所有前端开发者关注，因为，这意味着如果你想让你的页面在这些浏览器下表现良好，可能不得不去阅读它们官方提供的开发者文档。
ios端我们重点关注ios7的数据情况，因为html5在ios7上的表现一直不是很理想。
屏幕越来越大, 我们的交互要跟上。
用户的设备性能和网络环境越来越好。
总体来说：随着移动端设备的性能越来越好，移动端web开发终于可以大展拳脚，加上W3C一直在积极推进移动端的各种标准化落地，大前端的春天显然已经来临，但是，要想把一个用户体验极佳的产品交到用户手中，对于前端开发者而言，仍然充满了各种挑战：
屏幕尺寸越来越大，适配，适配，适配，这定将是一场持久战。
某些终端的诡异表现，诡异行为频繁出现。
提高性能，再提高性能。
Hybrid混合开发模式下的页面同步问题，页面分治问题等。
如何保证大前端合作时的高效协作和开发。
一个理想的无线端发布流程应该是怎样的。
Hybrid是什么？
移动端产品快速迭代下促生的某种混合应用开发技术，Hybrid有杂交，混合的意思，很形象地对这种开发模式进行了表达，故称为"Hybrid"。
为什么要Hybrid？
Hybrid架构是移动互联网时代，产品高速迭代要求下的产物。在面临何时引入Hybrid的问题时，绝大多数团队都会优先考虑成本问题，那么，对比无线端纯Native的传统开发模式，Hybrid能够带来哪些直观的好处？下表如是说：
注意：下表暂不讨论前端领域思想极为超前的ReactNative及其同类开发模式。
| 维度/模式 | Hybrid | Native | HTML5 | 其他 |
|---|---|---|---|---|
| 开发效率 | 由于采用混合模式开发，原生开发团队成员可以和移动端web前端开发人员共同协作开发，由于任务被分解，并行开发效率高。 | 传统原生开发模式，某些简单的页面开发不如web开发高效 | 开发速度快，上手易 | 暂不讨论 |
| 用户体验 | 由于直接获得了原生侧的某些能力，Hybrid页面的用户体验可以逼近原生体验 | 原生开发，用户体验表现极佳 | 坑多，无法获得原生侧能力，复杂场景下体验较差 | 暂不讨论 |
| 执行性能表现 | 性能表现良,但是受到webview容器本身的一些限制 | 优 | 除Hybrid侧获得原生侧的能力外，其他跟Hybrid侧表现基本一致 | 暂不讨论 |
| 管理方式 | 由于Hybrid需要通信桥的支持，因此需要成熟的框架支持，包管理机制也需要架构设计支持，管理成本较高 | 原生侧发布模式，有严格的应用市场审核机制 | web端构建发布及管理方式都较为成熟和轻量 | 暂不讨论 |
| 成本及总结 | 开发速度快，可以保证项目迭代速度，可以很好地进行并行开发，支持hotfix，快速版本回滚，兼顾原生能力和html5的灵活 | 由于应用需要审核，某些模块的改动不得不跟随大版本一起发布，导致某些发布场景比较受限和被动，对于hotfix支持较差，甚至无支持 | 技术成本相对较低，发布速度快，可以线上hotfix，支持快速版本回滚 | 暂不讨论 |
| 跨平台能力 | 能 | 不能 | 能 | 暂不讨论 |
何时需要引入Hybrid？
笔者2014年加入国内某创业团队进行移动端web开发工作时，经历了一年多时间的大前端磨合期，公司产品为主流的"轻"交互的业务型APP，创业团队的节奏十分紧张，每周四为固定发布日，为了在这么快的迭代速度下保证产品质量，前端团队当时决定在2.0大版本之后引入Hybrid实践，后端团队配合我们完成了无线端Hybrid的发布系统，当时前端团队只有3个人，两个原生开发和1个web开发（笔者自己）。
以下是我们前端团队的一些实践：
- 将某些将来可能一直变动的新模块采用html5进行开发
- 某些交互复杂的页面尽量采用原生开发
- 原生侧将常用的复杂控件调用接口暴露在jsBridge中
- Hybrid页面在应用内跟后端的交互将直接由原生侧接管
- 原生侧提供高度定制webview容器的接口
- 原生侧和jsBridge共同完成全局事件的管理和响应
- 原生侧debug包提供完整的log托管，webview调试入口
- ......
- 不断挖坑，填坑，整理和总结经验教训
就这样，笔者和ios,android侧的两位原生开发同学在实践初期就快速完成了几大主要业务模块的开发，由于引入了Hybrid，这些模块真正具备了［热插拔］功能，配合后端的发布系统，整个Hybrid模块的发布，回滚，更新变得极其灵活，web前端可以引入任何成熟的构建工具来进行管理，jsBridge的接口设计的非常简单，后期加入的同学可以快速熟悉这种模式。
笔者所在的团队实践的这种Hybid方案基本由原生侧主导架构，这个也是笔者比较推荐的Hybrid方案
回过头再回答开始那个问题：何时需要引入Hybrid？
笔者认为，如果存在以下几种情况，则可以考虑引入Hybrid方案：
- 产品迭代速度快，小版本间变更大，变动频繁
- 业务模式轻交互但是布局稍显复杂的某些页面，比如内容详情页等
- 团队原生侧开发人员少，但原生侧有统一的，稳定的架构
- 某些原来的html5页面体验差，急需改造为Hybrid的页面模块
- 其他明确需要Hybrid的场景
总之：不要为了Hybrid而Hybrid。
Hybrid实现的常见方案及优缺点
没有完美的最佳实践，只有不停地实践。
Web架构为重
- PhoneGap之流，跨平台，全web开发；用户体验存在一定风险，比如某个页面需要还原一个类似Native的设置界面效果，这个时候需要大量的html，css，js代码，最终效果可能还不理想。
- 兼容工作还是要做，而且很痛苦
Native架构为重(比较推荐的方式)
- 现在比较流行和成熟的做法，国内各大互联网公司的app均有实践。
- 一旦遇到十分棘手的兼容问题，原生侧可以直接接管
- web端和原生侧需要配合完成整个架构的落地
- 需要成熟的包管理机制
- 调试起来较为麻烦，需要原生侧支持
编译架构型
- ReactNative之流，RN的思想非常先进，本书暂不就这块展开详细讨论及评价。
我们需要做什么？
对于整个大前端团队而言，无论是原生开发还是web开发，都需要迫切学习相关的知识来进行友好地协作，以避免Hybrid开发过程中的各种“误会”。
接下来，就让我们从最熟悉的容器-WebView开始说起吧。