導讀：随着移動網際網路的迅猛發展，目前市面上「端」的形态多種多樣，iOS、Android 、H5、微信小程式等各種端大行其道，同一個業務需求往往又需要在多端上去實作，針對不同端去編寫多套代碼的成本顯然非常高。雪球大前端團隊将今年在跨端能力建設上的演進和推廣工作整理成系列文章。

本文為第三部分，介紹今年雪球大前端團隊在三端同建構設上相關工作：

RN / H5 同構的方案及效果

樣式元件系統的優勢及實作

同構H5的實作及服務端渲染 SSR

同構的 CI/CD、單元測試及開發測試流程

同構的 D2C 代碼智能生成

一、背景

雪球前端的業務場景除了雪球 App 外，還有重要的一環是微信私域 H5。各需求優先在用戶端 App 内實作後再同步到微信 H5，至少要投入 iOS、安卓、H5 三端的開發資源。在人力資源有限的情況下，經常會出現多需求和多開發崗位互相交叉的錯綜複雜關系，多崗位協同難免會造成效率降低和資源浪費。

那麼有沒有一種技術，能在效率、體驗、成本、通用性上取得最大化的平衡，甚至打破傳統的技術棧劃分，進而實作三端融合同構呢？

放眼業界，各大公司不約而同也在探索跨端融合。Facebook 最早推出 React Native 支援開發雙端，谷歌後來居上推出 Flutter 并不斷疊代，阿裡則以閑魚為代表在推動大前端的融合，位元組&快手都在大力推進自己的跨雙端開發架構，比如 lynx 等。目前市面較成熟的方案是雙端的融合。其中 React Native 是中小型公司較好的選擇，能以較低成本為用戶端提供雙端同構和動态化能力。

但 RN 開發有門檻難上手、代碼繁瑣、多端需單獨适配，并且在雪球的業務場景下，優先用 RN 開發完用戶端功能後，還要再次投入資源開發微信中的 H5 。

帶着上面的問題，雪球大前端 FE 團隊今年着力于三端同構的建設，實作了 RN / H5 同構的落地方案，極大程度上抹平了 Native、RN、H5 的技術割裂。目前三端同構已經在雪球的私募基金、公募基金、雪盈、社群等多個業務的複雜場景下進行了應用實踐。

RN / H5 同構方案最适合以 App 開發為主，并需要把 App 内功能同步到微信 H5 生态的業務場景。對于想實作 App 動态化、提升人效的中小型公司有借鑒意義，也提供了可落地的實操指南。

二、 RN / H5 同構概述

2.1 同構關鍵能力

1.一套代碼三端運作

一套代碼 iOS / Android / H5 三端運作，通過 RN 為用戶端提供動态化能力，并能同構生成微信 H5。三端代碼一緻，告别三端單獨開發或者相容适配。

2.樣式元件系統和同構元件庫

對 styled system 進行了最簡化的雪球定制實作，封裝顔色 token、螢幕适配、日夜間模式等，提升 UI 開發體驗，樣式代碼量大幅降低，試過就再也不想寫 css。封裝雪球同構元件庫snowbox，提供開箱即用的豐富業務元件，提升開發效率并抹平三端差異。

3.改善 RN 開發體驗

将 RN 開發門檻從用戶端降低為 Web 開發，初期可在浏覽器以 Web 開發方式進行業務邏輯開發和接口聯調等，無需啟動模拟器或連接配接真機，中後期也可三端同步開發。

視訊加載中...

2.2 同構的整體方案

通過三端同構元件庫 snowbox 和樣式元件系統 styled system 實作 RN 業務代碼的快速編寫。

用戶端部分：通過 React Native 生成雙端代碼，并為 App 提供動态化能力。同時借助 RN/H5 同構，改善 RN 開發方式，提高開發體驗。

H5 部分：通過 React Native Web 将 RN 代碼編譯為 H5，并實作服務端渲染，将雪球用戶端裡的 RN 功能和體驗完整複刻同步到微信體系。

三、同構的效果展示

結合實際業務場景，從三方面詳細展示同構的效果與優勢，分别是實際業務頁面的同構效果及 H5 的性能分析；采用同構技術棧後，如何改善傳統RN開發方式和開發體驗；最後介紹了同構元件庫的功能和效果。

3.1 業務頁面效果

