当前位置: 首页 > >

微信小程序开发技术

发布时间:

技术方案


一般来说,实图层渲染界面的技术栈有这么一些:


客户端原生或编译到原生的:Flutter / iOS / Android
用纯 Web 的:React / Vue / Angular, PWA / MPA, SPA
以及用原生与 Web 二者结合,用桥接的方式通信的混合技术


优缺点:原生的技术需要和微信客户端一起编译发布版本,显然不适合快读迭代;纯web最灵活,但是也会有性能问题,和安全问题。


小程序视图层
WXML(WeiXin Markup Language)


支持数据绑定


支持逻辑算术、运算


支持模板、引用


支持添加事件


WXML先被编译成JS文件,引入数据后会初始完成虚拟DOM,最终把虚拟DOM构建成DOM树,在WebView中渲染。
WXSS(WeiXin Style Sheets)


支持大部分CSS特性


添加尺寸单位rpx,可根据屏幕宽度自适应


使用@import语句可以导入外联样式表


不支持多层选择器,避免被组件内结构破坏


WXSS被编译成JS运行。常用选择器、组件,略过。


小程序的组件基于Web Component标准,使用Polymer框架实现Web Component。Polymer框架是Google提出的,但在使用过程中发现其性能较低,所以微信自研了一套。


Native组件层在WebView层之上。


小程序逻辑层


逻辑层讲数据进行处理后发送给视图层,同时接受视图层的事件反馈。


App()小程序的入口;Page()页面的入口


提供丰富的API,如微信用户数据,扫一扫,支付等微信特有能力


每个页面有独立的作用域,并提供模块化能力


数据绑定,事件分发,生命周期管理,路由管理


运行环境:iOS-JSCore、Android-X5 JS解析器、DevTool-nwjs Chrome内核
逻辑层生命周期


用户从微信打开一个小程序的执行过程:


Native执行一个拉起的操作,告诉App Service层


App Service层执行拉起,同时通知View层进行初始化


接下来要打开页面,通过路由通知App Service层


App Service层创建一个Page,然后通知Web层初始化,同时通知View层渲染并发送初始化数据


App Service层的Page会进行onLoad、onShow事件的执行,渲染完成onReady


当用户进行操作时,就出发一次用户事件,用户事件会通知到App


Service层并在此层执行,然后通知View层进行局部渲染,这样就完成了一次交互。


New View是在Web View初始化完成之后建立的,用于等待用户执行下一个界面时使用,减少Web View创建的花销,用户不需要等待了。App Service层的New Page也是同理。


小程序可以借鉴的优点


提前新建Web View,准备新页面渲染


View层和逻辑层分离,通过数据驱动,不直接操作DOM


使用Virtual DOM,进行局部更新


全部使用https,确保传输过程中安全


前端组件化开发


加入rpx单位,隔离设备尺寸,方便开发
小程序存在的问题


小程序仍然使用WebView渲染,并非原生渲染


需要独立开发,不能再非微信环境运行


开发者不可以扩展新组件


服务端口返回的头无法执行,如Set-Cookie


以来浏览器环境的js库不能使用,因为是JSCore执行的,没有window、document对象


WXSS中无法使用本地(图片、字体等)


WXSS转化成js而不是css,为了兼容rpx


WXSS不支持级联选择器


小程序无法打开页面,无法拉起APP


脱离微信的“小程序”:PWA渐进式应用


优点:


渐进增强:支持的新特性的浏览器获得更好的体验,不支持的保持原来的体验


离线访问:通过Service Workers可以再离线或者网速差的环境下工作


类原生应用:使用app shell model做到原生应用般的体验


可安装:允许用户保留对他们有用的应用在主屏幕上,不需要通过应用商店


容易分享:通过URL可以轻松分享应用


持续更新:受益于service worker的更新进行,应用能够始终保持更新


安全:可通过https来提供服务来防止网络窥探,保证内容不被篡改


可搜索:得益于W3C manifests元数据和service worker的等级,让搜索引擎能够找到wen应用


再次访问:通过消息推送等特性让用户再次访问变得容易



友情链接: