跨端跨棧連載 1/7：RN 開發 8 個 APP

前端早早聊大會，前端成長的新起點，與掘金聯合舉辦。

加微信 codingdreamer 進大會專屬跨端跨棧技術羣。

---

第十二屆|前端可視化專場，7-18 直播，10 位講師(螞蟻金服/阿里雲等)，大會報名地址

本文是第九屆 - 在線文檔，前端早早聊第 62 場，來自宋小菜大前端負責人 - 劉芳的分享講稿簡要整理版（完整版含演示請看錄播視頻和 PPT）：

---

你們好，我叫劉芳，是宋小菜大前端的負責人，此次演講的題目是 toB 場景 8 個 APP 的 RN 最佳實踐。

爲何選擇 React Native 技術棧

第一部分的問題是宋小菜如今有 8 款 APP ，爲何咱們選擇了 React Native 技術棧？

公司介紹

首先宋小菜是一家賣菜的公司，他的願景是作開放創新的數字化生鮮產業服務平臺。

公司目前觸及到的業務主要是生鮮領域的整個供應鏈，包括上游和下游。

宋小菜從 2015 年成立至今，已經開發了 8 個獨立 APP，這 8 個 APP 加起來有一兩千的頁面數量，它們服務了下游 3 萬多城市端用戶，上游 1 萬多供應商用戶，還有鏈接上下游的 7000 多司機用戶。當前宋小菜每一年的交易噸位有 30 多萬，這樣一個體量的公司，咱們能夠看一下它主要的業務：

業務介紹

咱們對接的上游用戶主要是蔬菜的供貨商和蔬菜的囤貨商，下游用戶是蔬菜的批發商和中小菜販，中間是物流司機。

那麼一家創業公司爲何有 8 個 APP ？主要是由於 8 個 APP 它的目標用戶是徹底不同的。

上游的蔬菜基地的用戶主要是Daiban，囤貨商還有供應商，這是咱們的外部用戶。他們的核心訴求是：他們的菜能不能賣出去？怎麼賣？多少錢賣？一天能賣多少？

在上游有也有內部用戶，即公司本身的採購團隊。採購團隊關心的是我要採購的商品種類，商品品質，還有我天天須要採購的數量等等。

從上游的蔬菜基地到下游的批發市場，還有咱們的物流團隊，物流團隊關心的是什麼呢？關心的是天天他有沒有東西要送？他須要開什麼樣子的車？從哪裏送到哪裏？什麼時間送？

下游的用戶就是我剛說的蔬菜批發商，包括了二批老闆和中小菜販。這些人他關心的是什麼？他關心的是宋小菜有什麼樣的菜？這些菜有多少錢？質量好很差？服務好很差等等。

服務這些的蔬菜批發商和中小菜販的有咱們的銷售團隊，銷售團隊關心的是天天的他的用戶有多少，他們要什麼樣的菜，菜的價格是多少，銷售團隊天天能賺多少錢，能不能達到咱們的 KPI。

這樣複雜的用戶羣和場景就決定了宋小菜的 APP 針對的目標用戶是很是不同的，用戶的需求也是不同的。只有針對不一樣的用戶需求提供獨立的產品才能知足公司的業務發展。

前端介紹

下面咱們看一下宋小菜如今前端開發資源的狀況。宋小菜整個大前端只有 15 個同窗，這15個同窗對接了 8 個 RN APP，十幾個 H5項目（這些 H5 有分微信端的 H5 和釘釘端的 H5，釘釘端的 H5 面向公司內部用戶，作一些協同的東西。微信端的 H5 面向外部用戶，提供的下單相關的需求）。

除了 RN App 和 H5 以外，咱們還有 6 個小程序，20 多個 PC 端的項目。此外，咱們前端還有本身的多個基建平臺。15 個同窗針對這麼多的端這麼多的項目，咱們怎麼樣去選擇咱們的 APP 的技術棧，咱們以爲適合當前當下資源和場景的纔是最好的！

做爲一個才成立 5 年的公司，它的產品也是在不斷的變化當中的，可能前兩年作的產品，兩年後就徹底換成另外一種打法和業務方式，以前作的產品功能不久就會變化，而咱們的前端開發資源其實又是不多的，目前只有 15 個。因此咱們很是追求開發效率和質量，須要 App 可以快速迭代，快速的幫助業務同窗進行試錯。