私募基金商品頁需求是雪球三端同構方案的第一個落地嘗試，針對頁面複雜（二十餘個複雜子產品+6 個二級頁）、工期緊張、技術積累不足等等問題，在需求開發過程中設計并完善了同構方案，引入樣式元件系統并封裝同構元件庫。

同構頁面在 APP 中打開速度媲美原生，同時能實作線上熱更新，開發人效相比于傳統開發提升一倍以上，高效響應業務變化。并且能同步部署 H5，将原本用戶端内才有的豐富功能和優秀體驗複刻到微信生态，同時賦能業務，客戶經理可以很友善在微信内分享傳播，客戶也能在微信中使用 H5 完成跟雪球用戶端内一緻的業務全流程。

在使用 RN/H5 同構開發後的三端一緻性示範視訊如下，包括加載速度、複雜曲線的互動、日夜間主題切換、同構與原生互動、二級頁效果等。

視訊加載中...

同構 H5 的性能

用 React Native 寫 Web 會不會像 Flutter 一樣無法在生産使用呢？

同裝置同網絡環境下同構 H5 頁面和純 H5 頁面的技術名額對比：(測試采用 m1,橫向滑動展示 js 資源加載情況)

項目技術棧lighthouse首次加載 js總 js元件庫頁RN 同構 SSR96205k205k私募商品頁RN 同構 SSR80270k270k私募持倉頁react ssr82208k208k私募首頁react ssr68227k227k投顧商品頁vue65340k485k基金首頁vue51340k359k基金持倉頁vue74340k369k

可以看到，使用 RN/H5 進行三端同構技術後，頁面性能相比于純 web 開發頁面基本持平，在代碼分割按需加載方面也沒有劣勢，不像 Flutter web 那樣動辄幾 MB 的 js 資源，完全可以在生産環境使用。目前也已在雪球微信服務号、雪球私募、雪球基金及投顧等場景廣泛使用。

3.2 RN開發體驗改善

對于大部分同學來說 RN 開發非常不友善。RN 的樣式開發、元素審查要一直盯着手機螢幕，RN 頁面狀态管理、網絡請求檢視、接口聯調沒有友善的官方工具，甚至沒有最佳實踐，大部分是通過打 log 來判斷，是以開發調試困難、效率低。

在實作 RN / H5 同構後，大幅改善了 RN 的開發體驗。

初期 - 用浏覽器開發 RN

RN / H5 同構後，需求開發初期，完全可以用正常 H5 的開發方式進行邏輯開發、UI 初步編寫和接口聯調。使用 vscode + chrome + snowbox 元件庫，即可快速完成頁面基本邏輯和初步樣式架構，降低開發難度。

樣式初步 - chrome 選擇 iphone se 寬度 375，可直接與設計稿 1：1 對照。

頁面狀态資料檢視 - 可通過 React Devtool 檢視頁面内部 state、hooks、store 資料檢視

接口調試 - 直接在 chrome 網絡調試 tab 進行接口聯調開發，簡單高效。

示範視訊：

視訊加載中...

中後期 - 三端同步開發

頁面基本邏輯&UI 初步開發完成後，可以進入用戶端内同構開發&樣式微調階段。

同時開啟三端開發 - 開啟兩個 terminal 視窗分别運作 RN 調試指令 yarn dev 和 web 調試指令 yarn web-dev。

UI 微調 - 同時連接配接 web android iOS，一次改動三端同步熱更新，進行三端 UI 微調。

示範視訊

視訊加載中...

3.3 三端同構元件庫展示

在業務需求開發中，雪球 FE 團隊聯合設計團隊對雪球 Design 設計元件進行三端同構的工程封裝，并搭建文檔網站，對同構進行了更詳細的介紹。羅列每個元件的參數，為每個元件的增加了線上沙盒示範。

除了在 RN 開發中使用外，同構元件庫也可在純前端 CRA、vite、next 等項目中使用，實作了真正意義上的跨端元件封裝。

https://snowbox.js.org/

視訊展示

視訊加載中...

元件參數文檔

四、樣式元件系統 - styled system

4.1 正常的 RN 和 web 樣式開發有何問題？

前端工程師開發中很大一部分時間是在寫 css 樣式，以往 Web 和 RN 的樣式寫法很繁瑣，比如寫樣式時，要給每個元素想一個有意義的 classname；css js 兩個檔案要來回切換；css 樣式需隔離，css 樣式備援，屬性重複定義，css 體積不斷增大；RN 樣式寫法繁瑣備援，每個元素都要重複設定日夜間主題顔色、布局方式、文字大小、螢幕适配；RN 雙端樣式有細微差異等等。

