基于 LowCodeEngine 的調(diào)試能力建設與實踐

概述

業(yè)務背景

低代碼由于研發(fā)效能和交付的優(yōu)勢變得越來越普及，在降本提效的同時也帶來了很多黑盒邏輯?，F(xiàn)有的低代碼平臺普遍缺乏面向用戶的調(diào)試能力，當用戶在低代碼搭建遇到問題時，排查和解決問題強依賴平臺的客服答疑或瀏覽器原生的調(diào)試能力，導致非前端用戶使用低代碼平臺的成本很高。因此我們需要提供更適合低代碼平臺的調(diào)試能力，降低低代碼平臺的使用成本。

技術難點

在阿里低代碼引擎的產(chǎn)品技術體系中，一方面我們需要提供低代碼平臺的基礎調(diào)試能力，適用于大多數(shù)低代碼的調(diào)試能力，需要考慮非前端用戶的使用習慣和學習成本；另一方面由于低代碼平臺的目標用戶類型差異較大，不同低代碼平臺所需的調(diào)試能力也是不一樣的，除了基礎的調(diào)試能力之外，我們需要通過提供擴展定制能力，幫助不同的低代碼平臺快速建設適合的調(diào)試能力。

技術細節(jié)

在技術架構上，我們通過分層設計，將調(diào)試體系分為 Client、Server、Protocol 等不同層來承擔不同的職責，向下做好協(xié)議的統(tǒng)一收斂，與低代碼引擎的協(xié)議和渲染體系對接，向上也能支持不同分層下的高度定制。在產(chǎn)品設計上，我們在低代碼引擎標準協(xié)議的基礎上完成了日志查看、錯誤碼定位、審查元素、數(shù)據(jù)源查看與修改等低代碼調(diào)試能力上的探索。具體實踐和分析：低代碼引擎體系下的調(diào)試能力在集團內(nèi)的中后臺平臺 A 落地了半年，活躍用戶總量為 300，占比平臺總月活的 10%，并大幅度降低了答疑中調(diào)試相關問題的占比。

低代碼引擎介紹

低代碼引擎是一款為低代碼平臺開發(fā)者提供的，具備強大擴展能力的低代碼研發(fā)框架。由阿里巴巴終端委員會（原阿里巴巴前端委員會）、釘釘宜搭聯(lián)合出品。使用者只需要基于低代碼引擎便可以快速定制符合自己業(yè)務需求的低代碼平臺。同時，低代碼引擎還在標準低代碼設計器的基礎上提供了簡單易用的定制擴展能力，能夠滿足業(yè)務獨特的功能需要。

開源地址：https://github.com/alibaba/lowcode-engine

官網(wǎng)：http://lowcode-engine.cn/#/

點擊文末「閱讀原文」，可直接跳轉查看

低代碼調(diào)試背景介紹

在阿里內(nèi)部有很多低代碼平臺，其中圖中的這款低代碼平臺是用于開發(fā)中后臺頁面。由于這個平臺沉淀的時間比較久，因此用戶量相對比較多，覆蓋的人群類型也比較廣泛。

該低代碼平臺月活躍用戶有大概 4000 人左右，這 4000 人里面有前端、后端、測試開發(fā)等。其中大概只有 30% 的使用者是前端研發(fā)，而剩下 70% 的使用者都是非前端研發(fā)人員。為了幫助這 4000 人使用該低代碼平臺，該低代碼平臺提供了兩個前端全職進行答疑，幫助該平臺的使用者解決他們遇到的問題。

我們可以看到，答疑同學一個月大概需要解決 400 多個答疑工單，這些工單里面有大量的使用問題和應用調(diào)試問題。

那我們來假設一下，如果這個低代碼平臺沒有前端同學來進行答疑，那是不是有至少 400 多個使用者有可能無法使用我們的低代碼平臺。我認為是非常有可能的，在這種情況下，如果他們遇到問題，找不到渠道來解決問題的，因此對低代碼平臺產(chǎn)生不好的印象，他們就很容易拋棄掉這個低代碼平臺，甚至拋棄掉所有的的低代碼平臺也是有可能的。