盤點一下宋小菜這 15 個同窗的技術棧，咱們發現其實這 15 個同窗最擅長的是 React、Node.js。此外，還有兩三個同窗之前作過 Java、或者安卓、 或者 IOS，具備必定的 App 原生開發能力的。還有一些同窗有 Vue 的開發背景。

基於研發成本、研發效率和用戶體驗的綜合考量，咱們認爲咱們不作混合型的 Hybrid H5 開發而作 RN 開發，一方面是追求 APP 相對比較好的體驗，另一方面，也追求咱們的開發效率。咱們不用原生開發，也不用 Flutter 開發，雖然可能原生開發和 Flutter 的性能和體驗更好，可是若是投入不少的資源到原生和 Flutter ，對咱們這 15 個同窗來講，它不是一個很具備性價比的技術方案。團隊不須要招那麼多的原生工程師，團隊同窗的技術棧也不會割裂，因此讓 React 的同窗既作 RN 又作 H5 和 PC 端，是當下宋小菜前端的一個最佳的方案。

React Native 基礎建設

第二部分主要說下咱們如今 React Native 基礎設施方面的探索。

React Native 基礎建設概覽

首先看一下咱們的 React Native 基礎設施概覽。

這張圖其實不只能夠套用到 RN 技術棧，任何一個技術棧均可以從左邊的幾個層次來考量，最上面的三層分別是代碼規範，工程結構規範和 UI 組件規範。這是任何一個技術棧最核心的東西，咱們有了團隊內部比較好的代碼規範和工程框架，在工程框架之上咱們去建設咱們豐富的組件庫。這裏針對 RN 咱們既有基於 UI 的展現型組件，也有須要原生能力的 Native 的組件。

除了上面的三個層次以外， RN App 還須要建設它的打包和發佈平臺。打包平臺後面會詳細的介紹，咱們團隊自主研發了一個叫作「大伯伯」的打包平臺，它是基於分支/平臺/環境管理的打包平臺。針對 RN 發佈，咱們研發了一個能夠進行原生髮布/熱更新發布/白名單發佈的平臺，這個平臺還能夠對歷史發佈進行管理，咱們內部叫作「大表姐」發佈平臺。

在大伯伯打包和大表姐發佈平臺之上，咱們對接了宋小菜技術部的 DevOps 工做臺，DevOps 工做臺是針對整個宋小菜技術部的，從需求開始階段到 UI 設計、技術研發和產品測試，包括迭代管理、Bug 管理、一鍵發佈等功能，涵蓋了整個的研發流程，咱們前端的打包平臺大伯伯和前端的發佈平臺大表姐，也對接到了 DevOps ，能夠在 DevOps 上進行需求迭代的配置性後，完成 App 的一鍵打包發佈。

除了編碼、打包和發佈外，咱們須要知道產品上了線以後的線上表現是如何的。早早聊以前的分享，也有咱們宋小菜的小哥哥分享了咱們的大浪子監控，我這邊只是提一下咱們 APP 端是如何接入大浪子監控的。有了監控以後，還須要使用監控產生的數據作一些報表型。固然咱們的報表型組件能夠展現任意數據源的數據，不只僅是監控數據，也有好比說銷售團隊的銷售情況，或者用戶情況等。咱們在咱們的 RN APP 上沉澱了通用的報表展示的解決方案。

說了這麼多，我不知道你們對 RN 技術棧有怎樣的瞭解程度，首先就先講一下 React Native 的基礎技術架構。

React Native 技術架構

React Native 從上到下能夠分三層，最上面這一層，做爲前端開發是常常會接觸到的，就是咱們的 JS 層。JS 層包含了官方原生提供的核心 Components 和核心 API，還有針對咱們 RN 佈局的 flex，還有一些社區的三方模塊，在 JS 這一層。上面橙色的主要是咱們作業務開發的一些寫的 RN Components 組件。

中間這一層是關聯 JS 層和原生層很是重要的一層，咱們稱之爲 JS Bridge。這是 JS 層調用原生 API，調用原生組件進行頁面渲染很是重要的一層。安卓端這一層主要是 JavaScriptCore，也有使用 Facebook 自研的 hermes的，在 IOS 端主要是用 JavaScriptCore，咱們 RN 中間層能夠比喻成 JS 和 Native 之間的通信員。

