该文章来自于阿里巴巴技术协会（ATA）精选文章。
导读：Native向左，HTML5向右，两者都是为了解决移动应用的问题，各有优势劣势。为结合HTML5开发便利动态性强和Native体验佳性能优的特点，让未来趋势和现实要求结合，鸟巢（Birdnest Native），一种全新的Native APP开发模式，应运而生。
背景：通过下面这段文字向大家介绍一下鸟巢，以及简单分析鸟巢的优势和劣势，鸟巢的适用场景和解答对鸟巢的疑问。欢迎大家参与讨论。先通过一段简单的视频演示鸟巢的实现效果：
什么是鸟巢
鸟巢（Birdnest native），一种通过前端技术扩展Native动态能力的解决方案。运用HTML5+CSS+JavaScript这些前端技术只是为了降低接入门槛。鸟巢为Native APP，提供的是一套从前端到后端的整体方案。技术目标是：
1.将Native页面开发难度简化为前端HTML5页面开发；
2.提供媲美传统Native的用户体验；
3.将业务复杂度放在服务端，可以通过动态推送实现业务功能更新。
+ + ->
图1、运用前端技术进行鸟巢Native APP开发
有了鸟巢，开发Native APP页面和开发一个HTML5页面一样简单：
图2、鸟巢页面代码和Native效果
鸟巢的特点
动态能力是鸟巢的初衷，鸟巢打造了从前端到后端的整体动态能力输出方案，形成了一个闭环，这是它最重要的特点。采用这种设计是为了，降低接入门槛，降低学习成本。
鸟巢参数
| 方案 | 支持平台 | 语言 | 布局方式 | 扩展性 | 动态能力 | 体积 |
|---|---|---|---|---|---|---|
| 鸟巢 | Web、iOS、android | HTML5+CSS+JavaScript | CSS Layout+Flex box | Bridge+Native Module | 服务端客户端整体动态方案 | android:650K，iOS:800K |
从支持平台（Android、iOS、Web），语言灵活度（私有 or 标准协议），布局方式能力（自定义 or CSS Layout）、扩展性（自定义 or Bridge+Native Module）和动态能力（自定义 or 纯客户端方案 or 客户端服务端整体方案）五个角度分析方案的优缺点。每个角度分成3级，由内到外代表能力的从低到高。
鸟巢对比
图3、业内方案对比
从实际情况看来，鸟巢无论是在系统支撑上（iOS5+支持，Android同步支持），入门门槛上（了解HTML5即可上手），还是整体配套上（客户端服务端整体解决方案）都超出了其他几种方案。鸟巢的整体解决方案，使应用方可以专注于UI开发，而无需考虑动态更新相关的客户端和服务端改造。
鸟巢的产生
鸟巢的demo版有用过自定义协议，在经历了私有协议的反复折磨后，最终果断放弃。转而选择采用业界前端标准的子集。
- Layout的选择：在2014年底确认采用CSS Layout和Flex Box来重新设计实现，让Layout变得简单起来，以前通过线性布局和水平垂直布局实现的种种问题，都迎刃而解。
- 脚本库的选择：在果断放弃接受范围窄的脚本库后，我们选型了一个性能佳体积小的JS库，iPhone和Android采用同一套JS库，大大降低了鸟巢核心的开发成本，提供了一个稳定可控的鸟巢核心。
- 页面协议的选择：选择HTML5来做页面描述，遵守Chrome事实标准后，问题都消失了。如果选择私有JSON页面协议，开发一个工具来编辑维护JSON页面，工作量巨大，效果也不佳。
鸟巢的优势
依托前端开发技术，获得Native用户体验；遵守行业标准，学习门槛低；客户端服务端整体方案，改造接入简单；重后端设计，减少客户端升级依赖；
标准化
语法
以标准的HTML5、CSS和JavaScript语法为唯一标准语法，无私有语法协议；
私有协议，会让开发者在最开始就望而生畏。协议本身，会不断的随着业务需求的驱动增加修改。团队人员的变动和衡量标准的不一，会让协议本身都会成为一种负担。
实现效果
Chrome浏览器是衡量语法是否标准的唯一标杆，鸟巢展示效果保持和Chrome一致，无需关心多浏览器兼容性问题；
√ ×
图4、与Chrome展示效果保持一致
开发效率
上手快
Easy to learn：尽管鸟巢从实际需求及性能考量，只实现了里面的一个子集，这带来了一定的学习成本，但是成本很低。一个刚刚毕业的新人，一周以后就能够高质量的做出各式满足视觉要求的页面，培养成本远远低于一个Native开发工程师。
易复用
Write once，run anywhere。这是很多程序员的梦想。由于采用Chrome标准，因此在iPhone上实现的页面，放在Android上也是完全ok的。只是在实际工作中，不同平台视觉要求可能会有差异，其中一个平台可能需要在另一个平台的页面基础上进行二次开发，但是效率也已经提升了很多。从鸟巢实际情况看，开发效率提升到了原有的1.5~2倍。
使用成本低
改造成本
鸟巢对原有APP方案的侵入性很低：鸟巢是为了替代Native APP中的动态部分，并不是为了替代Native APP本身。应用方根据自身的不同需求，可以选择整个APP、APP中的部分页面或APP中页面的部分进行托管。
维护成本
鸟巢是一套整体解决方案，客户端解决页面问题，服务端解决页面的动态维护管理问题。使用方无需单独考虑页面的维护管理。
图6、APP使用鸟巢的调用关系图
稳定可靠性
鸟巢这种方式目前已经接入了：支付、线下、搜索、服务窗等业务，鸟巢的原型版本在过去的一年里，托管了整个支付宝手机端的多个页面，每天有亿级的Native页面通过这种方式支撑。
图7、接入的应用场景
鸟巢的适用场景
鸟巢并不是一个万能的事物，而是在有动态需求的地方，可以很方便简单的解决这个需求。在缺乏客户端开发资源的情况下，可以通过前端技术获得Native体验。鸟巢本身不是为了做一个APP，而是为了解放APP本身的限制。
全业务托管
整个APP的所有页面全部托管给鸟巢，鸟巢负责全部页面的渲染、管理、更新、缓存。如：支付宝钱包支付采用了这个方式接入鸟巢。这个方案的好处就是：通过业务服务端发布和鸟巢页面管理，整个APP都处于可控状态，随时可以进行业务上新、业务变更和bug修复，业务可控性达到最佳。
图8、全业务托管样例
全屏页面托管
整个APP中，只有有动态变化需求的部分页面，才托管给鸟巢。鸟巢负责这部分页面的渲染、管理、更新、缓存。如：支付宝全局搜索采用这个方式接入了鸟巢。这个方案的好处是：在原有APP基础架构上，只用针对性的接入鸟巢，就可以把变更频繁的业务沉淀到服务端，降低业务变更对APP升级的依赖性。
图9、全屏页面托管样例
页面部分托管
整个APP中，在一个框架相对稳定的页面里，只有页面的一部分区域是需要动态变化的。鸟巢负责这个页面部分的渲染、管理、更新、缓存。如：支付宝线下采用这个方式接入了鸟巢。
对鸟巢的疑问
有很多同学问我，鸟巢是不是这样的，或者这样的？这里统一解答一下。
平台无关性
理论上，以鸟巢的方案实现了iPhone的页面，Android在展现上也是OK的，多平台共用一套模板也是鸟巢鼓励的方向。但并不强制，如果视觉风格本身两个平台有差异，其中一个平台就可以在另外一个平台的模板基础上进行二次开发。总的来说，开发速度是可以提升为原来的1.5~2倍。
鸟巢绝不是另一个的浏览器
鸟巢绝不是另一个的浏览器！鸟巢与Webview没有任何关系。鸟巢不会发展H5应用，更不会在此基础上形成应用生态。只是用低门槛的方式，适应界面布局和有限流程的变化需求。
只是借鉴使用了HTML及CSS的语法，整体的Layout及DOM结构与浏览器的方案和策略完全不同，每一个标签最终都会映射到一个Native控件上，引入了一个完整的JS库，通过Bridge将Native代码与JS进行桥接。
如何保障性能
鸟巢采用H5标准的子集，并抛弃了浏览器的DOM渲染模式，自行设计了一套Layout方法。同时，针对移动设备本身的特点，严格选择了协议的子集来实现，从而保证不会像浏览器那样臃肿。