Hybrid app 发展历程

　　距离上一篇 《基于微信 js-sdk 的简单应用》已经快一年了，说来真是惭愧。上次不久之后便换了工作，一直处于比较忙的状态。其次后面酣畅一段时间都没有从事移动相关的工作。直到今年3月份开始，临时借调去支持其他项目组又开始接触到移动项目中去。

　　今天要讲的还是hybrid , 至于原因，每每谈到移动互联网，谈到hybrid ， 我总是欣喜的。犹记得2013年夏天，hybrid 概念才刚刚兴起不久，对移动互联网毫无所知的我去参加了H5工程师的实习招聘；当然最终面试没有通过，虽然在学校的项目经历，对方很认可，然而对方主要业务方向便是移动互联网；面试官认真的介绍了Native app, Web app 以及 Hybrid app 的区别和各自优缺点；瞬间点燃了我要去做移动开发的决心。

　　第一阶段：诞生

　　由于深受Native开发成本，迭代周期之痛和Web app 体验之殇，hybrid 一诞生便广受欢迎，迅速成名。然而当时的hybrid 大多的webview 之流 ， 因此 phonegap / cordova 几乎只要听过hybrid 的人都知道， JQuery , Extjs , 也纷纷推出了移动版本的 JQ Mobile , 和 Sencha Touch ,使得Hybrid 的开发成本迅速降低，而体验有所提示。

　　第二阶段：融合

　　webview为主的Hybrid 解决了很多兼容性问题，提升了一定的用户体验。然后webview 在动画上有着天然的缺陷，并且提供给H5使用的端能力非常有限；既然H5实现动画非常卡顿，那为何不把动画交给Native , H5只负责每个页面中的内容。于是，一个SPA应用又被切成的多页存在于多个webview容器中。web容器来负责页面之间的切换效果，即使网络终端，容器仍然可以提供一些错误处理能力，不至于页面整体白屏，并且不可操作。第二个端能力便是上次提到类似微信jssdk 的中间层了。更原始一点我们也可以直接和Native 协商一些 scheme 协议 和回调，来直接和native 通信，然而这实际操作中会导致H5很难维护。 jssdk 实际上是指一段本地化的js文件，也叫js-bridge, 即 native 和 h5 之间通信的桥梁 。 bridge 对H5 暴露一些简单和统一的 api ，使得h5 和 Native  之间的通信变得非常简单。

 

　　第三阶段：离线

　　移动场景和PC 一个很大的不同便是网络环境，PC场景下大多是家庭宽带，办公环境等等，网速通常比较快。而移动端除了4g, 还有很多3g,2g网络，网速成为用户体验一个很大的瓶颈；离线化正式为了解决资源加载问题。通过资源离线化，可以解决首页白屏，等一系列因资源加载慢导致的用户体验问题，离线化之后对NA的要求会提高，资源包缓存更新策略，网络请求，设备，位置信息等，H5 对native 的依赖会更加明显，相对H5部分的开发则实际变得更加简单。附上糯米组件化平台化演进之路

　　第四阶段：React Native

　　react 和 react native 的出现甚至比Hybrid 的出现更令人惊喜和兴奋。不仅仅是新的库和工具的升级，而是开发思路和理念的升级。虚拟dom ; Learn once, write anywhere 等。都让人眼前一亮。这个阶段在手淘和其他一些公司也都有在使用了，我厂native 团队也在积极研究react native 的runtime , 争取早入集成到现有的app 当中；react native 的不同在于，完全脱离的webview 的方式, 以一种全新的方式来让前端工程师可以快速写出可比native体验的 app 。

 

　　这仅仅是我从一个前端工程师角度所看到的hybrid这些年的一些变化，正如 Hybrid 是native + webapp 的混合产物，hybrid的发展，不仅仅是前端工程师的推动，更需要native 工程师支持。如何让那个我们的Hybrid应用能快速拆解组合，也是native 和 前端共同去做的事情。就现在来讲，手淘，糯米，手百，这些大流量app ,都在朝着平台化的方向发展，能够快速接入H5 应用，并提供相应能力；而对于H5应用，也可能同时接入到手百 和糯米的平台当中；平台需要保证高度的扩展性来满足不同H5的需求 ， 而H5则需要最大化的降低自己在不同组件平台中的迁移成本。 native 和 H5 则变成了容器与内容的关系。