小程序技术方案探讨

2017-9-19

微信小程序上线大半年,大部分技术原理也有文章介绍了,本文尝试从需求出发探讨微信小程序技术方案的来源,以及最近公测的支付宝小程序技术方案的考量。

微信小程序

微信小程序的需求是让第三方开发者可以接入,可以使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求,最简单的实现方案是:让外部开发者开发纯H5应用,在微信的 H5 容器里打开,容器提供微信 native 接口,就行了。在有小程序之前,已经有很多这样的业务接入,像京东购物,钱包里的各种友商大众点评/滴滴出行等,都可以认为是一个“小程序”,内嵌在微信里,能调用微信 native 接口,是不是沿着这种模式下去,把相应的接口开放给第三方,再提供个入口就行了?

实际上这种简单的方案不能满足需求,在产品上微信小程序有另外两个很重要的需求:

  1. 管控。作为一个平台必须对接入的应用有管控能力,必须能尽量精确控制应用的内容和类型,毕竟若出现非法应用平台是要承担责任的,H5 的方式太过自由,开发者可以随时改变整个应用的内容,平台难以检测到这些改变,无法管控。另外H5开发质量参差不齐,平台也无法管控,这对于一向有洁癖的微信来说无法接受。
  2. 体验。作为一个“小程序”需要让体验接近原生,而上述像京东购物这些普通 H5 页面的体验不太行,包括启动速度/页面切换流畅度都有问题,跟原生体验没法比。

所有小程序的技术方案都是为了这两个需求服务。

管控

为了满足管控的需求,技术上微信做了两个事情:小程序框架和分离JS运行环境。

框架/DSL

H5太自由,首先要做的就是限制它的自由,怎样限制?自然是做个框架套住,让开发者只能按框架的规则去开发。那应该使用怎样的框架?

在 PC SNS 时代,Facebook 做开放平台时有类似的场景,为了第三方开发者能在 Facebook 平台上开发,同时又能限制住开发者的权限,Facebook 要求开发者使用自定义的一套 DSL(FBML)去开发,而这个 DSL 能怎么写,最终能转成什么,如何执行,都是平台说了算,同时也可以很方便做代码扫描和审查。

小程序正好能借鉴这样的设计思路,界面不使用 HTML 开发,而是自定义一套 DSL,这样就可以很容易配合审核/代码扫描/域名限制等系列措施去做管控,这就是小程序这一套框架的来源。这套框架通过 wxml 去描述界面,wxss 描述样式,js 去处理逻辑和数据,再通过工具一系列处理把这些转为 HTML/CSS/JS 显示在 webview 上,并处理界面交互和数据更新。

这样用一套框架去限制开发方式,再造一层 DSL,除了管控外还有一个好处,就是容易进行针对性优化,DSL 最终转成什么,最终如何执行渲染都由框架决定,上层不感知,可以做成由 webview 渲染,有条件也可以用类似RN的方案自己实现渲染层。

JS 环境

通过框架限定开发方式后,管控上还有个问题,就是如何限制应用端类JS语言调用dom API?小程序跑在 webview 上,渲染时必然要通过 JS 操作 dom,如果小程序框架和应用 JS 代码都有权限操作 dom,应用可能会通过各种方式在上线后绕过检查,注入 JS 调用 dom 接口去修改页面结构和内容,变成跟审核时不一样的应用。怎样能限制应用的 JS 调用 dom 的权限?微信想了个比较创新的解决方案,就是:JS 运行环境与浏览器分离,运行在单独的 JS 引擎上。

脱离了浏览器,JS 自然没有 dom 的调用权限,任何跟 webview 界面相关的 API 都无法拿到。而小程序框架核心JS运行在webview上,可以自由操作dom,通过小程序框架定义的机制,应用端通过 wxml/wxss 定义固定的渲染样式,JS 端只管数据绑定,数据可以通过 native 桥梁从 JS 引擎传递到 webview,JS端无法做任何渲染相关的操作,可以对渲染的内容有完整的管控权。

独立的 JS 运行环境除了满足管控需求外,也额外带来一些好处和一些坏处,好处在于:

  1. 多个页面可以共享一个 JS 运行环境,数据可以很方便地共享,整个小程序生命周期里共享同一个上下文,更接近 APP 的开发体验。
  2. JS 与页面渲染分离并行执行,不会出现 JS 执行时卡住页面渲染的情况,提升渲染性能。

坏处在于:

  1. 多了数据序列化传输的开销,数据需要从 JS 传到 webview 给视图层渲染,需要序列化为字符串格式再进行传输。
  2. iOS 上 WKWebview 的 JS 引擎比 JavaScriptCore 多了 JIT 优化,执行速度快很多倍,小程序的 JS 运行在 JavaScriptCore 上无法享受到这个优化。

由于管控需求过于刚需,这个方案带来坏处可以接受。

体验

