Web

谈几个概念

Hybrid

随着HTML5的发布，Web入侵Native的脚步愈发紧凑。Hybrid的概念被街谈巷议，你可能会遇到：

• 又空降一个CTO，“效率这么低，我以前的团队都是用Hybrid”
• 又换了一个产品，“发布这么麻烦，怎么不用Hybrid？”

但是我只想说：“Hybrid根本就是裸奔”，为什么？

1. 从资源布局的角度：

平台	布局文件	布局文件格式	编译布局文件	渲染
HTML	*.html	xml	×	WebView
Android	*.xml	xml	√	View
iOS	*.xib	xml	√	UIView

• 虽然三者的布局文件格式都是xml，但是Android、iOS在编译打包时会对xml做压平处理，形成二进制的xml。
• HTML则是直接对未加处理的文本格式xml进行解析，再生成符合HTML标准的DOM树，再对之渲染。

如果你说处理文本跟处理二进制没什么区别，那我无话可说。

2. 从加载代码的角度：

• Native用原生语言，编译期间生成了二进制的字节码(Byte code)，在运行时可以直接被加载运行。
• HTML用Javascript脚本（字符串），需要在运行时通过内置的Javascript引擎加以解析，而后转成字节码运行。

Semi-Hybrid

因为Hybrid性能表现差，于是业界催生了Semi-Hybrid - 半混合模式。 即渲染保留原生的，布局使用自定义。

通俗点讲就是：创造一个自己的布局语言，用自己的代码解析成Native控件。

有几个知名的工程：

1. Samurai-Native
2. React-Native
3. 淘宝App（布局json，渲染TBLayout，可以看下我仿的版本）

不得不说这些都是神级大作，但是也有些不可否认的缺憾：

1. 如果你不做编译，运行时还是直接对字符串操作
2. 难以团队化

因为接入成本太高，首先我要学会你的新语言，再让我的成员学会它。
即便你成功组建了这样一个团队，但是换个公司又得重新来过。

3. 滞后风险

官方的新特性不定期发布，新语言可能要跟随做适配，但你等不了。
举个例子，在iOS5.0时代，我们有个项目用了BEE框架，但是到7.0的时候原生的UINavigationBar、UITabBar出了侧滑特效。用BEE无法满足，最后苦逼的重构回原生。不过还是感谢这个框架，算是接触到的第一个架构级别的开源项目。

我们的选择

Semi-Hybrid虽然看起来很华丽，并确实如此，但是侵入性太高，想说爱你很难。

Hybrid虽然不堪，但保留了纯正的HTML/CSS/Javascript血统，与Web兼容，可以应用在一些对性能要求比较低的界面。 这些界面通常是交互少的纯展示类界面，比如：

• 关于我们
• 帮助
• FAQ

更进一步

当确定了使用纯正的语言(Native + Html5)开发，如何让二者的沟通与交互保持自身的纯正性就是我们的追求。而实现这步也就实现了跨平台，要做到这点，必须有几个标准：

• Android使用标准的ActionBar
• iOS使用标准的NavigationBar
• 打开界面使用统一的URI
• JS调用使用统一的接口