以往的 RN 業務代碼:

我們對比結合市面多種方案和實踐案例，最終受 styled system 啟發，結合雪球實際需求，設計并實作了定制化的樣式元件系統。封裝螢幕适配、日夜主題适配等通用樣式邏輯，将相容三端差異的代碼整合到樣式元件中。

雪球樣式元件系統具備以下優勢：

程式設計思路順暢，無需絞盡腦汁給樣式起名，無需 js css 來回切換，編寫迅速。
代碼精簡，減低 90% 的樣式代碼量，RN 包體積減少，同構 CSS 代碼量逐漸收斂。

自帶主題切換、螢幕适配、樣式隔離、相容三端差異。

4.2 樣式元件的核心實作

我們采用兩個基礎元件來實作這個系統，分别是盒子元件 Box 和文字元件 Txt，并通過 Typescript 進行規範和提示。

如下圖例子所示，分别将盒模型中邊距、顔色、大小、定位等屬性定義成屬性和Token，用代碼化的語言，将元件的每一部分屬性進行描述，也就是最友善的聲明式 UI。

解析流程：

Box

盒子元件，相當于 web 的 div 和 RN 裡的 View 。實作盒模型，定位，樣式屬性簡寫，顔色系統，主題切換，螢幕大小自适應等功能。

盒模型相關：m: margin; p:padding; br: border; flex: flex
定位相關：l:left; r: right; t: top; b: button; ab: absolute; c: center
顔色相關：cl: color; bg: background; 雪球顔色 token

Txt

文字元件，支援字号、字重、顔色、雪球常用 DIN 字型等，封裝行内占位等。

文字屬性：f: font size fw: font weight lh: line hight cl: color ls: letter spacing DIN：din 字型

顔色 token

與每個樣式單獨寫顔色色值不同，規範的設計系統，要有一套顔色系統的，将 UI 顔色和規範進行收斂控制，實作多主題切換，并用語義化的描述。比如雪球設計規範中，T010是指一級文字顔色，B010指一級背景顔色，并且同時包含日夜間主題的對應的顔色色号。

樣式元件系統對該顔色進行封裝，每種顔色值直接轉變為一個前端變量，将前端程式設計語言與設計語言統一，使元件和設計系統可以被快速實作。比如直接寫 cl="T010"即可。樣式元件系統會自動根據使用者主題渲染為不同的顔色。

通過采用 Typescript 對兩個元件 types 規範定義，包含每個 props 值的類型和枚舉值，實作書寫的提示和規範性。并進一步實作 Design Token。

螢幕适配

螢幕适配我們采用以 iphone8 375 寬度為标準，按寬度進行比例縮放。樣式元件系統，所有的尺寸樣式自帶螢幕适配，無需給每個樣式寫螢幕适配代碼。三端的螢幕方式有些差異，後文會詳細介紹實作方式。

抹平三端差異

由于業務代碼會在三端使用，部分屬性在不同用戶端會出現差異。比如 RN 沒有行内元素的概念，在用戶端内較難實作行内的 Tag; 比如字重 500 在安卓系統中不會生效；比如 DIN 字型，安卓用戶端裡需要使用 DIN-medium與iOS不同等等。

以往遇到這種情況，需要單獨做相容，每個元素都要寫一遍。采用樣式元件系統後，将相容代碼進行封裝，業務代碼不用關心細微差異，降低代碼量。

五、同構 H5 的實作

本節着重介紹同構 H5 的具體實作方案，先後介紹了同構 H5 關鍵庫：React Native Web及其先進理念；如何對已有 RN 項目進行改造；同構項目的常見相容處理方式，實作同構和代碼共存；如何通過服務端渲染提高H5性能，以及如何處理服務渲染後的螢幕适配等等問題。

5.1 React Native Web 介紹

React Native Web 由前 Twitter 前端主管 Necolas 開發，并使用該技術方案在 2017 年重構了 Twitter 網頁 (Twitter Web App) 并沿用至今。

React Native Web 在國内知名度不高，但是放眼世界 Twitter Web、Expo、NativeBase、React Native 官網等衆多項目全部使用的 React Native Web 能力。

