随着移动浪潮的兴起，业务在移动端App 的需求量迅速扩大，应用迭代更新的频率也随之极速攀升，但与此同时纯 Native 的开发和更新成本成为了业务增长难以逾越的瓶颈。因此，引入一种开发更高效、成本更低的解决方案势在必行，而在去哪儿这个解决方案就是 Hy。

Hy 方案是平台事业部移动框架组耗时近两年完成的跨平台移动开发 Hybrid一体化的渐进式解决方案，旨在让开发者使用前端技术开发跨平台的移动应用程序。Hy 方案从设计之初到现在经历了非常多的变化，战场从小型独立客户端到去哪儿大客户端，业务从零个到近百个。一路走来，Hy 经历了无数考验，并获得了璀璨的成果，在公司内受到了大家的肯定。

下面，将从几个方面介绍Hy，包括它的架构、理念以及作为开发者的我们经历的一些心路历程。

天下武功，唯快不破。

在当前的移动互联网环境下，iOS和Android上的App已经成了每个互联网产品的标配。如果一个用户端产品并不提供相应 App 版本，几乎会直接定义成一个不完整的产品。而被互联网人尊为铁律的『唯快不破』—— 快速开发、高速迭代、低成本上线，同时也是移动时代每个开发团队所追求的目标。综合以上两点原因，『Native 搭台，Web 唱戏』的 Hybrid 开发模式，以『快』的特点赢得了大家的青睐，并纷纷投入大量开发力量，使这种开发模式迅速走红。

Hybrid 开发模式是什么？它兼顾Web App『快』和Native App『全』的一种开发模式；它不依赖版本的实时更新，快速实现跨平台需求，同时，又能通过 Native 提供的Api 调用原生功能，解决了纯 Naitve 原生架构，开发『慢』、发布『慢』、更新『慢』的问题，使迭代速度『快』得可以完全满足产品的需求。

与此同时，2014、2015年正是去哪儿在移动端发力、业务增长迅猛的一段关键时期，因此公司决定更广泛使用 Hybrid 开发模式，同时我们团队也肩负起 Hybrid 方案架构设计和开发的艰巨使命。当然，我们并没有辜负大家的期望，于2015年初上线了第一个 Hy 方案独立 App（ CRM App），并于年中正式提供 Hy 1.0 完整方案，并且终于在最近完成了自我进化——Hy 2.0 发布，基于最新的 React 进行架构，提供更好的技术、工具、文档、统计支持。

不仅仅是混合，更多的其实是融合。

对于 Hybrid 开发模式，有人认为它会把Web App扼杀在摇篮里，有人认为它会把Native App引向一个新阶段。而我们的观点是，Hybrid 开发模式更像萃取两方精华、剔除两方糟粕的一条崭新道路，它不会替代任何一方，只是给开发者更多的选择。而 Hy 方案的架构、设计方向正如文章标题所说，Native 和 Web 都有它们自己的『美好』，也有各自的『痛点』，而 Hy 方案要做的不是纠正他们的错误，而是融合他们的『美好』，用对方的『美好』，解决自己的『痛点』，让它们真正地『在一起』。

关于融合，其实要从两方面来谈。第一个方面是 Web 融合 Native，也是大家通常所认知的Hybrid —— Native 给 Web 暴露 API，使 Web 具有调用 Native 功能的能力，最著名的代表就是 Codova（PhoneGap）；第二个方面则是 Native 融合 Web，Web 所具有强大的发布能力和大规模协作的能力是 Native 所不具备的，因此 Native 结合自身的特点对 Web 的优秀能力进行融合是必要的。

Hy 方案在融合上进行了很深入的探索和实践。在 Web 融合 Native 方面，适配层不仅仅支持了 iOS 和 Android 的壳，还对微信、Touch 进行了充分适配；在 Native 融合 Web 方面，Hy 方案提供了完善的离线资源更新机制，让业务发布 App 上的业务和发布常规业务一样快速简洁，并方便管理。

『磨』平平台差异，真正的跨平台。

其实，在谈到前端Hybrid 或者 HTML5 时，大家第一印象其实是『跨平台』——Wrtie Once，Run Anywhere。C 的跨平台基于它的编译器跨平台，Java 的跨平台基于它的运行时 JVM 跨平台，而前端跨平台其实是基于浏览器。虽然 Google、Apple 等大公司主导的开源浏览器内核 WebKit 占领的绝大大部分移动市场，但是由于开源，手机厂商都会对自己设备上 WebView（浏览器）进行『所谓的调优』，因此最终导致现在并没有像JVM 一样统一、靠谱的前端运行环境，使『跨平台』的成本大大加大。

其实不仅仅是跨平台，交互尤其是富交互的一致性、离线状态展示等都是业务经常会遇到的问题。面临这样严峻的问题，作为框架的 Hy 方案必须要在这个方面做出突破，将业务经常遇到的坑填平，真正抹平各个平台的差异。

