背景

隨著應用DinamicX(簡稱DX，下同)技術的場景和團隊愈加復雜與廣泛，持續保障DX核心競爭力，支持團隊級別協同開發，助力復雜業務場景的訴求愈發強烈。之前的DX開發基于模板平臺，其核心為基于開源的Monaco編輯器(驅動VScode的開源代碼編輯器)定制開發的前端工程。雖然模板平臺在過去一定程度上滿足了業務開發需要，但其編輯體驗，調試體驗和性能保障等愈發難以滿足開發者要求。

面對上述這些問題，從DX業務研發的需求角度看，我們需要一站式的開發環境，提供從創建，開發，編譯，調試，到發布的全研發周期保障。

全研發周期保障

技術方案選型與設計

基于上述考慮，我們需要的是一個IDE。不同于模板平臺這樣的Editor，IDE提供了完整的開發周期支持。目前業界主流的VSCode，不僅提供了豐富的API用于做擴展，也包含了極其豐富的插件市場，可通過開發VSCode插件的方式來提供DX IDE。

VSCode生態

模板平臺運行于Web環境，受限于瀏覽器， IDE運行于本地環境，擴展豐富容易，環境可控兼容性好；

編輯器可用來做豐富的編輯期支持，其LSP API除部分API(調用棧，快速修復，展示所有引用，動態計算表達式，內聯值計算，類繼承關系，符號表)不支持外，提供了豐富的編輯補全文檔等功能；

相較于純粹的編輯器，IDE則提供了完整的開發周期支持，包括項目系統，代碼歷史上下文理解，調試，同其他功能的結合(如腳手架，編譯等)，應用研發周期管理，平臺相關的內容(如Swift, Kotlin, Faas)等。

雖然VSCode提供了諸多能力及擴展，包括但不限于文件樹及菜單，工程體系，編輯器與語言服務(智能感知)，調試服務，更好的集成構建與開發生命周期管理，平臺工具相關等，但在面向開發者的交互層面，仍存在諸多限制與不便。與此同時，發源于阿里經濟體內部的IDE框架--OpenSumi框架 ( 阿里&螞蟻自研 IDE 研發框架， 已開源 )，既可兼容 100% VS Code API，也擴展了諸多API，提供了豐富的UI自定義支持，大大簡化了自定義插件的交互開發，因而我們采用OpenSumi作為IDE最終的技術選型。

OpenSumi定制擴展

如上，下圖簡要說明了OpenSumi對于自定義視圖的支持。

結合上述的開發目標和技術選型，我們有了如下的設計。

設計大圖

分層設計

總體來看IDE分為以下幾個層次:

1 IDE容器(CLI)

如上我們使用了基于OpenSumi框架的IDE基座，其不僅兼容了VSCode生態，還提供諸多API等擴展，形成了ide-framework。再通過針對經濟體場景下的定制，如登錄態，前端開發工作臺等，打包構建了O2這一最終的交付產品。對于我們而言，就是通過開發兼容VSCode API的OpenSumi插件，通過在O2上安裝插件以達到最終的產品交付。

考慮到命令行調用、代碼復用的原因，我們設計了基于Node.js的CLI用于支持諸多基本功能，如創建模板，編譯模板，發布模板等。這里也有一個兩級分層。即提供通用的調試服務，靜態文件服務的utbd-devtools，以及基于utbd-devtools的各個不同CLI/IDE插件(通過DaemonInterface同utbd-devtools進行交互)。

2 底層能力

這里主要抽象了一些同模板開發沒有直接關系的一些公共服務，包括調試協議(通道)、數據的存儲與持久化、單例對象的管理池、Git服務、數據埋點服務等。

3 基礎服務(模板開發)

這里主要是模板開發所需要的一些基礎服務。

從編輯的角度而言，主要是自定義的DSL下的代碼智能感知，核心是要一方面去實時分析源代碼的語法樹結構，一方面要結合DSL本身的約束與規范來判斷各個樹節點(及屬性)是否合法等，再結合VSCode本身提供的語言服務器協議，實現最終的代碼智能感知。從DX的角度而言，我們需要考慮以下DSL的分析:

1. xml： 即main.xml，其描述了視圖的結構與樣式，對其分析有成熟方案；
2. json： 包括event_chain.json和mock.json, 用于描述事件鏈和mock數據，對其分析有成熟方案；
3. 表達式： 基于模板設置的數據源(data)，開發者可通過表達式的形式來描述屬性，如：