雖然是 5 年前就開始的項目，如今看依舊有非常前瞻性的理念，因為 Necolas 也是 normalize.css 庫的作者，對 CSS 和前端工程化有獨到的了解，其在 React Native Web 中開創性實作了諸如原子化 CSS、css-in-js、前端元件化、Web 的容器化封裝、手勢系統等等。具體可看參考文獻中的第一個視訊。

在 div 上能看到大量"r-"開頭的單個 css 規則，是否令你聯想起如今火熱的 Tailwind css、UnoCSS？

原子化 CSS 處理

以往前端項目中，随着樣式的增多，CSS 逐漸備援、重複打包、難以維護。現在很多庫的前瞻性原子化 CSS 思路，其實 React Native Web 5 年前已實作。

這種方式在使得 CSS 代碼量不會随着頁面的日益增多而無限擴充，而是會逐漸趨于收斂，并且在服務端渲染後，能做到真正的 CSS 按需加載。

再加上用戶端不支援 CSS 渲染，是以抛棄 CSS 的曆史包袱之後，Web 能跟用戶端樣式代碼一緻，開發才能真正的實作跨端元件封裝，有助于我們實作三端同構的元件系統。

後來 Necolas 加入 Facebook，從事 React 相關開發。近期 Facebook 對 React Native Web 這種原子化 CSS 的處理方式進行封裝，取名 stylex，Facebook 和 Whatsapp 等官網都使用這種 CSS 處理方式重寫。stylex目前還未開源，不過其基本理念來源于 React Native Web ，可見 React Native Web 的前瞻性，再加上 React 是 Facebook 出品，在可預見的未來，這種處理方式可能會成為 React 的預設樣式寫法與解析方法。

随着雪球前端對 React Native Web 的深入了解和使用，我們也積極參與 React Native Web 的開源建設，為 React Native Web 增加多個 feature，核心開發者也展示在了 React Native Web 項目首頁。

5.2 RN 項目的同構改造

同構的 web 架構

我們在已有的 RN 項目裡引入 React Native Web，并選取 Next.js 作為服務端渲染的項目腳手架，同時使用 koa.js 做 node 服務端自定義 server。

Next.js 是 Vercel 明星開發團隊出品的成熟 react 服務端渲染架構，在開發體驗、代碼分割、服務端渲染、優化方面做的很好，開箱即用，是以我們使用 Next.js 來處理 web 的編譯，通過服務端渲染能力解決 React Native Web css-in-js 方案的首屏渲染問題。

為了能複用雪球前端通用的 node 中間件，比如 snb-lib-token 等, 是以服務端采用 Next.js + 自定義 server 的方式（custom-server）

前端代碼由 Next 進行服務端渲染
服務端代碼由自定義 server koa 實作，進而複用雪球node中間件。

同構的路由注冊

雪球 App 裡是為每個 RN 頁面注冊一個 URL 路由，該規則通過json動态下發，用戶端讀取後将 RN 頁面注冊到 URL 路由上，進行比對和跳轉，并且能控制 RN、H5、原生的優先級邏輯。

同構 H5 的路由跟 RN 的路由注冊保持一緻，實作同一個 URL 在用戶端内打開 RN 頁面，在微信中打開 H5。這樣做還有一個優勢，由于保持了 RN / H5 路由一緻，H5 還會為用戶端 RN 頁做兜底，比如 RN 未覆寫到的低版本用戶端或者 RN 包出問題時，點選 URL 會打開對應的同構 H5 頁面做降級。

同構的差異化處理

同構改造還涉及對 RN 和 H5 的差異化處理，總結主要有三種方式：由代碼處理、由 Metro 處理、由 Next.js 處理，分别以三端相容代碼、jsbridge、H5 路由注冊為例介紹。

1. 由代碼處理差異 - 以相容代碼為例

開發需對平台進行邏輯判斷，比如微信分享的 jssdk 在用戶端打包時無需引入，比如端上的邏輯無需在 node 上執行。

Platform.OS 有 "iOS" | "android" | "windows" | "macos" | "web" 5 種，在同構項目中 web 其實還分為兩種，一種是純 web，一種是 node 服務端渲染。是以我們進行封裝，增加了 node 辨別。

// 隻有web才引入weixin-js-sdk

if (OS === 'web') { wx = require('weixin-js-sdk');

}

// 隻有在服務端才進行mobx 的服務端 useStaticRendering 設定

if (OS === 'node') {

useStaticRendering(true);

}

