中华视窗是诚信为本,市场在变,我们的诚信永远不变...
背景
从前,如果我们打算实现某个需求,通常需要三种程序员(IOS, 安卓,前端)写三份代码。这就带来了非常大的开发成本,所以业界也一直在探索跨平台方案——从最早的H5, 到现在的weex, React 。这些方案的本质目的都是,一套代码,多端运行。
H5和的发展
早期H5和方案的本质是,利用客户端App的内置浏览器(也就是)功能,通过开发前端的H5页面满足跨平台需求。
该方案提升开发效率,同时也满足了跨端的需求。但有一个问题就是,前端H5的性能和客户端的性能相差甚远。
weex的发展
于是后来, 业界继续探索可以媲美原生体验app的方案,比如说WEEX 。
WEEX依旧采取前端H5页面进行开发,同时app在终端的运行体验不输 app。即可以保证快速响应需求,又可以保证用户体验。
那么WEEX是如何实现的?
本质来说,WEEX是用客户端 的能力,去做了部分浏览器()的工作。
在2016年2月, 发布了v0.10.0版本,在这个版本里面,集成了v2 版本的Vue。
为啥是Vue 2.x 版本呢?
Vue 2.x加入了 -DOM 和预编译器的设计,使得该框架在运行时能够脱离 HTML 和 CSS 解析,只依赖 ;同时 -DOM 也使得 Vue 2.x 渲染成原生 UI 成为了可能。
weex 原理探究
我们先来看一下 weex 的整体框架。
weex 整体架构
从上图中可以看到weex的大致工作流程:
前端开发可以写熟悉vue语法的单文件,然后打包成出来一份dist —— JS ,然后部署到服务器上
客户端打开某一个页面,通过网络下载JS ,然后在客户端本地执行该JS
客户端提供了JS的执行引擎()用于执行远程加载到JS
JS执行引擎执行JS ,和浏览器的过程类似,JS 的代码被执行,生成VNode 树进行patch,找出最小操作DOM节点的操作,把对DOM节点的操作转变为 DOM API, 调用 进行通信
将渲染指令分发到(、iOS)渲染引擎,由渲染引擎完成最终的页面渲染
看完上述整体流程后,可以大致理解为何WEEX可以达到媲美原生的体验,因为其页面渲染并不是像H5方案一样使用浏览器的渲染能力,而是原生渲染,所以本质上渲染出来的页面就是一个页面。
下面会具体的介绍下面几个过程:
第一步: 生成 JS
JS 是前端同学写好代码后打包出来的dist.
前端同学可以在.vue 的单文件中,写,
Weex
前端开发
前端框架