<ImageView
  width="match_content"

  height="14"

  scaleType="fitXY"

  imageUrl="@{data.picUrl}"

  visibility="@{data.picUrl?'visible':'gone'}"

/>

此處的imageUrl和visibility屬性即通過表達式書寫，表達式不僅可用于XML，也可用于事件鏈文件。表達式語法是一個刪減版的TypeScript語法，通過書寫antlr4語法文件(Lexer.g4和Parser.g4),使用antlr4ts工具即可自動生成對應的Lexer.ts，Parser.ts，ParserListener.ts和ParserVisitor.ts文件，從而用于后續AST分析。

分析獲得DSL的AST后，通過元數據(平臺約束的控件、表達式、原子能力等)的約束，結合VSCode LSP下支持的代碼智能感知API，我們即可實現包括補全、懸浮文檔、診斷、跳轉定義、代碼格式化、折疊、高亮等在內的代碼開發支持。

4 Feature開發與研發模式組裝

我們按照研發模式包括一條工作流，工作流又可以分為多個階段(準備階段、創建階段、編輯階段、調試階段、測試階段、發布階段)，每個階段又包括多個Feature(如創建階段包括創建工程與創建模板)這樣的層次關系，通過開發Feature最終組裝成DevelopPattern。

5 研發模式擴展

實踐中，不僅存在各類研發模式等的訴求，因為各種原因，還存在不少基于研發模式的自定義擴展，如消息業務域有基于DX模式的腳本擴展，菜鳥和CBU有基于DX模式的容器搭建擴展。為此，我們還設計了研發模式擴展插件，容許插件對上述的研發模式進行自定義擴展以滿足各自訴求。

IDE功能與使用

本文只介紹DX研發模式相關功能。

功能區圖示

創建階段

創建階段包括DX工程與模板。

創建工程

1. 設置GitlabToken(僅一次，以便自動創建Gitlab項目)
2. 點擊創建工程入口
3. 選擇研發模式(此處應為DX)
4. 配置參數，創建項目

創建模板

【新建模板】

1. 點擊創建模板入口
2. 配置參數，創建模板

【克隆模板】

1. 選擇需要克隆的模板對應的cola.build并右鍵
2. 點擊克隆模板

編輯階段

導入模板

其中包括通過關鍵字搜索模板，搜索結果可以直接打開(如本地存在)，也可以選擇導入。

導入時，我們可以選擇針對單模板的導入，也可以通過應用名+業務名的方式檢索到相關的所有模板，一并導入。

模板導入過程中，會挨個查詢各個模板的所有版本號，已經對應的內容，將這些內容作為Git記錄，加以提交。對于正式版本號，會打上形如: release/templatename/templateversion這樣的tag。

模板依賴管理

目前IDE中并不支持編譯基礎組件，僅支持引用基礎組件。如需編輯基礎組件需在模板平臺上操作，然后本地更新元數據獲取最新版本號后更新依賴以生效。這是因為，我們希望未來Import可以由Template標簽來替代，Template相關的編輯，引用和編譯IDE中都是支持的。

因而，這里只包括基礎組件的依賴管理以及批量版本變更。

對于基礎組件的依賴管理，實際上是可視化地編輯cola.build中的dependencies字段。

批量版本變更則適用于一個基礎組件被一組模板引用時，批量地更新這些引用模板對于被引用的基礎組件的版本依賴描述(源代碼)，通過選擇預發布，我們也可以在更新源代碼的同時，將引用模板批量預發布。

類似基礎組件依賴的批量修改，IDE也支持了Slot引用的批量修改。

代碼幫助

此處主要包括事件鏈格式化、表達式格式化、本地文件搜索、以及代碼樣例搜索。

其中本地文件搜索可通過簡單的規則精準搜索到文件如并點擊打開，如s/s/m可匹配到:  sub_main/src/mock.json。

代碼樣例搜索可通過關鍵字搜索到當前Aone代碼庫(Gitlab)上有哪些引用，如@getEngineStorage結合event_chain.json可以了解到時間鏈中getEngineStorage的具體用法。

表達式支持

此處的主要作用是實現表達式的一鍵格式化。

事件鏈可視化

此處主要是通過可視化的方式將事件鏈描述的原子能力的調用與轉移表現出來，目前支持了多種轉移關系，包括顯式的轉移以及隱式(表達式)的轉移關系。