2. 由 Metro 打包工具處理差異 - 以 jsbridge 為例

jsbridge 等功能跟各端有關聯，在用戶端内需調用端内方法，在 web 端需調用 web 的方法。

同構寫法為通過 native.js 字尾區分，由 React Native Metro 打包工具預設提供。

RNBridge
├── index.js # 由前端工具打包的檔案
├── index.native.js # 由 React Native 自帶打包工具(Metro) 打包的檔案

3. 由 Next.js 處理 - 以 H5 路由注冊為例

因為雪球的 RN 是按照路由注冊，與 web 相通，是以同構 H5 實作對應的 URL 路由注冊即可。

得益于 Next.js 的自動注冊路由，服務會根據 pages 目錄結構，生成對應的 url 路由。但是預設 RN 項目的頁面目錄也是 pages，是以next.js 會打包全部 pages 中的頁面，部分沒有經同構處理的頁面會報錯，需要控制隻打包同構的頁面。我們的處理方式是添加自定義辨別 ".web.js"，設定 Next.js 隻處理 "web.js" 字尾的檔案作為入口檔案，實作跟 RN 原生代碼的共存。

module.exports = {
  // 入口隻選web.js字尾的  
pageExtensions: ['web.jsx', 'web.js', 'web.tsx', 'web.ts'],
};

同一目錄下的RN 入口與同構入口：

.
├── index.js
├── index.web.js

index.web.js 中内容也很簡單，使用封裝好的 Wrapper 包裝下 RN 入口檔案即可，裡面有全局的參數、樣式等處理，把Web和node端也當做容器來處理，使 H5 保持跟 RN 一緻。

import { Wrapper } from 'snowbox';
import Page from '.';

export default Wrapper(Page);

5.3 同構的服務端渲染

服務端渲染（SSR），是指由服務側（server side）完成頁面的 DOM 結構拼接和樣式生成，降低頁面渲染的白屏時間。

我們發現複雜頁面同構生成的 H5，在 iphone6 等低端手機上渲染較慢，對同構頁面進行 lighthouse 跑分也證明了這個問題。其中有一部分原因是因為React Native Web 的樣式解析采用的 css-in-js 方案，是以需要在 js 加載完後，動态計算後才能得到，在低端手機上必然會造成白屏問題。

對此我們的優化方案是采用服務端渲染，并修改Web的螢幕适配邏輯，提升同構網頁性能。

采用 RN 同構服務端渲染後的性能提升：(測試采用 m1，将 cpu 性能降低 4 倍)

lighthouse

項目服務端渲染非服務端私募新商品頁8067xueqiu.com/rn9893元件庫展示頁9686

RN 服務端渲染示範

服務端渲染螢幕适配

前端頁面需做移動端适配，根據不同的螢幕寬度進行相應的比例縮放。

在用戶端 React Native 中，我們使用的是 Dimensions.get('window').width 擷取螢幕寬度，并按照比例對每個元素進行尺寸計算，得出适配大小。

但是在 H5 服務端渲染時，服務端的 Dimensions 擷取不到使用者的螢幕寬度，尺寸計算失敗，導緻服務端渲染的 H5 初始樣式展示有問題，頁面渲染會有抖動的現象。

根據前端項目的服務端渲染經驗，我們做了兩部分處理：

使用 rem+vw 布局來做螢幕适配：H5 使用 rem+vw 适配，替代 RN 裡面js的動态計算方案。由于 rem 和 vw 都是相對大小，無需擷取螢幕的實際寬度，是以能實作服務端渲染，并能自動适配不同的螢幕大小。也因為無需 js 動态計算樣式，是以提升了頁面性能。
不支援 rem 的預設 375：對于一些不支援 rem 的地方，比如 svg 的大小，依舊保留預設的計算方案，Dimensions.get('window').width 給的預設值 375，保持元素比例正确。不進行螢幕适配。

服務端渲染改造點還包括「服務端樣式提取」、「OS 封裝」、「Window 封裝」、「Wrapper 通用參數處理」、「全局變量封裝」等，具體可移步元件庫官網了解詳情。

六、同構的 CICD 流程

6.1 持續內建

“持續內建”(CI) 通常指的是持續地将代碼更改內建到代碼的主分支中。具體來說，CI 服務通過自動化測試、建構和釋出過程來幫助使用者頻繁地內建更改。對于基于 pull-request 的工作流，每次都會運作所有測試和 lint 檢查，打包，下發。