這樣我們可以看出來這個低代碼平臺有兩個問題：

• 答疑成本高，對于非前端研發(fā)同學來說，十分依賴答疑同學提供的支持，這樣會導致低代碼平臺用戶量越多，答疑成本就越高，
• 學習門檻高：就算有足夠的答疑支持，非前端研發(fā)使用低代碼平臺也有較高的學習成本，這就導致低代碼平臺很難進行更大范圍的推廣。

因此，我們需要去減少答疑的成本，為了找到減少答疑的解決方案，我們先來分析一下答疑的案例。

這是一個答疑同學在答疑過程中和低代碼平臺的使用者溝通的過程。

在最開始的時候，用戶會跟答疑人員說遇到了一個報錯，需要答疑人員幫忙看看問題在哪里。這時候一般都需要用戶提供可以讓答疑人員復現(xiàn)問題的步驟。比如說，需要提供報錯頁面的地址。在大多數(shù)情況下，這些頁面都有權限管控，需要找對應的權限管理員來添加權限。甚至有的項目因為添加權限太麻煩，只能通過截圖或者視頻來查看和定位問題。

所以這個案例暴露出來的第一個問題是權限管控會讓答疑時間更長，也讓查看和定位問題的難度更高了。

我們繼續(xù)看第二部分，當權限添加完成之后，用戶和答疑人員往往還要溝通復現(xiàn)路徑，由于用戶和答疑人員溝通過程往往存在信息差，所以需要反復溝通才能明確復現(xiàn)的步驟，答疑人員才能復現(xiàn)出報錯場景，才能找到到問題。

我們可以看出來，這里暴露的第二個問題是復現(xiàn)問題溝通耗時且繁瑣。

找到問題之后，發(fā)現(xiàn)這些問題很有可能是一些對于前端很簡單的問題，比如說標點符號使用錯誤，中英文符號使用錯誤等。因為大多數(shù)低代碼平臺的使用者是非前端開發(fā)，他們沒有前端相關的基礎。因此對于前端來說很簡單的問題沒有辦法自己解決，就只能依賴答疑人員的幫助。那如果缺少了答疑，沒有前端基礎的使用者想要解決類似的問題，學習成本還是非常高的

因此，一方面為了減少答疑的溝通成本、另外一方面為了降低非前端研發(fā)同學的學習成本。我們決定為低代碼平臺提供低代碼調(diào)試工具。

低代碼調(diào)試能力建設

首先我們來看一下該低代碼平臺調(diào)試的現(xiàn)狀。這里我們設計了一個頁面，這個頁面在設計器中是沒有問題的，但是當我們在某一個組件中配置了一個錯誤的表達式，我們在預覽的時候就會看到頁面出現(xiàn)報錯。對于前端來說，可以打開控制臺查看報錯信息，報錯信息就像圖中展示的這樣。

這個報錯信息能幫助低代碼開發(fā)師找到問題嗎？實際上，不管是對于前端研發(fā)人員來說，還是對于非前端研發(fā)來說，都是很難直接定位到問題的。

一方面，這個頁面很有可能有幾百上千個節(jié)點，每一個節(jié)點都有很多個配置。這個報錯信息沒有告訴我們這個報錯的代碼是配置在哪個組件節(jié)點里面的。也不能讓用戶打開每一個節(jié)點來檢查每一個配置。

另外一個方面，低代碼平臺可以配置代碼的地方很多，這樣就導致我們的代碼是非常散亂的。我們無法通過現(xiàn)有信息知道報錯代碼配置的方式，配置的地方。也就是說，就算是前端，也很難找到報錯代碼的。

為了讓低代碼平臺的使用者能自己解決這類調(diào)試問題，我們就需要提供一個調(diào)試工具，讓用戶可以

• 直觀的知道如何查看報錯的內(nèi)容
• 可以根據(jù)報錯內(nèi)容，知道報錯的代碼在哪里
• 在找到報錯的代碼之后，知道如何去修改代碼，修復問題。

有了這個工具之后，低代碼平臺的使用者就可以自己解決問題，也就大大減少對答疑人員的依賴了。

