技术 | Hybrid载体的变化(三)

如图:惊讶的变化

前面两篇文章从客户端的两个角度来说了说变化,今天我们从前端的角度来看一看这些变化,对于我们的工作会有什么样的改变,记得在2013年下半年时在携程做Hybrid App,当时对于前端的选择很有限,最好的解决方案也只是require.js + zepto.js + backbone.js,而今天,特别是VirtualDOM的出现让Hybrid最终的呈现将不止于Web,有了UIView这种Native的Render Engine,或者类似小程序这样,严格分离的Web Render Engine,这些火花的碰撞,正是因为前端技术方案的变化而引起的。

模块化是前端工程化的一块非常重要的基石,而工程化的出现意味着你的应用可以在“可维护性”,“多态复杂场景”下达到一个最优的平衡,以前我们在写一个Hybrid页面时可能是这样的:

define(['baseView'],function(baseView){   
    return baseView({   })
})

而现今:

import baseView from 'baseView.js';
class indexPage extends baseView{}
export default indexPage

从直观上代码更易读,侧面来说可维护性达到了空前的高度。当然现在不一定是要baseView,你也可以通过一些方式去写一些基类,就像“UIViewController”一样有一些比较通用的方法,来处理“导航栏”的设置,转场等等。将这些比较通用的地方交给框架来处理,会降低业务编写的成本。带来这一切要从webpack,babel的普及,让我们可以从一个更易读的方式来书写JavaScript代码,这些构建上的变化改变了我们思考的方式,如今我们会更倾向用“package.json”来维护项目,因为npm提供了强大的脚本钩子来让我们执行我们编写的构建脚本。

Facebook在2014年的时候开源了一个前端库“React”,说实话当年它一出来我们就在思考这样的方式可以对Hybrid这样的模式带来什么变化,它总结了视图处理的方式,当然我们并不能去“狭义”的比较,当然一句document.xxx操作DOM的方式在只有改变一个值的情况下的意义,这样的类比以前讨论的很多,这样的比较毫无意义,但是为什么“它”敢说它比操作DOM要快?那是因为一个页面不仅仅只有一个DOM,当你全部重绘,肯定要比绘制一部分要慢,而“React”要解决的就是绘制一部分。很多年前Backbone也提供了数据变化而更新视图的功能,你可以用发布订阅模式来处理这一部分,但是你还是需要去手动的操作DOM的更新,比如当你使用backbone配套的jQuery时:

this.$el.html('<div></div>')

这一部分传统意义上是可以交给框架去处理的,在“React”出现之前,“Angularjs”接替了一部分这些工作,那我们为什么要着重去说“React”呢?因为VirtualDOM这种来表现视图的描述,它为跨平台提供了基础和可能,这是AN无法比拟的。VirtualDOM将视图通过通用的结构来描述,比如:

{
tagName: "div",
children: [
{         
        "props": {              
            "className":"xxx",              
            "tagName":"div"
}
}
]
}

对于Web的意义它描述的是一组DOM节点以及节点上应该有的属性,如果对它进行一定的扩展,理论上它可以描述任何可以绘制的界面,你需要实现的只是对应的Render Engine而已。这也正是为什么React会存在ReactDOM这样的一个模块,它就是Web 的Render Engine,用来绘制Web界面。那么,如果我们在Native端也实现一个NativeReactDOM这样的Render Engine,这也意味着你可以用UIView这样Native的UI来描述界面,这也正是在后期出现的React Native的原因,没有VirtualDOM这一层抽象的描述,你很难做到一个真正意义的跨平台。如果有心的朋友应该可以发现Facebook又开源了一个库叫ReactVR,这也正是利用了VirtualDOM的抽象描述,在对应的VR上实现Render Engine来达到的其目的。Hybrid模式的出现也是想利用Web技术来写移动App,但是它不是完美的一种解决方案,真正没有瑕疵的跨平台,还真要感谢VirtualDOM的出现。

说到了描述界面,我们应该还要关注一种CSS的布局方式,我们知道传统的网页布局float或者postions,特别是前者在移动端上的实现会比较蛋疼,后来为了简化布局,CSS技术上出现了一种叫Flex布局的方案,这个方案就非常容易来描述移动端上的实现,Facebook又提供了一个库来实现移动端的Flex布局叫yogo(https://github.com/facebook/yoga),当然还有css(https://github.com/reworkcss/css)将css转换成了JSON对象形式,有了这些,剩下需要做的就是通信了,看来我们又可以回到前面两章中提及了JavaScriptCore,它来沟通Native和JavaScript,将一个Native界面完完整整的绘制了出来。

其实又不得不提到另外一种思考:“transformer”,babel的出现将ES6转换成了AST,通过操作AST又可以将代码转换成ES5,它可以直接跑在不支持ES6的浏览器中。“transformer”也就是转换的一种实现,它来具体的操作AST,将代码转换成你想要的,这个的意义是在“编写”上的,如果一个技术很难书写,对于普及是有很大限制的,为什么React可以如此流行,那是因为JSX的一种语法定义,我们可以用HTML的方式来描述React,这种方式又称之为“DSL”,我们可以定义一组通用的标签来描述,在“transformer”的帮助下将它转换成JS可以执行的描述。

当你在描述:

<div className="icepy"></div>

你得到的却是:

React.createElement('div',{ className: 'icepy'})

甚至将你的CSS也进一步转换成对象,比如:

{
fontSize: '12px'
}

有了这些,你在对应的地方实现Render Engine,就可以将一个界面绘制出来,想想,为什么会出现React Native,Weex这样的移动UI框架的原因,就在于此了。

你身边如果有朋友对混合领域(跨技术栈)或全栈,编程感悟感兴趣,可以转发给他们看哦,^_^先谢过啦。

原文发布于微信公众号 - 子曰五溪(fed-talk)

原文发表时间:2017-05-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券