雪球三端同構的 CI 由 Gitlab CI 實作，包含 commit 校驗、代碼 lint 校驗、單元測試、RN 打包上傳等等。

而持續部署（ CD ）分為兩部分，分别是端側 RN 釋出和 Web 服務的部署。

端側 RN

采用 Gitlab CI + 自研 mPaaS 實作。所有 feature 分支 PR 合并後自動打 RN 包，由自研 mPaaS 實作 RN 釋出用戶端版本控制、多階段控制、代碼上傳、分包下發、切包等功能。

Web 服務

采用 Drone CI + 自研 Rolling Docker 部署。由 sit、sep、staging、prod 四個特定分支來承載 Web 服務的分環境部署。PR 合并後觸發 Drone CI 的 Docker 鏡像建構，随後通過 Rolling Docker 部署前端 node 服務。

同構的開發、測試、上線整體流程如下圖所示:

6.2 同構的單元測試

CI 流程中的關鍵環節是單元測試，因為涉及到用戶端，是以同構代碼的測試與以往前端測試有所不同，我們對 RN 開源項目的單元測試進行了對比調研。

RN 元件庫使用測試工具對比

元件庫位址工具及類庫react-nativehttps://github.com/facebook/react-nativeJest react-test-rendererReact Native Elementshttps://reactnativeelements.com/docs/testingJest React Native Testing Librarytamaguihttps://github.com/tamagui/tamagui/blob/master/jest.config.jsJestnativebasehttps://docs.nativebase.io/testingJest jest-expo

方案對比

Jest react native 作為 jest preset 配置 + RNTL 庫

使用者多，官網推薦，大多數 RN 庫都使用這套配置來測試

使用 node 環境模拟 react native runtime，是以不能測試 native feature，比如 fireEvent.scroll 可以調用 onScroll，但是不能模拟原生側調用的onMomentumScrollBegin方法

platform.os 預設為 iOS

2.Jest-expo-enzyme 作為 jest preset 配置，即內建了 enzyme（也是 react 測試庫）的 api

可以模拟 web、iOS 和 Android 環境分别運作，platform.os 正确

無法解決 RNTL 庫提到的 native feature 測試不到的問題
jest-expo-enzyme 項目屬于 expo 項目内小分支，對應資料少，enzyme 使用比 rntl 體驗稍差

選用方案

Jest + React Native Testing Library：測試庫（基于 react-test-renderer 和 React Testing Library）

優點

允許測試正常 React Native 程式的大部分邏輯
允許在 Jest 或其他測試運作器支援的任何作業系統上運作測試，比如 CI
使用的資源比完整的運作時模拟器少得多
可以使用 Jest 模拟計時器

代碼覆寫率

jest 內建了代碼覆寫率計算的功能，通過jest --coverage可以獲得代碼覆寫率相關結果，以下是 test case 的示例結果，通常認為 80%以上是一個比較理想的結果，測試率報告可以作為完善用例的參考。

七、展望

7.1 智能生成同構代碼

近幾年來，人工智能技術日益滲透到軟體工程領域，比如微軟 Copilot 基于大模型的代碼自動生成系統。人工智能在設計稿轉代碼方面也有很多研究成果，2017 年的關于圖像轉代碼的 Pix2Code 論文掀起了業内激烈讨論的波瀾，講述如何從設計原型直接生成源代碼。2018 年微軟 AI Lab 開源了草圖轉代碼工具 Sketch2Code，2019 年阿裡釋出 imgcook 在雙 11 大促中自動生成了 79.34% 的前端代碼，京東 Deco、codefun、58 Picasso、DhiWise 等産品相繼出現。随着 D2C 在生産中的廣泛應用，智能生成代碼不再隻是一個線下實驗産品，而是真正産生了價值。

目前 D2C 大部分是應用于 H5，如果能和三端同構結合，将會創造出更高的價值。并且由于同構元件對 UI 進行了高度的抽象，是以也有助于 D2C 代碼智能生成的實作，同構生成三端代碼。

我們對代碼智能生成的開發工作劃分了三個階段，由淺入深，逐漸實作最終的目标。

初期-編譯器：利用 imgcook/DhiWise/Deco/Picasso 等平台對設計稿進行解析，生成描述代碼 DSL，開發編譯器将描述代碼 DSL 編譯為前端代碼。

