小程序框架原理綜合分析和 fard 的新思路

halo,你們好,我是 132 ,很久不賤~前端

今天給你們帶來的是一個 fre 轉小程序的新框架,叫 fard,它使用了很是精彩的思路,將 fre 代碼跑到小程序環境裏vue

背景

當下國內前端環境中,幾乎每個框架做者最終都會研究小程序,如 nerv 和 taro,anu 和 nanachireact

加上前陣子某人發微博說出 「hooks 沒法用於別處,想用就得從新實現」 這種膝蓋言論git

我急迫的想要給 fre 一個歸宿,尋找適用於 fre 的小程序方案github

現有方案

在作 fard 以前,我看了幾乎全部的小程序框架,如下:web

編譯型 封裝型
taro wepy
nanachi mpx
mpvue
uniapp
chameleon

以上列舉的只是常見的,還有不少小衆的沒有寫出,小程序框架比小程序還多::>_<::小程序

編譯型

對於編譯型框架,基本上就是 AST 轉譯,寫 react/vue 的語法,編譯出小程序的語法weex

這樣作的好處是理論上無所不能,啥都能轉,甚至使用 parcel 的策略能讓編譯速度很快app

可是致命缺陷是,全程寫的不是真的 react,react 內部的遍歷過程根本沒走,並且還須要制定足夠嚴格的語法約定框架

我認爲,這個方向是走投無路的方向

封裝型

封裝型框架,基本就是對小程序的 API 進行封裝,使其長得像 vue

優勢是可以最大程度的接近原生,缺點是沒有足夠的抽象層,沒法跨端

跨端

瞭解完兩種類型的框架,咱們來探討一下「跨端」

跨端一直是不少人樂此不疲的事情,跨端的關鍵點在於尋找一個【抽象中間層】

  • 好比 taro 等使用 AST 做爲抽象中間層
  • flutter 使用各個端都支持的渲染引擎做爲抽象中間層
  • RN 本身搞了個 bridge,把橋做爲抽象中間層
  • weex 利用 v8 搞了個 runtime 做爲抽象中間層

(以上僅僅是舉例,不要深究他們的原理)

因此,fard 只須要尋找一箇中間層,就完事了

Fard 原理

好吧,通篇,就這段是重點 ::>_<::

首先,fard 是 fre 轉小程序的框架,fre 是 react like 框架,它包含了整個 reconciler

reconciler 全程都是 js 的遍歷行爲,可以跑在任何 js 環境中,小程序也不例外

因此最終 fard 的方案,就和 RN 相似,在小程序端跑 fre reconciler 過程,跑完再經過某個【橋】反饋給小程序視圖

好吧,上圖

如圖,首先,在小程序裏,跑 fre reconciler 的全部邏輯,hooks 就位於這個階段,因此 hooks 全部邏輯,都是在 fre 中跑完的

跑完後就好說了,咱們拿到了一個 vdom (也能夠說 fiber,可是咱們只須要子集 vdom )

拿到這個 vdom 後,就去 setData,附加給 Page

好的,到這裏,能夠說全程 js 邏輯,該拿到的都拿到了,就差怎麼反饋給視圖了

小程序自身也是 vdom 機制的,若是說它默認提供 vdom 的接口的話,咱們直接將 vdom 附加過去便可

可是並無,小程序開放的惟一的修改視圖的方法就是 template

因此咱們須要根據 vdom 改造 template,使其成爲橋樑

這個也很是簡單,好比 vdom 長這個樣子:

let vdom = {
    name:'@2',
    type:'view',
    children:[
        {
            name:'@1',
            type:'text'
        }
    ]
}
複製代碼

咱們徹底能夠經過 template 模擬出來

<template is="@2">
    <view>
        <block wx:for="{{props.children}}" wx:key="">
            <template is="{{item.name}}"></template>
      </block>
    </view>
</template>

<template is="@1">
    <text></text>
</template>

複製代碼

咱們能夠經過 template 模擬出整個 vdom,很好,bridge 就這麼搞定了

其實到這裏,fard 就搞定了

剩下的就是,增長更多的 case,封裝更多的通用 API,提升性能了

綜合分析

咱們看到 fard 是相似 RN 的原理,咱們高度抽象 fre 的 reconciler 層和小程序的 template bridge,使得整個設計很是的簡單卻精彩

並且它可以完美的支持 jsx 和 hooks API,不存在任何約定任何限制任何規範

畢竟,這纔是 jsx 真正的意義

一樣的,hooks API 自出現以來,關於它內部的黑魔法也一直使人津津樂道,我用實際行動證實,hooks API 徹底能夠用到任何端,也包括 webgl

前提是要有設計精巧的抽象中間層

總結

最終,放上 fre 和 fard 的地址,有興趣的能夠看看:

github.com/132yse/fard

github.com/132yse/fre

相關文章
相關標籤/搜索