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 则变成了容器与内容的关系。