點擊節點或者邊也可以自動選中對應的代碼區域。

代碼智能感知

1. 代碼補全: 支持main.xml中的控件名，屬性，屬性值；event_chain.json中的原子能力名，原子能力參數，事件鏈節點；表達式(名稱/data字段/事件鏈名稱)等；
2. 懸浮文檔: 支持main.xml中的控件名、屬性名；event_chain.json中的原子能力名，原子能力參數；表達式名；
3. 代碼診斷: 包括main.xml中的控件名，屬性名，屬性值；event_chain.json中的原子能力名(原子能力參數暫不支持，主要原因是平臺上的約束不夠完備)；表達式名；
4. 跳轉至定義: 主要是跳轉到mock.json(即data表達式，從main.xml或event_chain.json)和event_chain.json(從main.xml)；
5. 代碼格式化: 包括main.xml的格式化，event_chain.json的格式化，表達式格式化；
6. 代碼折疊: 包括main.xml, event_chain.json, mock.json以及表達式的折疊；
7. 代碼高亮: 主要指的是表達式名的高亮。

調試階段

預覽

這里主要包括調試服務掃碼、預覽頁單模板預覽和業務容器多模板預覽。開發者通過掃碼連接調試服務，當有設備連接時，當前選中的模板的變更將會編譯并將產物實時推送到手機并生效，當前沒有設備連接時，模板變更會實時編譯，并將編譯產物以二維碼方式透出，可直接掃碼預覽。

其中預覽頁單模板預覽同之前模板平臺。

業務容器多模板的預覽核心是解決預覽頁預覽的一些問題，包括缺少對于自定義組建的良好支持，只能預覽單模板，數據Mock不真實等，使用這一特性，開發者可以在任意包含DX模板的頁面中預覽IDE中的模板文件，代碼變更并同步到設備成功后，刷新頁面重新渲染模板即可生效。

這里也包括通過Command+Shift+P喚起命令面板，執行切換預覽模板從而快速切換到指定模板的功能(僅預覽頁預覽下有效)。

視圖審查

視圖審查主要用于排查布局顯示上的問題，比如節點丟失，屬性值不對等。

假設已經掃碼連接了調試服務，下同，不贅述。

1. IDE上打開啟用視圖審查開關
2. 設備側渲染DX模板
3. IDE上選中某條視圖審查記錄(也支持模糊搜索)
4. 打開對應模板的main.xml文件
5. 點擊main.xml中的某個標簽，可以自動展開三棵樹中的對應節點，并且將設備側的對應視圖高亮。
6. 點擊展開樹節點，或者展開樹節點屬性節點，即可自動選中對應的源代碼。

表達式回放

表達式回放主要用于排查復雜表達式執行的問題。

1. IDE上打開啟用表達式回放開關
2. 設備側渲染DX模板
3. IDE上選中某條表達式回放記錄(也支持模糊搜索)
4. 點擊回放按鈕，即可看到整個表達式執行的時序
5. 選中某個被執行過的節點，可以看到其執行的上下文。

事件鏈回放

事件鏈回放主要用于排查事件鏈執行的問題。

1. IDE上打開啟用事件鏈回放開關
2. 設備側渲染DX模板
3. IDE上選中某條事件鏈回放記錄(也支持模糊搜索)
4. 點擊回放按鈕，即可看到整個事件鏈執行的時序
5. 選中某個被執行過的節點，可以看到其執行的上下文。

設備管理

主要用于同iOS模擬器(Mac上)的深度融合，這樣開發者即使沒有一個iOS設備，或者設備商沒有可用于測試的包，也可以方便地安裝并使用IDE的各個功能。

發布階段

模板發布

1. 選擇需要發布的模板(支持搜索)
2. 選擇需要發布的分支
3. 填寫發布描述
4. 選擇部分配置項(其中校驗版本沖突主要用于防止模板平臺上存在一些更新的版本號；預先提交變更可使開發者訊速地修改校驗變更(尤其是簡單模板的變更)；跳過Git檢查可以不用檢查是否有待提交的內容，尤其是當開發者需要發布另一個分支，且當前分支的變更不需要提交時；預發布則用于配置是否正式發布)
5. 發布即可

發布的結果彈窗也會提示開發者這次發布產生了哪些版本號，產物cdn地址等。

模板歷史版本查詢

這里包括: 模板url拷貝、模板zip下載、模板預覽、發布信息、源代碼查看、代碼Diff、內容回滾、Diff鏈接分享(CR使用)等。