底層就是安卓和 IOS 的原生層，IOS 和安卓原生層是上層 JS 核心 Components 和 API 在底層的封裝，原生層上有一層叫 yoga 層，yoga 層是 Facebook 自研的跨平臺 flex 引擎，用於解析和渲染 flex box 的。

咱們作 RN 開發，若是涉及到原生的特殊需求，好比說咱們最近作的藍牙打印，還有以前作的微信、支付寶原生方法的封裝，這個時候咱們就會接觸到原生層，作一些原生層的封裝。

React Native 腳手架 - Brick

瞭解了 React Native 的技術架構以後，再來看一下咱們的 Brick 框架。

Brick 框架包含了咱們 RN App 的工程腳手架和工程模版，在上圖藍色的圈圈內部白色的圈層就是咱們 Brick 框架所作的事情。它規定了統一基礎的依賴包，包括了 RN、 IOS 和 安卓的一些基礎依賴的版本，好比說咱們如今 RN 用的是 0.59.9 這個版本，那麼對應的安卓和 IOS 也有肯定的基礎版本。

除了基礎依賴包以外，咱們還有腳本工具，腳本工具會作一些命令化的功能，好比說環境切換，熱更新配置，還有代碼規範檢測等等。

除了腳本工具和基礎依賴以外，Brick 框架還封裝了通用的頁面模板，好比宋小菜有統一的登陸和網關，這個流程統一規範化的，咱們就把登陸和網關的東西封裝到工程模板裏面，讓業務開發不用關心登陸和網關的東西，只關注業務的核心流程的代碼實現就能夠了。

針對 RN 的全局狀態管理，咱們約定能夠選用 rematch，這個後面也會大概講一下。

除了這些 Brick 框架自有的東西以外，還有前端跨平臺的工程在 RN App 中的嵌入。好比 RN 更新檢測的 SDK、RN App 埋點的 SDK，以及 RN 側的報表展現插件，後面都會詳細的去介紹一下。

這裏對 RN APP 工程框架 Brick，再來回顧一下剛剛說的幾個點：

1. 咱們在 RN 腳手架裏面統一了基礎的依賴包，並按照必定的規律去升級。升級的時候，也能夠對相關的三方包的依賴版本進行檢測。

2. 腳本工具目前咱們主要作的是環境切換、熱更新配置，本機打包以及處理一些 IOS 證書 PP 文件管理等，以及代碼規範檢測。

3. 組件庫這裏有展現型的基礎組件：包括多套主題，Button、Text、TextInput、Page、Upload 等。還有原生組件，原生組件有不少是按需引用的，好比說微信三方的 wechat 原生組件、支付寶的 Alipay，還有咱們藍牙打印的 bluetooth 等等

4. 除了組件以外，咱們封裝了基礎的工程模板，模版中封裝了路由，咱們是基於 react-navigation@3.+ 的版本，在這個模板之上提供了統一的登陸和網關請求等功能。咱們還提供了路由的定製和登入登出場景的切換，好比說在什麼狀況下能夠去觸發它的登入登出。

5. 還有咱們在 RN 上面會用到全局狀態管理，全局狀態管理咱們如今用的 rematch , 它很是相似於 dva ，可是它是使用 async/await 處理異步請求，對於習慣了 promise 的開發者，rematch 更易於接受和使用。同時咱們還在rematch 之上還使用了它的一些三方插件，好比 loading 和 persist 等。

6. 除了全局狀態管理，還有宋小菜跨平臺的一些組件在 RN 上的接入，好比說內置了的更新檢測和更新功能的組件，埋點上報組件，報表組件等

腳本工具

詳細講一下咱們的宋小菜的腳本工具作了什麼事情。

腳本工具它一方面是由於咱們 APP 開發確定會有多套環境切換，它可使用腳本就很是方便的去切換環境，還能夠去執行咱們的熱更新的一些配置，咱們使用了 fastlane 爲核心的能夠配置打包命令 IOS 證書 PP 文件管理，還有咱們的 IOS APPStore 的一些信息管理

在這個之上，咱們還能夠按期的使用腳本進行整個框架的一個升級。在代碼提交的時候進行代碼檢測，咱們如今的代碼規範主要是使用的是 standard，還有一些其餘的命令，好比說咱們進行 AndroidX 的一個切換等等。

APP 組件庫