因此，团队下足了功夫。不论从样式到组件逻辑，还是从整体架构到细节处理，都深入去研究、实践、测试。例如，对于高清屏边框1px 的方案，先后更换了三次方案，最终基本完美的解决了问题。这不仅仅是技术，更重要的是态度，一点点打磨，最终磨平平台差异，实现真正的跨平台。

坚持渐进式，坚持组件、插件化，坚持不断的进化。

从设计使用至今，Hy 方案一直保持着其渐进式的特点，而且为了保持这个特点，在框架设计和开发时，一直坚持组件、插件化，使框架本身核心健壮的同时，拥有很强的扩展性。

以 Hy 方案 2.0 版本举例， 整个『大礼包』，它共分为5大部分：

  • 前端层 Yo：包括样式、组件及前端路由。
  • 适配层 HySDK：适配和客户端环境，同时也适配微信和 Touch。
  • Native 底层 Hytive：提供定制化 WebView，以API 形式提供 Native 功能，并以自定义插件的形式扩展业务功能。
  • 离线包和热更新机制：提供静态资源离线缓存机制与平台化的资源管理服务。
  • Ykit 工具集：提供定制化的工具方案。

开发者在使用时，并不需要使用完整的『大礼包』，而是根据实际情况，渐进式地选择 Hy 2.0 的某个部分进行使用，并可随时根据自己的业务场景进行扩展。如果开发者只是做简单的页面，可以只使用 Yo 的样式；当需要一些页面组件时，可以通过 Ykit工具加入相关的组件；当需要开发内嵌到客户端或者微信内的项目时，可以使用 HySDK；最后，开发者觉得项目有必要离线、弱网可用，那可以在热更新平台进行离线包的发布。

和 Hy 1.0 相比，Hy 2.0 保持了渐进式的设计思路，但是对概念进行了简化合并，并同时对代码基于 React 进行重构，在引入业界先进思想的同时，对实现方式进行了一下大幅度优化，提升在设备上的运行效率。

重构不是造轮子，是一个破立而后生、不断进化的过程。

Hybrid 是不是『银弹』？要优化的路还很长。

业界有这样一套正反逻辑，始终处在争论的最中心。正逻辑：当移动设备性能尤其浏览器性能提高了，Hybrid 开发模式足以代替原生开发模式；反逻辑：当移动设备性能提高了，原生方案和 Hybrid 开发模式的性能同时提高，两个开发模式之间还会有性能差距，而 Hybrid 会永远处于追赶的地位。

其实，不论哪个逻辑实现，Hybrid 做好自己就行，它的目标只有一个：使用 Hybrid 开发模式开发的产品能满足用户的体验即可。而 Hy方案的目标也是有一个，就是尽可能的进行优化，将开发体验和用户体验提升到极致，努力成为去哪儿乃至整个集团最优秀的 Hybrid 解决方案，满足公司绝大部分的业务场景，减少业务线的开发成本，至于是不是『银弹』，由时间来评定。

对于 React-Native，是兄弟也是竞争对手。

提到 Hybrid 肯定要提到近一段时间的『网红』—— React-Native，而我们团队也根据去哪儿的实际情况推出了 QRN —— 去哪儿基于 React Native 深度定制的移动平台框架，旨在让移动开发者使用 JavaScript 进行移动平台的高效开发；它拥有极高的代码复用率、丰富的 API 扩展、更快的加载速度、完善的部署系统等优秀特性。这时，难免大家会有疑问，Hy 和 QRN 究竟是什么关系？

大家如果喜爱金庸武侠的话，应该听过这样一个说法：金庸武侠中最强的武功不是九阳神功更不是九阴真经，而是双手互搏。双手互搏可以让武者同时使用两种武功，更好的应对实时变化的战局。而老顽童周伯通在桃花岛的山洞里也是靠着双手互搏，模拟对战，来提升对武功的理解和自身实力的。

Hybrid 和 QRN 就像两种武功，而团队在使用双手互搏。在应对不同的场景时，推荐业务使用不同的解决方案。例如，在处理多数据多图片的需求时，QRN 处理的比较好；而一些纯的展示需求， 或许 Hy 方案会有更好的表现。在应对不同业务场景的同时，两个方案也是竞争对手。虽然开发框架的同一个团队，但毕竟是两个项目，两个项目之间的重点部分可以时常作比较，例如首屏速度和 List 性能，把相互的优点作为各自目标来优化本身，同时促进两个方案的快速成长。

写于最后。

正如标题所讲，Hy 方案的出现不是为了替代谁，更多的是为了『彼此间的美好』，让 Native 和 Web 更关注自身的优势，最终可以形成一个辅助业务团队进行快速开发、高速迭代，而且降低开发、更新成本的一套实用、务实的一体化渐进式解决方案。

回顾这两年走过的路，Hy 的发展史几乎等同于我们团队的发展史，从一个概念化的雏形，走到现在各方面都比较完备的产品，种种的经历也使我们不断地成长。在这期间，公司各个业务线也给予我们的方案和团队极大的肯定和支持，在这里表示下我们的感谢。最后，我们团队将在今后的工作中，继续发扬自己的风格，为业务提供更多更好的移动前端解决方案。