用WEB技术栈开发NATIVE应用(二):WEEX 前端SDK原理详解

桂林seo / 随笔杂谈 / 时间:2018-03-02 19:33

摘要: WEEX依旧采取传统的web开发技术栈进行开发,同时app在终端的运行体验不输native app。其同时解决了开发效率、发版速度以及用户体验三个核心问题。那么WEEX是如何实现的?目前WEEX已经完全开源,并捐给Apache基金会,我们可以通过分析其源码来一探究竟。

传统的移动端开发,一个完整的业务需要维护三份终端代码:Android、iOS、H5,这带来了极大的开发成本以及维护成本。尤其是对处于业务初创期需要快速试错的业务以及需要支持定期运营活动的业务。所以业界也一直在探索跨平台方案,旨在通过一套代码完成各个终端的业务逻辑。相关方案经过不断演化,从早期的H5、Hybrid到如今的Cloud Native(云原生),在开发效率和用户体验上都在一点点逼近最初的设想。

早期H5和Hybrid方案的核心是利用终端的内置浏览器(webview)功能,通过开发web应用满足跨平台需求。该方案可以解决跨平台问题,同时可以提升发版效率。但其最大的弊端在于用户体验相较于native开发的app存在较大差距,经常出现页面卡顿,加载慢等问题。

于是后来业界开始探索依旧利用web技术栈开发出媲美原生体验app的方案,于是以WEEX为代表云原生开发框架开始出现。所谓云原生(Cloud Native)指可以通过云端快速发布(与远程web应用发布流程类似),同时还可以达到媲美原生App体验的方案。WEEX依旧采取传统的web开发技术栈进行开发,同时app在终端的运行体验不输native app。其同时解决了开发效率、发版速度以及用户体验三个核心问题。那么WEEX是如何实现的?目前WEEX已经完全开源,并捐给Apache基金会,我们可以通过分析其源码来一探究竟。

WEEX框架主要分为两部分:

1.前端Java框架

2.Native SDK

在上一篇博客中,我们介绍了Native SDK的原理,本文主要介绍其前端Java框架原理。

1 整体架构

首先还是再来看下WEEX开发的整体架构:

可以看到在JS-Native Bridge将渲染指令发送给Android或者iOS渲染引擎之前,我们的业务代码运行在JSCore/v8的执行引擎之中,而在该执行引擎之中除了执行业务JSBundle,还运行着JS Framework,JS Framework不仅提供了jsbundle必要的运行时环境,同时还提供了与native通信的接口。

而这个JS Framework就是我们今天介绍的重点。

这是前端框架的主要架构:

FRONTEND FRAMEWORK/DSL:这是WEEX的开发框架,目前WEEX主要是使用Vue.js进行开发

WEEX-VUE-LOADER:前端编译器,将vue文件编译成es5代码

WEEX-VUE-FRAMWORK:WEEX核心框架,主要负责将virtual dom转换成weex的native dom api

WEEX-RUNTIME:负责与native渲染引擎对接,将native dom api转换成对应平台(Android、iOS)的platform api,然后传递给native渲染引擎,由后者负责渲染工作。

2 Vue.js

首先来看下前端开发框架Vue.js,Vue.js目前与React 、 Angular构成了三大最流行的前端开发框架,Vue.js具有组件化、virtual dom以及MVVM三大特性,还学习React的Redux,引入了状态管理模块Vuex。同时相比起React主要基于JSX,Vue.js的开发模式更加清晰,简单,上手速度更快。.vue 文件通常可以分为三部分: 、


桂林SEO半杯酒博客文章,转载请注明原文网址摘自 http://www.mna5.com/suibizatan/739.html,谢谢配合!

微信扫一扫,关注我们
1
3