這個組件庫包括了基礎的 UI 組件，還有一些功能性的組件，這些功能性的組件有不少是原生性的，提供原生開發能力的，那麼咱們如今 UI 組件大概有 40 多個，在咱們剛剛說過的宋小菜的 8 款 APP 裏面，使用覆蓋率已經達到了 100%，頁面上面的東西基本上都是用組件進行搭建的。

咱們功能型原生組件就包括剛剛說過的微信支付寶，還有 message-box，藍牙，而後還有報表，埋點等使用原生開發能力的組件。

上圖是咱們的 RN 組件文檔，能夠看到它的分類，它就是會有基礎組件數據展現型的、數據錄入型的、時間類的、交互類的、通用頁面的，還有其餘的。下面這張 PPT 大體列舉了一些組件。

講過了咱們的 RN 框架 Brick 和組件庫後，咱們看一下 RN APP 比較重要的打包和發佈的平臺。先看一下咱們大伯伯打包平臺長的是什麼樣子。

大伯伯打包平臺

在打包平臺上對任何一個 App，有該 App 的概述和打包須要的配置操做，那麼打包就只要在上面選擇打包的分支、打包的環境、包的類型（IOS 包或者安卓包）等等配置就行了。

確認配置後點擊「極速打包」，就會等待打包結果，全部成功的包都會生成一個下載用的二維碼，不管是測試仍是開發，它只要掃一下這個二維碼，就能夠去下載咱們已經打好的包，驗證這個包的功能。 這個打包平臺它是用 Node.js 開發的，它的主要功能包括：打包流程的控制 和 安裝包的管理。最近打過的包在上面都會有歷史記錄，須要使用的時候，只要掃一下二維碼就能夠下載使用。

咱們的打包是以 Jenkins 爲核心的一個打包任務管理，它與發佈平臺進行了整合，它造成了前端 APP 打包發佈流程一體化，而且它與公司的 DevOps 平臺也進行了整合，造成了開發流程的一個閉環。

大表姐發佈平臺

上面是咱們的大表姐發佈平臺，發佈平臺有不少功能，我截取了其中的發佈版本列表。這裏記錄了每次發佈的 App 是什麼，發佈的是什麼平臺，什麼分支。每次發佈的版本號，發佈渠道，還有發佈文案等等。

App 的安裝頁面也是提供給對外下載的頁面，該頁面會檢測手機端的平臺是 IOS 端仍是安卓端，而後提供下載包。

咱們的發佈平臺也是使用 Node.js 進行開發的，他在 RN 應用方面有下面這些功能：

1. 提供了熱更新的分發功能，它能夠按照渠道分發，它能夠便於測試，好比說它能夠只分發 IOS 端或者只分發安卓端，在熱更新方面，它是提供的是增量更新，它能夠節省用戶的的網絡資源請求。

2. 除了熱更新發布以外，能夠提供原生安裝包的一個分發功能，實現了按渠道分發，便於測試

3. 同時它提供了一個自動化的版本管理方式，避免開發者在項目中修改版本號。其實咱們剛剛打包的時候，若是咱們打的是正式的包，就能夠選擇這是怎樣的迭代？好比說是大版本更新仍是功能迭代，仍是 hotfix。肯定了以後在發佈的時候就會自動地更新版本號，發佈完成後還會把更新以後的版本回寫到 git 倉庫。發佈時候還有一個強制更新選項，若是選擇是強制更新的話，那麼用戶點開 APP 就會有個強制更新的彈窗，這時候用戶只能去更新才能使用。若是是非強制更新的話，用戶就可選更新了。此外，咱們還有基於渠道和灰度的開關的設置，支持線上進行版本回滾。每一次的 App 版本發佈以後，都會記錄這個版本，若是線上發現了重大問題須要回滾的時候，就會觸發回滾操做，就把這個版本取消掉。

4. 同時咱們也會對須要更新的安裝包進行檢測，只有是經過咱們小菜的發佈平臺分發出去的，才能經過咱們的安裝包檢驗。防止外部安裝包僞造，提升了咱們發佈的安全性。

5. 咱們也有針對每一個版本安裝狀況的統計，好比說咱們 1.0 版本，發佈了 1.1 版本，那麼每一個版本它安裝的用戶是多少呢？咱們能夠實時查看 App 最新版本的安裝狀況

6. 咱們發佈平臺也是集成在公司的 DevOps 系統上面，而後造成了前端流程的一個 CICD 閉環。

