WebView与native:
WebView:android中的一个重要控件,用来展示一个web页面。使用webkit引擎,4.4版本之后,直接使用Chrome作为内置网页浏览器。(理解为浏览器上浏览H5页面即可)
native:理解为我们android/ios上的App
WebView的体验:
WebView的性能,给人最直观的莫过于:打开速度比native慢。
一个webview的打开会经过以下阶段(无反馈,白屏,loading,展现)
小程序的css样式跟普通web一模一样,但是体验却比webView要好很多,为什么?
界面渲染机制:
目前,页面渲染的方式主要有三种:
1. Web 渲染。
2. Native 原生渲染。
3. Web 与 Native 两者掺杂,也即我们常说的 Hybrid 渲染。
小程序最终的呈现形式,是 WebView + 原生组件,Hybrid 方式
由于小程序的宿主是微信,如果用纯客户端原生技术来编写小程序 ,那小程序代码需要与微信代码一起编包,跟随微信发版本,这种方式跟开发节奏必然都是不对的。
如果用纯 Web 技术来渲染小程序,在一些有复杂交互的页面上可能会面临一些性能问题。这是因为在 Web 技术中,UI渲染跟 JavaScript 的脚本执行都在一个单线程中执行,这就容易导致一些逻辑任务抢占UI渲染的资源。
因此小程序选择了 Hybrid 的渲染方式,可以用一种近似 Web 的方式来开发,并且还可以实现在线更新代码。同时,引入原生组件有以下好处:
扩展 Web 的能力。比如像输入框组件(input, textarea)有更好地控制键盘的能力
体验更好,同时也减轻 WebView 的渲染工作
绕过 setData、数据通信和重渲染流程,使渲染性能更好
双线程机制:
小程序是双线程设计,即视图渲染与业务逻辑分别在运行在不同的线程中。这个设计主要是解决传统web技术中的一个痛点:
传统的web页面开发渲染线程和脚本线程是互斥的,长时间的脚本运行可能会导致页面失去响应或者白屏,体验糟糕。
小程序为了更好体验,将页面的渲染线程和脚本线程分开设计在不同线程中执行,具体实现:
1.视图view层在webview中渲染,一个页面对应一个webview
2.业务逻辑Appservice层运行在同一个JSCore线程中,具体ios是JavaScriptCore,android是X5 JSCore,开发者工具是webview中;
这样解决了长时间的脚本阻塞页面渲染的情况,但是也带来一些新的问题:
1. 天生的延迟,线程间要通信(双线程通过native通信)
2. 业务逻辑层因为运行在JSCore中无法访问DOM和BOM的api;(管控和安全,阻止开发者使用一些浏览器提供的,诸如跳转页面、操作 DOM、动态执行脚本的开放性接口。)
双线程通信:
逻辑层和渲染层的通信会由 Native (微信客户端)做中转,逻辑层发送网络请求也经由 Native 转发。
于是我们也就可以把 DOM 的更新通过简单的数据通信来实现
1. 在渲染层把 WXML 转化成对应的 JS 对象。
2. 在逻辑层发生数据变更的时候,通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native,再转发到渲染层。
3. 经过对比前后差异,把差异应用在原来的 DOM 树上,更新界面。
我们通过把 WXML 转化为数据,通过 Native 进行转发,来实现逻辑层和渲染层的交互和通信。而这样完整的一套框架,基本上都是通过小程序的基础库来完成的。
小程序的基础库:
小程序的基础库是 JavaScript 编写的,它可以被注入到渲染层和逻辑层运行。主要用于:
1 在渲染层,提供各类组件来组建界面的元素
2 在逻辑层,提供各类 API 来处理各种逻辑
3 处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑
由于小程序的渲染层和逻辑层是两个线程管理,两个线程各自注入了基础库。小程序的基础库不会被打包在某个小程序的代码包里边,它会被提前内置在微信客户端。这样可以:
降低业务小程序的代码包大小
可以单独修复基础库中的 Bug,无需修改到业务小程序的代码包
网友评论