對于第一個問題，我們需要讓低代碼平臺的使用者知道“如何查看報錯”，我們提供的解決方案是，在遇到報錯的時候，我們通過一個顯眼的標識來告訴用戶，你開發(fā)的頁面出現(xiàn)錯誤了，其中錯誤的個數(shù)有多少個。用戶看到這個標識之后，就會去點擊這個標識。當用戶點擊之后，就會在頁面中出現(xiàn)低代碼調(diào)試工具，來幫助用戶查看報錯相關的信息。

在這個調(diào)試工具中，我們通過展示日志的方式，來讓用戶更加直觀的找到跟錯誤有關的信息。并且，慢慢的用戶就知道我們提供了一個工具來幫助他們開發(fā)低代碼頁面。之后遇到其他問題也會自己打開低代碼調(diào)試工具，相當于起到了鍛煉用戶開發(fā)習慣的作用。

在用戶知道如何查看報錯之后，接下來的問題就是如何通過日志輸出的能力，讓用戶知道錯誤的代碼在哪里。

對于這個問題，我們通過給不同類型的報錯提供對應的錯誤碼，來幫助用戶找到報錯代碼。

1. 首先對于不同類型的錯誤，我們會提供一個單獨的錯誤碼，并且還會提供對應的上下文信息，比如組件 ID 是多少，用戶配置的表達式內(nèi)容是什么；
2. 當然有了這些信息還是不夠的，我們還需要將上下文信息用更語義化的方式展示給用戶。因此為了更好的組織這些錯誤碼、對應的上下文信息以及展示給用戶的描述文案，我們利用錯誤碼管理后臺來管理這些信息。

有了這些信息，我們在低代碼調(diào)試工具的日志面板中就可以展示出非常詳細的信息來幫助用戶找到報錯的代碼。

比如：之前我們在控制臺中看到的錯誤，在日志面板中展示的內(nèi)容就變成了：某某某組件表達式執(zhí)行出現(xiàn)錯誤，并給出了錯誤的原因，給出了錯誤的表達式內(nèi)容，錯誤的組件 ID 等信息。用戶通過組件 ID 就可以在低代碼平臺中進行搜索，就可以找到對應的組件了。也就能找到報錯的代碼了。

對于非前端研發(fā)來說，我們幫助用戶找到錯誤的代碼還不能完全解決問題，我們還需要告訴他們?nèi)绾涡薷拇a來解決錯誤。

為了解決這個問題，我們在錯誤日志的基礎上，增加了一個外鏈功能，用戶可以點擊這個外鏈，打開一個錯誤碼對應的文檔，這個文檔通過圖文的方式詳細的描述了問題的解決步驟。這樣對于一些簡單的問題，用戶就可以找到解決方案。

當然，對于一些相對復雜的報錯案例，用戶可能還是無法自己解決問題，還是需要答疑人員的幫助。為了減少用戶和答疑人員來回溝通的成本，我們還支持用戶上傳頁面日志，日志中會攜帶頁面的關鍵信息，比如說日志內(nèi)容、搭建產(chǎn)生的 json 源碼，環(huán)境信息等等。這樣就可以減少工單處理的時長。

第二個用戶會遇到的問題是？對于大多數(shù)低代碼產(chǎn)品，他們的在頁面設計時所看到的效果，和實際預覽的時候看到的效果在一些情況下是不一致的。比如說我們在設計這個頁面的時候，給某個組件配置了表達式，而這些表達式在畫布中是不會進行計算的。這樣會導致一個問題。設計時看到的效果和實際展示看到的效果是不一致的。

比如這里的按鈕展示的就不一樣。那么當我們在預覽的時候，如果效果和我們的期望的不一樣，我們就想知道

• 這個組件的配置表達式是什么？
• 這個組件展示的文案是怎么計算出來的？

之前為了解決這些問題，用戶需要回到設計器中，找到對應的組件，查看這個組件的配置才能解決。而對于一些復雜的配置，比如三元表達式，用戶為了找到問題，還需要在很多地方添加 Console，查看數(shù)據(jù)源的值。因此為了幫助用戶快速的定位到單個組件配置的問題，我們提供了組件審查功能。