後面這個圖會詳細的介紹了一下，咱們這個打包發佈是怎麼樣的一個流程，能夠跟着我從最開始看一下。 最開始的時候是用戶既能夠在 DevOps 上面進行點擊發布，也能夠在咱們的大伯伯平臺上面點擊打包，打包命令其實就是調用了 Jenkins，Jenkins 調用 fastlane 命令進行打包，打包了以後，就會生成對應的包，IOS 包它生成了 ipa 文件，安卓包生成的是 apk 。而後會把打包結果進行一個上傳，並通知咱們的打包平臺（DevOps 或者大伯伯），接着就判斷當前的包是不是發佈包，若是不是發佈包打包流程就結束了。

若是是發佈包的話，發佈平臺就會自動的去生成一個預發佈單，而後預發佈單就會去判斷這個包是對外的 AppStore 包，仍是咱們企業應用的包，若是是對外的 AppStore 的包，就會自動的去把包上傳到 AppStore，並調用 AppStore 的 API，去填寫提交審覈的發佈單，而後就直接生成了審覈單，等待 AppStore 的審覈結果，若是 AppStore 審覈經過了以後，咱們發佈流程就結束了，若是 AppStore 審覈拒絕的話，那麼開發再看看不成功的緣由是什麼。

從這幅圖能夠看到，其實開發人員在作 App 發佈的操做很是簡單，就是最開始綠色的流程。他只要在打包平臺上或者 DevOps 平臺上面，配置好參數點擊發布，後面的全部的流程都是自動化去實現的。

講過了打包和發佈以後，再講一下針對 App 的線上表現，咱們實現的一個全平臺的監控平臺，它叫大浪子監控平臺。

大浪子監控平臺

由於前面已經有咱們宋小菜的開發小哥哥分享過這一塊內容，這裏就簡單看看功能。

第一幅圖就是咱們去監測目前線上 APP 有沒有什麼異常 Issue？每一個 Issue 的等級是什麼？這裏等級的劃分是咱們基於一些算法來算出來的，從 P0 到 P6，其中 P0 級是最嚴重的，那最不重要的是 P6 級的。

每一個 Issue 當前的狀態是什麼？每一個 Issue 的錯誤類型和錯誤信息描述是什麼？這個 Issue 是出如今 JS 端，仍是 Native 端等等。

點擊一下它的最右側的詳情，咱們能夠去看到它具體究竟是什麼樣子的一個問題，下面會有對 issue 的一些詳細的錯誤，好比錯誤棧、最近一段時間內的觸發頻率等。

基於這個 issue 咱們還能夠設置必定的報警規則。

在每一個 Issue 裏面其實咱們還上報了 session 信息，使用這個 session 信息，就能夠追蹤關於這個 session 的整個的事件的一個流程是什麼樣子的？好比說 session 最開始的可能就是用戶打開了 App，接着就進入了某個頁面，請求了哪些接口，而後他作什麼樣動做，而後又一個路由切換，又是網絡請求等。同時在這個 session 裏面咱們還知道這個用戶的設備型號和用戶信息等。

最後這幅圖是說咱們能夠針對 issue 會制定預警規則，使用預警規則在一段時間以內去觀察這個 Issue 有沒有命中這個預警規則。由於以前有咱們的開發者已經講過大浪子的東西了，我這裏只是大概的羅列了一下它的功能。

而後監控平臺它是一個多平臺的埋點監控，咱們 RN 只是它其中的端，針對 RN 咱們在最開始的圖上面，咱們也寫了咱們在 RN 上面有一個監控的 SDK，這個 SDK 實際上是能夠捕獲咱們原生端和 JS 端的錯誤，而後進行上報的，並且在大浪子上面咱們能夠對上報的錯誤進行管理和定責，也能夠去追蹤它錯誤具體發生的問題是什麼，它是如何被觸發的，而且對這個錯誤咱們能夠進行必定的報警，一旦認爲咱們這個錯誤已經被解決了，咱們能夠制定必定的報警規則，而後多長時間去檢測一次他這個錯誤有沒有再次被觸發這樣子一個報警。而後講過了監控以外，咱們還有另一個針對APP端很重要的一個平臺，就是咱們的數據報表，先看一下咱們移動端的數據報表是怎麼作的。

數據報表