中期-設計稿解析、可視化編輯器：自行開發設計稿圖層解析服務，開發定制化的頁面可視化編輯器。

後期-智能識别：智能識别設計稿/圖檔，自動分離/組合子產品，合理布局，最終生成代碼。

目前雪球 FE 在相對簡單的背景類頁面生成中，自主研發跑通了全流程，實作了背景類頁面的智能代碼生成。但在複雜的 toC 端設計稿轉代碼中，目前還在初期階段。我們利用 imgcook 等工具對 figma 解析，識别設計稿，通過開發的 DSL 編譯器自動生成的代碼。

左邊為設計稿，右邊為自動生成的 RN/H5 同構頁面，已初見雛形，後續還有很大的改善空間。

生成的代碼示例：

export default function Block_0() {
  return (
    <Box col br={8} w={351} h={202} >
      <Box p="12">
        <Box col ml={16}>
          <Txt f={28} fw="500" c>
            +21.49
          </Txt>
          <Box m={2} >
            <Txt f={12} fw="400">
              今年以來
            </Txt>
          </Box>
        </Box>
        <Txt f={16} fw="500">
          %
        </Txt>
      </Box>
    </Box>
  );
}

7.2 更多端的同構

微信生态除了 H5 之外，小程式也是非常關鍵的一環。目前雪球的小程式還是單獨開發，後續我們計劃适配小程式，把樣式元件系統的 UI 編寫方式引入小程式開發，同時也會向 Taro 、Uni-App 等方案學習交流，進一步實作 iOS、安卓、H5、小程式、PC、VR 等多端同構的願景。

八、小結

軟體工程沒有銀彈，隻有根據具體案例制定相比對的解決方案。RN / H5 三端同構方案是基于實際業務需求，綜合考慮效率、體驗、成本、通用性的，針對雪球現狀定制化的解決方案。此方案最适合以 App 開發為主，并需要把 App 内的功能同步到微信 H5 生态的業務場景。對于想實作 App 動态化、提升人效的中小型公司有借鑒意義，也提供了可落地的實操指南，通過技術改造來顯著提升開發體驗，使技術真正為我們所用，并進一步賦能業務。

展望未來，在豐富同構元件庫、代碼智能生成、多端同構等等方面還有很長的路要走，期待與大家交流和共創。

參考資料

Nicolas Gallagher - Twitter Lite, React Native, and Progressive Web Apps https://youtu.be/tFFn39lLO-U

Theme UI : https://theme-ui.com/

styled-system: https://styled-system.com/

Shopify/Restyle: https://github.com/Shopify/restyle

NativeBase: https://docs.nativebase.io/utility-first

React 18 keynote: https://youtu.be/FZ0cG47msEk

閑魚宗心：這一年，我對終端組織與技術架構的思考：https://mp.weixin.qq.com/s/BGGsuYrlojMfTqfTo71VZg

人機協同時代，AI助力90.4%雙11前端子產品自動生成: https://www.imgcook.com/blog

作者:雪球大前端團隊

來源:微信公衆号:雪球工程師團隊

出處:https://mp.weixin.qq.com/s/3DRsUeZs5Z6TrMVlPrLiuA

雪球跨端架建構設之三端同構篇

一、背景

二、 RN / H5 同構概述

2.1 同構關鍵能力

1.一套代碼三端運作

2.樣式元件系統和同構元件庫

3.改善 RN 開發體驗

2.2 同構的整體方案

三、同構的效果展示

3.1 業務頁面效果

3.2 RN開發體驗改善

初期 - 用浏覽器開發 RN

中後期 - 三端同步開發

3.3 三端同構元件庫展示

四、樣式元件系統 - styled system

4.1 正常的 RN 和 web 樣式開發有何問題？

Box

Txt

顔色 token

螢幕适配

抹平三端差異

五、同構 H5 的實作

5.1 React Native Web 介紹

5.2 RN 項目的同構改造

同構的 web 架構

同構的路由注冊

同構的差異化處理

1. 由代碼處理差異 - 以相容代碼為例

2. 由 Metro 打包工具處理差異 - 以 jsbridge 為例

3. 由 Next.js 處理 - 以 H5 路由注冊為例

5.3 同構的服務端渲染

服務端渲染螢幕适配

六、同構的 CICD 流程

6.1 持續內建

6.2 同構的單元測試

七、展望

7.1 智能生成同構代碼

7.2 更多端的同構

八、小結

參考資料