它的效果是這樣的，當切換到組件審查面板的時候，用戶可以點擊頁面中的元素，或者點擊大綱樹中對應的組件，就可以看到這個組件的詳細信息。

比如這里有一個低代碼開發(fā)的頁面，我們需要查看頁面中某一個按鈕的展示邏輯。

1. 我們就可以點擊這個按鈕，就可以看到這個組件的詳細信息
2. 首先展示的詳細信息，是這個組件根據(jù)配置計算出來的值，我們可以看到這個按鈕展示的文案來源是 content 這個參數(shù)的值。
3. 第二個展示的信息是這個組件配置的原始內(nèi)容，這里我們就可以看到 content 這個參數(shù)值實際上配置的是一個表達式，也就是 content 的值是根據(jù) state.text 的表達式計算來的。
4. 第三個我們展示的信息是這個組件可以訪問到的上下文信息，比如 this.state 的值是多少，比如 this.utils 下有哪些函數(shù)等等。

這樣用戶就可以通過這個工具，一步步查看組件參數(shù)的配置，也可以推導出它的計算過程，如果不符合預期也可以快速的發(fā)現(xiàn)并知道如何解決問題。

除了剛剛提到的這兩個工具之外，我們還提供了數(shù)據(jù)源面板和 schema 面板兩個調(diào)試工具。

• 數(shù)據(jù)源面板：數(shù)據(jù)源面板可以讓用戶查看頁面數(shù)據(jù)源的值，并且為了方便低代碼平臺的用戶對數(shù)據(jù)源進行調(diào)試，數(shù)據(jù)源面板還支持修改數(shù)據(jù)源的值。
• schema 面板：對于低代碼平臺來說，所有的可視化操作和配置，實際上操作的都是一個 json 對象，這個 json 對象我們把它叫做 schema，我們也提供了 schema 面板來查看頁面渲染時使用的 schema 源碼。

以上就是我們針對該低代碼平臺建設的低代碼調(diào)試能力。但是它只能解決一個低代碼平臺的問題，為了幫助更多的低代碼平臺解決類似的問題，我們還需要提供低代碼調(diào)試擴展能力。

低代碼調(diào)試擴展能力

在阿里，將近有200多個低代碼平臺，而剛剛我們提到的低代碼平臺只是這里面中的一個。那么其他低代碼平臺需要調(diào)試能力嗎？肯定也是需要的，不過他們需要的不只是我們之前提到的調(diào)試能力，他們還需要根據(jù)自己平臺的特點，來定制適合自己平臺的調(diào)試能力。

比如，

• 有的平臺的用戶是前端，就期望能通過瀏覽器插件來進行調(diào)試，這樣更符合前端用戶開發(fā)調(diào)試的習慣；
• 而有的平臺，提供的是表單搭建能力，比如說宜搭。就更需要表單相關的調(diào)試功能；
• 有的平臺就想在調(diào)試能力上加一個按鈕，來幫助用戶找到答疑入口。

為了滿足不同低代碼平臺對調(diào)試能力的訴求，我們需要在低代碼調(diào)試能力的基礎上提供擴展能力，讓低代碼平臺可以定制對應的調(diào)試能力。

• 插件化：首先我們需要將調(diào)試能力進行插件化，插件化的意思是將每一個調(diào)試能力都抽象為一個插件。這樣可以方便不同的低代碼平臺選擇不同的調(diào)試能力，并且可以對調(diào)試能力進行插拔，平臺需要什么調(diào)試能力就可以引用對應的插件。
• 基礎調(diào)試能力：在將調(diào)試能力插件化之后，我們就可以將之前建設的調(diào)試能力作為基礎調(diào)試能力，并且沉淀成基礎調(diào)試能力插件，比如日志調(diào)試能力插件、元素審查調(diào)試能力插件等等。
• 調(diào)試擴展能力：當基礎調(diào)試能力不滿足低代碼平臺的訴求時，低代碼平臺就需要利用我們提供的調(diào)試擴展能力，來開發(fā)自定義調(diào)試插件。
• 低代碼平臺開發(fā)者：當我們有了基礎調(diào)試能力和調(diào)試擴展能力之后，低代碼平臺的開發(fā)者就可以基于這兩個能力開發(fā)平臺的調(diào)試能力了。

