前言
最近几年小程序的生态越来越完善，各家的流量App也都在搭建自己的小程序生态。 抛开小程序的业务生态，单纯从技术的角度来说，小程序的远程派发和容器化的跨平台的技术实现对本人日常的架构思考和设计有很大的启示作用。
在最近的工作中，我一直思考着一种客户端容器化架构，让Flutter、Web这两种跨平台的技术实现可以运行在像简化的Docker容器中，原生App提供容器的运行时。
- Flutter: 优点是贴近原生的渲染体验和有限的系统能力，缺点是iOS的Skia和Flutter Engine需要通过Framework的方式打包进App(动态库需要签名)，不仅对包体积的影响较大，而且丧失了远程派发的能力
- Web: 成熟多样的标准, 从Cordova、Ionic到RN和Weex这类基于web标准的跨平台技术层出不穷，最后到如今的小程序。
为什么选择实现一个简单的小程序？
- 提供一个轻量级的可远程派发的backup的技术实现
- 现行Web框架的再拓展(可以加强和原生的体验)
涉及的知识（iOS）
- JavaScriptCore(JSVM、JSContext)
- 渲染和逻辑分开的技术架构（WKWebView渲染、MiniProgramJSContext的逻辑执行）
- 对基于WebView的Hybrid框架进行优化(MessageHandler的通信优化)
- 客户端起本地服务提供小程序Runtime服务（本地提供Vue和wx组件的render脚本）
实现效果
小程序效果实现-gif.gif
整体架构设计
渲染和逻辑双线程架构设计
架构设计点：
- WebView（iOS中承载的是WKWebView）负责加载和渲染HTML或者WXML(自定义DSL的模板)。同时本人在这边是通过Vue运行时实现render和数据绑定的，所以Webview这边的JSC这条线程还运行着Vue Runtime 和Vue拓展组件。
- 在每个MiniProgram启动的时候二外提供了一个JSContext，对应一个新的JavaScriptCore虚拟机，用于执行MiniProgram的逻辑js
-
WebView的JSContext，这里简称WJSC，小程序相关的Context，这里简称JSC。这里需要两个通信的Bridge：WJSCBridge负责渲染页面和Native的交互，JSCBridege负责MP运行时和原生的交互和hook生命周期
MiniProgram容器架构设计
网友评论