用WEB技术栈开发NATIVE应用:WEEX SDK原理详解
摘要: WEEX依旧采取传统的web开发技术栈进行开发,同时app在终端的运行体验不输native app。其同时解决了开发效率、发版速度以及用户体验三个核心问题。那么WEEX是如何实现的?目前WEEX已经完全开源,并捐给Apache基金会,我们可以通过分析其源码来一探究竟。
点此查看原文:https://yq.aliyun.com/articles/376633?spm=a2c41.11181499.0.0
作者:阿里-移动云-大前端团队
传统的移动端开发,一个完整的业务需要维护三份终端代码: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框架主要分为两部分:
前端JavaScript框架
Native SDK
本文主要探讨Native SDK的核心原理,其前端JavaScript框架会在后续的文章中进行介绍。
1 整体架构
首先来看下WEEX开发的整体架构:
从上图中可以看到weex的大致工作流程:
研发人员利用web技术栈开发weex file,打包成JS Bundle,然后部署到服务器上
终端通过网络获取JS Bundle,然后在本地执行该JS Bundle
终端上提供了JS的执行引擎(JSCore)用于执行远程加载到JS Bundle
JS执行引擎执行JS Bundle,并将相关渲染指令以及其他需要利用native能力的指令通过JS-Native Bridge透出
JS-Native Bridge将渲染指令分发到native(Andorid、iOS)渲染引擎,由native渲染引擎完成最终的页面渲染
看完上述整体架构后,可以大致理解为何WEEX可以达到媲美原生的体验,因为其页面渲染并不是像H5方案一样接入浏览器的渲染能力,而是原生渲染,所以本质上渲染出来的页面就是一个native页面。
接下来我们再来将端上的模块进行详细的拆分:
如上图所示,WEEX NATIVE SDK大致可以分为如下几个层级:
JS执行层:
JS执行引擎:JSCore,解释并执行JS Bundle
main.js:提供WEEX runtime,SDK初始化,JS Core会首先加载main.js,为js bundle提供weex runtime
Bridge层:提供JS和Native的双向通信能力
Dom层:维护页面Dom结构
Render层:完成页面渲染
native组件库:本地UI组件库,每一个组件对应一个html标签,所以当我们在weex开发过程中使用到的各种标签:div、text、image等等,最终都被转化成为了一个native的控件
module manager、module库:功能模块管理层
WXSDKManger、WXSDKEngine:SDK全局环境维护
WXSDKInstance:weex 实例,一个js bundle对应一个weex实例
2 WEEX SDK初始化
有了上述大致架构和功能划分后,我们以一个实际的例子来分析WEEX NATIVE SDK的运行逻辑。首先来看下WEEX SDK在初始化阶段都做了哪些准备工作。
这里以Andorid代码为例进行分析:WEEX的初始化通常放在Application中,其初简化的初始化逻辑入如下:
public class WXApplication extends Application {@Overridepublic void onCreate() {super.onCreate();initWeex();......}private void initWeex() {// 自定义相关配置InitConfig config=new InitConfig.Builder().setImgAdapter(new ImageAdapter()) // 自定义图片适配器.build();WXSDKEngine.initialize(this,config);// register moduletry {WXSDKEngine.registerModule("testmodule", TestModule.class); // 注册自定义模块WXSDKEngine.registerModule("event", WXEventModule.class);WXSDKEngine.registerComponent("richtext", RichText.class); // 注册自定义UI组件......} catch (WXException e) {e.printStackTrace();}}
}
从代码中可以看到,weex的初始化比较简单,主要完成两件事:
完成初始化配置:比如指定相关适配器,比如图片请求适配器
注册自定义的UI组件和功能模块
剩下的事情都交给WEEX SDK来完成了,那么接下来就来看下WEEX SDK都做了些什么?
具体代码在WXSDKEngine.doInitInternal:
private static void doInitInternal(final Application application,final InitConfig config){WXEnvironment.sApplication = application;WXEnvironment.JsFrameworkInit = false;WXBridgeManager.getInstance().post(new Runnable() {@Overridepublic void run() {long start = System.currentTimeMillis();WXSDKManager sm = WXSDKManager.getInstance();sm.onSDKEngineInitialize();if(config != null ) {sm.setInitConfig(config);if(config.getDebugAdapter()!=null){config.getDebugAdapter().initDebug(application);}}WXSoInstallMgrSdk.init(application,sm.getIWXSoLoaderAdapter(),sm.getWXStatisticsListener());boolean isSoInitSuccess = WXSoInstallMgrSdk.initSo(V8_SO_NAME, 1, config!=null?config.getUtAdapter():null);if (!isSoInitSuccess) {return;}sm.initScriptsFramework(config!=null?config.getFramework():null);WXEnvironment.sSDKInitExecuteTime = System.currentTimeMillis() - start;WXLogUtils.renderPerformanceLog("SDKInitExecuteTime", WXEnvironment.sSDKInitExecuteTime);}});register();}
这是WEEX SDK的初始化逻辑,其主要做了以下几件事:
初始化WXBridge,同时启动WXBridge线程,待接收指令。WXBridge在Android的实现本质上是一个基于HandlerThread的异步任务处理线程
initSo:加载so文件,即JS执行引擎
initScriptsFramework:加载SDK中的main.js,完成weex runtime的初始化
register:注册SDK自带的UI组件和功能模块
3 页面渲染
WEEX SDK在完成了初始化之后,即可开始渲染页面了。接下来我们以如下这JS代码为例,来介绍页面的渲染逻辑:
JS代码比较简单,逻辑就不介绍了。接下来重点介绍,当终端获取到如上图右侧的js bundle后,如何进行加载、渲染以及后续的相关逻辑执行。
3.1 weex实例创建
实际上当WEEX SDK获取到JS Bundle后,第一时间并不是立马渲染页面,而是先创建WEEX的实例:
这幅时序图中有两个主要逻辑:
创建createInstance:创建一个weex实例,每一个JS bundle对应一个实例,同时每一个实例都有一个instance id。由于所有的js bundle都是放入到同一个JS执行引擎中执行,那么当js执行引擎通过WXBridge将相关渲染指令传出的时候,需要通过instance id才能知道该指定要传递给哪个weex实例
execJs:在创建实例完成后,接下来才是真正将js bundle交给js执行引擎执行
3.2 页面渲染
在实例创建完成后,接下来就是页面渲染了。首先来看下页面渲染的整体流程:
js bundle涉及dom操作的执行都会被weex-vue-framework转化成native dom api, 前端框架vue是基于virtual dom api,而weex的前端框架:weex-vue-framework的核心逻辑就是将vue的virtual-dom转换成Native DOM API
weex终端的执行引擎在执行到Native DOM API后,则会将其转化为Platform API,说白了就是通过WXBridge将Native DOM API以约定的方式转发给native渲染引擎,完成页面渲染
可以看到,在js执行引擎创建好weex实例后,会执行对应的JS Bundle,并在执行到platform api的时候将其通过wxbridge,发送给DomManager。相关代码可参考:com.taobao.weex.bridge.WXBridge
3.2.1 createbody
一个页面的DOM结构最外层是body,所以创建页面一开始就是createbody,整个create body的过程大致可以分为以下几个步骤:
WXBridge将create body指令发送给WXDom模块。WXDom是另一个异步线程,负责维护页面的Dom树
WXDom创建一个新的dom树,同时创建body节点
WXDom将create body指令传递给WXRenderManager渲染引擎,渲染引擎主要完成如下几件事:
初始化一个组件实例,称为mGodComponent
generateComponentTree:由于一个WEEX页面就是由多个UI组件(Component)构成的一棵树,所以渲染引擎会初始化组件树
创建view
3.3.2 addElement
创建完body后,需要在body中添加一个text组件,指向该操作的Native DOM API为addElement,其具体操作为:
WXDomManager:更新本地dom树,添加text节点
WXRenderManager:本地渲染引擎添加相关组件:
从已注册的组件中找到text对应的组件,并实例化
将初始化完成的text组件添加到body所对应的view之上
给text组件设定布局、添加监听事件
加入数据绑定
在此一个带有一个text标签的简单页面才算是渲染完成。值得一提的是,在WXRenderManager创建组件时,需要在本地已注册的组件中需要标签对应的组件,此处标签对应的组件为com.taobao.weex.ui.component.WXText,其本质上是一个TextView。从这里可以发现,其实我们在JS Bundle中指定的各种标签,其实都最终被转化为了一个native的控件。这也就是为什么用WEEX开发出来的app,本质上还是一个Native App。
其他的对应关系还有:
div 对应WXDiv
image 对应WXImage
list对应WXListComponent
a对应WXA
……
4 总结
通过前文的介绍,相信大家对WEEX有了一个初步的系统认识。简单来说,WEEX放弃了传统的Webview,而是搭建了一个native化的浏览器,因为用native的方式实现了一个浏览器的大部分核心组成成分:
JS 执行引擎
渲染引擎
DOM树管理
网络请求,持久层存储等等能力
…
另外为了保证整个SDK的运行效率,SDK维护了三个线程:
bridge线程:完成js到native之间的通信
dom线程:完成dom结构的构建
渲染线程:完成UI渲染,也就是UI线程
以上就是WEEX SDK的大致框架和核心逻辑,篇幅有限,无法面面俱到,只是希望通过该文想大家展示WEEX基于WEB技术栈开发native app的原理。文章内容如有偏颇,欢迎大家指正。
用WEB技术栈开发NATIVE应用:WEEX SDK原理详解相关推荐
- 用WEB技术栈开发NATIVE应用(二):WEEX 前端SDK原理详解
摘要: WEEX依旧采取传统的web开发技术栈进行开发,同时app在终端的运行体验不输native app.其同时解决了开发效率.发版速度以及用户体验三个核心问题.那么WEEX是如何实现的?目前WEE ...
- 简易的web全栈开发——服务器部分
简易的web全栈开发--服务器部分 java sdk的安装 nginx的安装 mysql的安装 node的安装 连接数据库 第一步,买一个云服务器,过程略,买的是个2核4G的轻量应用服务器,预装的是c ...
- 【融职教育】Web全栈开发就业班核心优势
IT技能培训行业现在是一片红海,在红海中求生存和发展就要具有一定的特色和竞争优势.本质上都是为学员提供更好的服务,提高教学品质,让学员可以学会技术,掌握足够工作技能,具有向企业交付的能力,让学员不仅可 ...
- Web全栈开发基础(小白入门版本)
博客传送门 近几个月认真写了写Web全栈代码,有点小收获这里分享一下.我还做了个PPT,资源路径 欢迎拍砖指点! Web全栈开发是一个听起来很虎的名词.本文从技术层面解释全栈开发,能帮助没有全栈概念, ...
- web全栈开发项目搭建整体思路和学习路线
web全栈开发 全栈开发技术介绍: 全栈技术指可以完整整个项目搭建的有效集合. 包括:网站的设计,web前端开发,web后端开发,数据库设计,接口和组件,移动端开发,产品设计,系统架构,产品的理念和用 ...
- 苏州木渎计算机课程培训,苏州木渎H5/web全栈开发培训
课程名称:H5/web全栈开发 课程类型:网页设计 班型:全日制/周末班/晚班 适用校区:全校区 课程详情: 由于网络的发展以及人们使用网络的频繁性,企业需要通过网页呈现产品.服务.理念.文化,或向大 ...
- 【哈士奇赠书活动 - 18期】-〖Flask Web全栈开发实战〗
文章目录 ⭐️ 赠书活动 - <Flask Web全栈开发实战> ⭐️ 编辑推荐 ⭐️ 内容提要 ⭐️ 赠书活动 → 获奖名单 ⭐️ 赠书活动 - <Flask Web全栈开发实战& ...
- 什么是全栈工程师,为什么全栈开发用Python,Python web全栈开发到底有多高薪?
我们经常听到全栈工程师这个词语.那么很多小伙伴还是不明所以,什么是全栈工程师?为什么全栈开发用Python?Python web全栈开发到底有多高薪? 一.什么是Python web全栈工程师? 全栈 ...
- web全栈开发工程师的趋势、价值
随着技术的发展.用户量的增加.客户端种类变多,每一个小小的细节都需要优化和考虑.在海量的访问量面前,也许改变一个按钮的位置和颜色就能影响上千万次的用户体验.如今的互联网产品已不是以一己之力就可以完成的 ...
最新文章
- request.getServletPath()和request.getPathInfo()用法
- Android多线程分析之二:Thread的实现
- mfc messagebox 非模态_進博尋寶記:當進博遇見非遺?愛上中國傳統文化--財經-
- 经典C语言程序100例之八七
- IplImage类型解释和举例
- Spark _14_SparkShell的使用
- 大数据--循序渐进的大数据(2)
- java 鼠标拖动矩形_java – 用鼠标拖动创建矩形,而不是绘制
- ios android分享代码,快速插入代码块——iOS Android
- 让你的Android程序更省电
- 工作中的沟通及信息传递
- 2019年京东Java研发岗社招面经(面试经历+真题总结+经验分享)!
- oracle常见等待事件,必看干货 | Oracle 常见的等待事件说明(下)
- C++循环的内存释放问题?
- 2017年12款小型企业的最佳杀毒软件 你知道几个?
- java5 64_java8 64位(官方免费版下载2020)
- 缺少软件测试项目?最好试试这套方法
- 《P2P技术详解》系列文章
- one class classification
- WD蓝盘绿盘黑盘红盘的区别
热门文章
- 修改图片src_【学习园地】企业SRC搭建
- 【学习笔记】数据链路层——轮询访问介质控制(轮询协议、令牌传递协议)
- android 模拟长按菜单键_如何采用PLC梯形图实现单键启动程序
- redis关键字删除_微信公众号文章防删除
- oracle加大内存对大表,在ORACLE里如果遇到特别大的表,可以使用分区的表来改变其应用程序的性能...
- mysql数据库 auto_increment_mysql数据库 auto_increment
- 10亿!北大获最大一笔校友捐赠
- 重磅!华为发布2025年十大趋势
- 德媒看2019年的世界:西方在争吵,中国在崛起,非洲在增长……
- 44年前的一个数学猜想终被破解