首先低代碼平臺開發(fā)者可以看看現(xiàn)有的基礎調(diào)試能力是否適合自己的低代碼平臺，并且選擇適合自己低代碼平臺的基礎調(diào)試能力。

基礎調(diào)試能力無法滿足的部分，低代碼平臺就需要開發(fā)對應的調(diào)試能力插件。自定義調(diào)試插件開發(fā)完成之后，就可以和基礎調(diào)試能力組合到一起。這樣，低代碼平臺就擁有了更適合自己平臺的調(diào)試能力。

比如：

• 低代碼平臺 A，就選擇了元素審查的基礎調(diào)試能力，并且基于自己平臺的搭建特點，開發(fā)了表單調(diào)試能力。
• 低代碼平臺 B，就選擇的是日志的基礎調(diào)試能力，并開發(fā)了圖表調(diào)試能力。

這樣不同的低代碼平臺就可以擁有更適合自己平臺的調(diào)試能力，這個就是我們最終期望實現(xiàn)的低代碼調(diào)試擴展能力，

接下來的問題是：我們要如何實現(xiàn)低代碼調(diào)試擴展能力，并且它還能用于幾十、上百個低代碼平臺。

幸運的是，在我們建設低代碼調(diào)試擴展能力之前，阿里集團大部分低代碼平臺都是基于低代碼引擎來建設的。也就是阿里內(nèi)部 200 個低代碼平臺中，有將近 130 個低代碼平臺是基于低代碼引擎來實現(xiàn)低代碼搭建和渲染的。

有了這個前提，我們就可以站在巨人的肩膀上，通過給低代碼引擎這個體系提供標準的低代碼調(diào)試能力，以及低代碼調(diào)試擴展能力，來服務越來越多的低代碼平臺。

正如我們之前提到的，大多數(shù)低代碼平臺，可視化拖拽和配置實際上都是在操作一份 json 文件。低代碼引擎也不例外，并且低代碼引擎還對這個 json 文件制定了一份標準協(xié)議，也就是「低代碼引擎搭建協(xié)議」。因此通過低代碼引擎建設的低代碼平臺，在可視化操作之后，都會產(chǎn)生一份符合搭建協(xié)議的 json schema。

這份 json schema 瀏覽器是無法直接進行解析渲染的，因此還需要依托于「渲染引擎」來解析 schema，將低代碼頁面繪制到瀏覽器中。那么這個渲染引擎是不是只有一套呢？并不是。由于渲染引擎在繪制頁面的時候，還會用到大量的基礎組件或者業(yè)務組件，這些組件用到的技術?？赡苁遣灰粯拥模瑸榱俗尣煌夹g棧的物料都能渲染到瀏覽器中，渲染引擎也需要根據(jù)不同的技術棧實現(xiàn)多套。

因此，我們有多套渲染引擎。例如 React 渲染引擎、Rax 渲染引擎、以及未來還會有 Vue 渲染引擎等。

介紹了那么多關于渲染引擎的信息，那渲染引擎和調(diào)試能力是什么關系呢？

調(diào)試能力需要通過渲染引擎才能獲取到頁面信息。為什么這么說呢，我們先看一下低代碼頁面繪制的過程。

1. 首先低代碼平臺通過可視化配置，會產(chǎn)生一份描述頁面的 json schema。
2. 在頁面渲染的時候，渲染引擎會根據(jù) schema 的內(nèi)容繪制頁面，并且除了 json schema 之外，渲染引擎還需要知道，json schema 中描述的組件和插件是什么樣的。所以也需要把整個頁面會用到的組件、第三方插件等信息給到渲染引擎。
3. 渲染引擎有了這些信息之后，才會在瀏覽器上繪制出來頁面。