小程序最主要的两个技术点 — 框架和JS运行分离 都是源自管控需求,而体验上的需求就是由各种细致的性能优化组成了,很多文章也分析过,这里简单说下,包括:

  1. 离线包:整个小程序打包下发,不需要打开每个页面都去请求,减少第二次打开时间以及页面切换时间。
  2. 预加载:预加载多一个wkwebview放后台,用户打开小程序时省去初始化wkwebview时间。另外对于一个小程序内的页面切换,得益于框架的设计,可以做到预渲染模板,切换时再填充数据,加快渲染速度。
  3. 缓存:退出小程序后不会立即销毁,会在后台继续跑5分钟,在这期间用户切回小程序时速度快。
  4. 视觉:小程序首次加载通过loading和动画的方式过渡,拒绝白屏,给人一种快的感觉,同时提升了小程序的标识度。

剩下的就是围绕小程序这个平台的周边建设了,像组件,native接口,IDE,后台管理,版本管理,权限控制等基础支持。

支付宝小程序

策略

微信小程序推出时主要面向的场景是线下,希望商家能开发小程序,做像点菜买票这样的即时性应用,提升线下商户体验,支付宝作为线下战场的主要竞争对手自然要跟进。

支付宝要做小程序应该怎么做?可以根据自身的情况,定义另一套技术体系,让第三方接入。但这样的话第三方如果要同时接入微信和支付宝,需要开发两套程序,成本很高,而微信有先发和平台优势,很可能变成只开发微信小程序而放弃接入支付宝小程序,所以最好的做法是降低这里的接入成本,让微信小程序的代码可以复用在支付宝小程序上。所以支付宝小程序对外的框架/API/组件必须是跟微信小程序接近或力求一致,技术上没得选择,所以可以看到支付宝小程序公测版的文档很多跟微信一致。

实现

支付宝小程序框架对外接口是跟微信一样,又因为同样有管控/安全和体验的需求,有些策略是类似的,像独立 JS 环境,离线包,缓存策略等,但在小程序框架的实现上就跟微信完全不一样。小程序框架作为一层屏蔽了实现细节的 DSL 层,最终通过什么技术手段实现都可以是由框架底层自由定制的,这边底层架构基于蚂蚁前端团队多年的积累,最终 web 版小程序是以 react 为基础实现。

React Native

除了对外的跟微信一致的 web 版小程序,内部一直在尝试 React Native 版小程序,渲染层不适用 webview,而是用 RN 去渲染,提升性能和体验,这也是小程序 DSL 层带来的好处,底层渲染引擎可以很方便地替换实现方案,甚至同时存在多套方案。

很多人问为什么不用 weex,按我理解首先是蚂蚁的前端技术栈基于 react,切换成本高,另一个 RN 相对 weex 成熟度高,社区支持度高,并保持着不间断的更新,相对友好。

RN 本身不跨平台,iOS/Android有各自的写法,在 RN 的使用上,业界很多人各自实现了基于 RN 的跨三端或两端的开发方式(例如JDReact),也就是一次开发,能同时支持 RN 在 iOS / Android 两端做原生渲染,也支持 fallback 到 webview 渲染。这里小程序也算是这样一套方案,上层通过自定义 DSL 开发业务,部署时通过工具分别转换成三个平台不同的代码,在三个平台运行。

内部应用

小程序是一套对外的方案,主要用于第三方应用接入,因为上文也说了,框架上很多技术方案都是为了满足对第三方管控和安全方面的需求,而小程序相关的很多体验优化其实用纯 H5 也可以做到,内部业务用 web 版小程序开发并没有带来什么好处,反而增加mg游戏平台官方网站成本。但 RN 版小程序不一样,它有一些优势,包括:

  1. RN 相对 webview 性能优势明显,秒开率高,交互也更流畅。
  2. 相对于单纯使用 RN 开发,使用小程序可以屏蔽平台差异,实现跨平台一次开发。
  3. 小程序有配套的开发环境/IDE/包管理等基础设施支持,无需再重复建设。
  4. 对于业务开发者,小程序不是全新的一套开发方式,在业界可复用,对于框架实现者,RN也是业界流行开源方案,有强大的社区支持。对内对外都避免了另外创建一套只能在内部使用的技术体系,极大降低技术成本。

基于这些原因,在蚂蚁财富这边一些内部原本应该使用 H5 实现的业务,也正尝试更多地使用小程序实现,以提升用户体验,目前部分基于小程序 RN 版开发的业务已在线上稳定运行,后续也会继续尝试把小程序 RN 版持续打造成高性能稳定的三端统一动态化方案。

分类:技术文章
评论

*

*

2017年9月19日 13:32

大学里可以开设一门微信小程序开发的课程,入手简单,实用性强

2017年9月22日 10:17

楼上的建议不错,不过依然不太可能。
强大如诺基亚的塞班的生命周期不过短短10年,现在互联网的发展速度太快,谁也不知道下一个微信何时出现,大学哪怕现在开出课程,也可能四年后无人问津。

[…] 4. 视觉:小程序首次加载通过loading和动画的方式过渡,拒绝白屏,给人一种快的感觉,同时提升了小程序的标识度。另外推荐一篇 cocos 介绍的关于小游戏适配原理http://forum.cocos.com/t/faq/54842相关来源:http://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips.htmlhttp://blog.csdn.net/tsr106/article/details/53052879http://cococave.com/tech/3486/ […]

Baidu
sogou