咱們有一個叫大盤子的一個平臺，這個平臺主要是公司的 BI 和數倉同窗使用的。在這上面，他能夠選擇數倉裏的某一個數據表，而後指定他這個報表的 X 軸的維度是什麼，Y 軸的指標是什麼。

咱們在左側能夠對這個表的展示進行定義，好比說咱們用的是柱狀圖，仍是波線圖，或者是地圖之類的。定義了以後，還有比較詳細的 X 軸和 Y 軸的字段定義，經過這些配置化的定義以後，就能夠生成咱們在 APP 上面能夠看到的數據報表。咱們能夠作不少看板，每個看板裏面能夠是一個地圖，也能夠是一個混合了表格和各類的柱狀圖線圖的複雜報表，這些看板就能夠在移動端使用。 這張圖大概的講了一下咱們報表的東西是怎麼樣實現的。

前面的數據準備工做是公司的數倉的人去作的一些工做，他們把業務數據清洗到數據倉庫裏面，數據進入數據倉庫以後，就能夠在咱們剛剛的平臺上進行 PC 端的拖拽製圖，圖作好生成看板，這些看板最終能夠進行多端展示。由於咱們後面作數據報表的小哥哥也會分享這裏可視化的東西，因此我就再也不贅述了。

好了，而後最後咱們在回顧一下咱們 RN 方面的基礎建設：

咱們從新回顧一下：左側的上面三層是代碼規範，工程規範，組件規範，在咱們宋小菜主要是使用了 Brick 框架和 CUI 組件，Native 組件進行實現。這三層咱們主要的目的就是實現 RN 開發框架、開發規範和組件庫，最終用來提升 RN 的研發效率。

中間的兩層是打包和發佈，咱們在宋小菜其實有三個平臺：技術部公用的 DevOps，咱們前端的大伯伯打包平臺和大表姐發佈平臺。這兩層所作的目的就是提供一站式的打包和發佈。它能夠節省咱們的 APP 端研發效率，而且保證它的流程規範。

最後下面兩層就是咱們作的進一步的建設性的東西，第一點是埋點監控和 Bug 預警，它的做用是跟蹤了線上缺陷，而且能夠監控用戶行爲。最後一點就是咱們的數據報表，在咱們宋小菜它包含了大表哥報表，和大盤子圖表。

這裏整個的技術部分就介紹完了，最後咱們來展望一下將來。

展望將來

咱們目前在 RN 方面的持續建設，我大體分了這樣幾點

1. 最基礎的仍是組件，咱們其實仍是會繼續的去基於咱們 UI 組件和 Native 組件作一些基於業務場景的組件。其實業務場景的組件再往上可能就是一些模板性的東西，好比說是營銷類的、採購類的場景組件。而後咱們還會持續的擴充咱們的硬件能力，利用咱們的原生開發的能力，繼續的擴充咱們的 Native 端的硬件能力。

2. 在組件之上，會對咱們的 Brick 框架進行框架升級的自動化，由於咱們如今的框架升級仍是偏人工的，後面咱們能夠把這個框架升級作成自動化的，好比用一個腳本就去進行一個整個 APP 端的一個框架升級。再日後可能能夠支持業務分包，好比說在一個 APP 裏面，根據業務功能不一樣達成多個 JS bundle 包，有了這個功能就能夠進行分包發佈，最後再考慮是否是能夠整合現有應用減小應用數量。

3. 第三點就是持續集成，持續集成包括咱們 APP 能夠作一些自動化測試，其實咱們已經有一些核心流程的自動化測試和單元測試，後面咱們能夠看看作成平臺性的測試。打包腳本的配置化，就是把 App 的打包腳本變成可配置的，存在數據庫裏面，隨存隨用。最後還能夠嘗試作功能性的 A/B Test，由於咱們如今已經有灰度發佈了，後面可能會作一些功能性的，好比說某些用戶他使用的是 A 功能，另外一部分用戶使用的多是 B 功能這樣子。

4. 最後關於多端融合方面，由於小菜端很是多，有 RN、小程序、H五、PC 等，咱們可能會繼續發揮 RN 快速迭代更新的優點，而後去探索一下和其餘端型態的一些融合方案。

我今天的分享就到這裏，下面是個人我的的二維碼，一是釘釘的二維碼，一個是微信的二維碼，有興趣的同窗掃一掃加好友，後面進行線下交流。

---

本文使用 mdnice 排版