在整個繪制過程中，瀏覽器知道 schema 的內(nèi)容嗎？以及知道每一個組件的參數(shù)值嗎？實際上，瀏覽器是不知道的，因為這些執(zhí)行和解析的過程都是由渲染引擎完成的。那么調(diào)試能力需要知道這些信息，就只能通過渲染引擎來獲取。

• 比如說需要通過渲染引擎來獲取頁面的 schema
• 比如說需要跟渲染引擎來獲取單個組件的參數(shù)值。

因此調(diào)試能力需要通過某種方式和渲染引擎進行通信，比如通過 API 來進行通信。但是正如之前我們提到的，渲染引擎根據(jù)不同的技術棧實現(xiàn)了多套，而每一套渲染引擎提供的 API 都有可能是不一致的。因此我們不能基于渲染引擎的 API 來開發(fā)調(diào)試能力。

這里為什么說不能呢？想象一下，如果有這樣一個低代碼平臺，它即支持PC頁面的搭建也支持 H5 頁面的搭建，但是 PC 頁面使用的可能是 React 版本的渲染引擎，而 H5 頁面使用的是 Rax 版本的渲染引擎。那么同樣的調(diào)試能力就需要根據(jù)兩個不同版本的渲染引擎 API 來做兼容，或者說可能需要開發(fā)兩套。這肯定是不合理的，那調(diào)試能力和渲染引擎之間就需要一個溝通的標準。

這個通信的標準就是低代碼調(diào)試協(xié)議。它通過定義渲染引擎和低代碼調(diào)試能力之間通信的標準，來抹平不同版本渲染引擎在 API 和實現(xiàn)上的差異。比如：

• 它定義了渲染引擎如何主動通知調(diào)試能力；
• 它也定義了調(diào)試能力如何主動通過渲染引擎獲取到相關的信息。

這樣的好處是，

• 對于低代碼平臺的開發(fā)者來說，他們在開發(fā)低代碼調(diào)試能力的時候可以不用關注頁面用的是什么技術棧的渲染引擎。也不需要做任何兼容和適配的工作；
• 對于低代碼引擎來說，不同技術棧得渲染引擎在實現(xiàn)了低代碼調(diào)試協(xié)議之后，就可以支持所有已經(jīng)開發(fā)好的調(diào)試能力。

接下來讓我們看看調(diào)試協(xié)議是如何進行定義的。

首先在定義協(xié)議之前，我們再來明確一下我們定義協(xié)議的目的是什么。它的主要的目的還是用來完成調(diào)試能力的開發(fā)。而調(diào)試能力開發(fā)需要的主要分為兩個方面：

1.schema 獲取和操作類型

第一個是 schema 的獲取或者修改相關的操作。比如獲取整個頁面的 schema，獲取單個組件節(jié)點的參數(shù)和狀態(tài)。這些操作本質(zhì)上都是在獲取或者操作 schema。

基于低代碼引擎建設的低代碼平臺，產(chǎn)生的 schema 是根據(jù)低代碼引擎搭建協(xié)議規(guī)范生成的。因此我們操作 schema 就是操作搭建協(xié)議描述的結構。為了讓調(diào)試能力更方便的操作搭建協(xié)議，我們將搭建協(xié)議分成了三層。

• 第一層是搭建協(xié)議的頂層結構，為了操作這一層結構，我們在調(diào)試協(xié)議中定義了 schema 調(diào)試域。這樣就可以通過 schema 調(diào)試域來獲取整個頁面的 json schema 或者說修改整個頁面的 json schema。
• 第二層是搭建協(xié)議中的容器結構，容器是一類特殊的組件，在組件能力基礎上還增加了一些特殊能力，比如說它有單獨的自定義方法和數(shù)據(jù)源。因此我們定義了 Container 調(diào)試域來操作容器這一層結構。這樣我們就可以在調(diào)試能力中修改容器的數(shù)據(jù)源或者調(diào)用容器中的自定義方法了。
• 第三層就是搭建協(xié)議中的單個組件結構，在調(diào)試中肯定需要對單個組件進行操作，比如說需要知道組件計算后的參數(shù)值，組件的原始配置，獲取組件的 json schema 等等。因此我們定義了 Node 調(diào)試域來操作這一層結構。