批量內置

這里將會完成雙端產物的內置，以及Android側所需要的presetTemplateInfos.json構建。

設置

這里主要是Gitlab Token的配置，以及基于GitDiff的模板發布所以來的Diff基線配置。

IDE演進思考

針對過去模板平臺的不足，我們實現了從編輯器到IDE的轉變，顯著提升了開發者的研發體驗。面向未來，我們有以下方面的演進思考:

擴大應用場景/團隊

1 IDE直接收益

• 工程化支持，開發者可在一個工作區內開發相關業務的一組模板；
• 代碼托管到Gitlab，多人協同，提交歷史，回滾，搜索，CR，數據統計，直接打通集團代碼服務；
• 更簡單的批量模板管理，如批量修改基礎組件依賴，批量發布，批量內置等；
• 對標高級語言編輯的代碼智能感知體驗(補全，文檔，診斷，跳轉，格式化，折疊，高亮等)，涵蓋main.xml, 表達式，事件鏈等。不僅如此，針對事件鏈，IDE還提供排序，一鍵折疊所有和可視化預覽；
• 更好的預覽體驗，開發者可結合IDE的業務容器預覽直接在當前業務容器動態替換模板(IDE中模板即時修改編譯生效)；
• 豐富的問題排查工具箱，針對視圖異常排查，IDE提供了視圖審查和源代碼關聯，可以建立動態的源碼同實際視圖結構(屬性)的雙向關聯；針對表達式執行復雜的問題，IDE提供了表達式回放以跟蹤表達式AST的結構和，執行順序，輸入輸出和上下文；針對事件鏈執行復雜的問題，IDE提供了事件鏈回放以跟蹤事件鏈中原子能力之間的執行順序，輸入輸出和上下文；
• 更好的模擬器融合，Mac上IDE深度融合了iOS模擬器，開發者可快速安裝/激活應用，連接調試服務并預覽頁面。

2 IDE潛在收益

• DX IDE提供了研發模式層面的擴展，基于DX衍生出來的技術方案可便捷地融合到IDE；
• 目前我們正在移動小組層面同研發體驗CoE團隊討論客戶端研發效能的度量模型和指標，基于IDE對于研發過程的多維度細粒度感知，我們將有機會幫助團隊度量研發效能，進一步改善研發體驗。

3 IDE使用成本

• 開發者需安裝O2和DX IDE插件，之后會有自動化的腳本，工具和命令以保證環境符合要求；
• 既有模板遷移成本的問題，目前IDE支持了基于搜索關鍵字(或ID)的單模板導入，以及基于app&biz的一組業務模板導入，一鍵遷移所需模板到DX工程；

技術迭代

目前，IDE已實現DX工程化和全研發生命周期支持，包含優秀的代碼編輯體驗，諸多問題排查手段，豐富的工具箱以解決研發痛點，后續我們將圍繞以下方面開展技術迭代。

1 既有設計的完善

• 補齊Android SDK中視圖審查功能。
• 性能方面，提供包括編輯期Linter，運行期的實時性能采集，發布期的Benchmark，運維期的性能大盤等數據以改善模板性能。
• 兼容性方面，打通手機中臺等設備服務，開發者可以快速預覽在不同設備上的渲染效果和性能。

2 技術演進與探索

• 目前的技術架構下，開發者依需安裝IDE和插件，存在接入成本高的問題。通過將IDE遠程部署，開發者使用Web連接遠端服務，不僅可避免安裝成本，也便于共享工作區等；
• 過去客戶端業務研發往往是客戶端與服務端分離，面對不斷增加的業務挑戰，更快的迭代速度要求，以業務為中心的端云一體化開發有了更多價值，Faas本身的日益成熟也使得客戶端開發后端邏輯更為便捷可行。IDE作為一個統一的編程平面，能更好地支持一體化工程下的前后端邏輯(頁面)開發，加速業務價值交付；
• 目前業界主流生態越來越多地使用聲明式UI，不論是技術先進性還是技術同學成長，我們都應更多地擁抱這一趨勢。探索DX DSL同聲明式UI(JetpackCompose, SwiftUI,Flutter,ArkUI)的結合，通過升級DSL，結合Jetpack Compose/SwiftUI/Flutter，配合以相關的分析解析編譯執行等工具鏈配套，開發者可更貼近原生(友好)地開發跨平臺業務。