2.輔助類型

除了獲取或者修改 schema 相關的操作之外，在調(diào)試的時候，我們還需要一些輔助類型的操作。比如說，調(diào)試能力想打開一個新的瀏覽器頁面，就需要在瀏覽器窗口中執(zhí)行對應的表達式。這些需要執(zhí)行的表達式我們就用 Runtime 這個調(diào)試域來進行通信。比如，當我們審查元素的時候，需要頁面出現(xiàn)遮罩，來標識用戶正在查看的組件是哪個。因此我們定義了 Overlay 調(diào)試域來進行相關通信。

這樣我們的低代碼調(diào)試協(xié)議就定義好了。接下來我們看一下根據(jù)低代碼調(diào)試協(xié)議，我們實際上在調(diào)試過程中調(diào)試工具和渲染引擎通信的示例。

輔助類型 – Runtime 調(diào)試域

第一個例子，是一個輔助類型的域，也就是 Runtime 調(diào)試域。當調(diào)試能力期望在新的瀏覽器窗口中打開一個新的頁面時，就會發(fā)送一個 Runtime 域的 JSON，這個 JSON 中的 expression 字段就是定義了需要執(zhí)行的表達式。當渲染引擎接收到這個 JSON 之后，通過解析，就知道了它的意圖，就會執(zhí)行 JSON 中的表達式，執(zhí)行完成之后，也會發(fā)送一個 JSON 通知調(diào)試面板表達式執(zhí)行完成。

schema 操作類型 – Schema 調(diào)試域

第二個例子，是關于操作低代碼引擎搭建協(xié)議頂層結構的域，也就是 Schema 域，當 Schema 變化的時候，渲染引擎就會發(fā)送圖中的 JSON 給到調(diào)試工具，調(diào)試面板就能知道當前頁面的 Schema 變化了，頁面渲染的內(nèi)容也就變化了，調(diào)試能力就需要執(zhí)行相關的操作，比如更新 schema 調(diào)試面板展示的內(nèi)容，更新審查面板的大綱樹等等。

低代碼調(diào)試協(xié)議目前基本上介紹的差不多了，我們再考慮一個問題，之前我們提到這個協(xié)議由渲染引擎來發(fā)送，但是這樣是不是合適呢？實際上是不合適的，因為對于低代碼平臺來說，線上環(huán)境和開發(fā)環(huán)境中用的渲染引擎都是同一個，在線上環(huán)境有那么多冗余的代碼是有問題的。另外這種實現(xiàn)方案也會讓渲染引擎有較大的改動，同時也會讓使用舊版本渲染引擎的頁面無法使用調(diào)試能力。

那么由誰來發(fā)送調(diào)試協(xié)議呢，以及它又通過什么方式來和渲染引擎進行通信呢？

為了解決這個問題，我們新增了一個代理人的角色，這樣：渲染引擎通知調(diào)試能力的方式就變成了，渲染引擎通過事件讓代理人知道要發(fā)送調(diào)試協(xié)議了，代理人就發(fā)送對應的調(diào)試協(xié)議。調(diào)試工具想獲取 schema 的內(nèi)容就變成了，調(diào)試工具發(fā)送的調(diào)試協(xié)議，由代理人來接收，接收之后代理人就會調(diào)用渲染引擎的 API 來獲取 schema 的內(nèi)容。得到結果之后代理人再將結果通過調(diào)試協(xié)議發(fā)送給低代碼調(diào)試工具。

增加代理人的好處是：

• 渲染引擎只需要提供相關的 API，而不需要為了調(diào)試能力進行大規(guī)模的改動。
• 代理人只有在開發(fā)低代碼平臺頁面時才存在，這樣就不會影響到我們的線上環(huán)境。

我們看一下實際通信的例子，

1. 首先在頁面初始化的時候，代理人會調(diào)用渲染引擎的 API，來注冊日志回調(diào)事件，相當于跟渲染引擎說，有日志了記得通知我；
2. 當渲染引擎出現(xiàn)日志的時候，就會調(diào)用代理人注冊的回調(diào)函數(shù)，相當于通知代理人，有日志了，日志內(nèi)容是某某某。
3. 代理人收到通知之后，就會發(fā)送對應的調(diào)試協(xié)議，也就是圖中的 Json 對象。
4. 低代碼調(diào)試能力就會接收到對應的協(xié)議，也就可以執(zhí)行相關的操作，這里就是將接收到的新日志展示出來。

我們已經(jīng)定義好了低代碼調(diào)試協(xié)議，也實現(xiàn)了渲染引擎和調(diào)試能力之間的通信能力。

接下來我們還需要提供一個容器來展示基礎插件和自定義插件。

根據(jù)展示的類型，我們將插件分為兩種：

1. Tab 類型：比如之前的日志面板。對應圖中的黃色區(qū)域。
2. Action 類型：當點擊的時候，它只會執(zhí)行一些操作，比如上傳日志，比如跳轉到答疑頁面等等。這些插件會展示在圖中的紅色區(qū)域。

用戶可以根據(jù)自己需要的調(diào)試能力來選擇開發(fā)不同類型的插件。

我們現(xiàn)在基本上已經(jīng)實現(xiàn)基本的調(diào)試擴展能力了，為了讓低代碼平臺可以更便捷的開發(fā)低代碼平臺調(diào)試能力，我們還提供了調(diào)試相關研發(fā)的工具鏈，讓用戶可以初始化開發(fā)插件，調(diào)試插件以及整合插件。除了工具鏈之外，我們還提供了更方便的 API 來操作調(diào)試協(xié)議，這樣用戶開發(fā)調(diào)試能力的時候就不用寫 JSON 了。

這樣我們的低代碼調(diào)試擴展能力就建設完成了。

低代碼調(diào)試能力實踐

在阿里的這款中后臺低代碼平臺中，使用調(diào)試能力的月活躍用戶有 300 人，平臺的答疑量降低了 10% 左右。

其中一些簡單的答疑基本上已經(jīng)消失了，比如說由于跨域，一些接口請求會出現(xiàn)錯誤，之前也有很多同學因為這類問題找到我們答疑同學，現(xiàn)在之類答疑已經(jīng)沒有了，并且由于組件表達式配置錯誤，而導致的頁面報錯，這種類型的答疑也少了很多。

此外，阿里對外的商業(yè)化低代碼平臺，釘釘宜搭，由于大多數(shù)搭建場景是在搭建表單頁面，他們也根據(jù)表單頁面的特點，擴展了對應的調(diào)試能力?？梢灾С植榭幢韱螖?shù)據(jù)和錯誤請求。

目前低代碼調(diào)試能力還處于剛剛萌芽的階段，還需要不斷探索和建設。就像瀏覽器提供給前端研發(fā)豐富的調(diào)試能力一樣，低代碼領域未來還會有非常豐富的調(diào)試能力，這些調(diào)試能力可以幫助越來越多的低代碼開發(fā)師解決低代碼搭建過程中遇到的問題。

下一步我們還會建設更多的基礎調(diào)試能力：

• 比如用戶在低代碼中寫的 JS 代碼，我們可以在調(diào)試工具中查看和調(diào)試對應的 JS 代碼。而不是需要回到設計器中才能查看。
• 比如可以在調(diào)試工具中查看頁面的數(shù)據(jù)源請求信息。
• 比如可以查看頁面或者容器生命周期的執(zhí)行等等。

此外，我們還會提供更多的低代碼調(diào)試容器：

• 比如 Web 容器，適合提供給非前端研發(fā)同學來使用。
• 比如瀏覽器插件容器，適合提供給前端研發(fā)來使用，更適合前端研發(fā)同學的調(diào)試習慣。
• 比如說客戶端調(diào)試容器，提供給一些特殊調(diào)試場景來使用，比如用于移動端調(diào)試場景。

最后，我們也需要讓更多的渲染引擎支持低代碼調(diào)試能力，比如我們低代碼引擎中不同技術棧的渲染引擎，React 版本的渲染引擎和 Rax 版本的渲染引擎，以及未來由社區(qū)支持的 Vue 渲染引擎。