基於 LowCodeEngine 的除錯能力建設與實踐

概述

業務背景

低程式碼由於研發效能和交付的優勢變得越來越普及，在降本提效的同時也帶來了很多黑盒邏輯。現有的低程式碼平臺普遍缺乏面向使用者的除錯能力，當用戶在低程式碼搭建遇到問題時，排查和解決問題強依賴平臺的客服答疑或瀏覽器原生的除錯能力，導致非前端使用者使用低程式碼平臺的成本很高。因此我們需要提供更適合低程式碼平臺的除錯能力，降低低程式碼平臺的使用成本。

技術難點

在阿里低程式碼引擎的產品技術體系中，一方面我們需要提供低程式碼平臺的基礎除錯能力，適用於大多數低程式碼的除錯能力，需要考慮非前端使用者的使用習慣和學習成本；另一方面由於低程式碼平臺的目標使用者型別差異較大，不同低程式碼平臺所需的除錯能力也是不一樣的，除了基礎的除錯能力之外，我們需要通過提供擴充套件定製能力，幫助不同的低程式碼平臺快速建設適合的除錯能力。

技術細節

在技術架構上，我們通過分層設計，將除錯體系分為 Client、Server、Protocol 等不同層來承擔不同的職責，向下做好協議的統一收斂，與低程式碼引擎的協議和渲染體系對接，向上也能支援不同分層下的高度定製。在產品設計上，我們在低程式碼引擎標準協議的基礎上完成了日誌檢視、錯誤碼定位、審查元素、資料來源檢視與修改等低程式碼除錯能力上的探索。具體實踐和分析：低程式碼引擎體系下的除錯能力在集團內的中後臺平臺 A 落地了半年，活躍使用者總量為 300，佔比平臺總月活的 10%，並大幅度降低了答疑中除錯相關問題的佔比。

低程式碼引擎介紹

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

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

官網：http://lowcode-engine.cn/#/

點選文末「閱讀原文」，可直接跳轉檢視

低程式碼除錯背景介紹

在阿里內部有很多低程式碼平臺，其中圖中的這款低程式碼平臺是用於開發中後臺頁面。由於這個平臺沉澱的時間比較久，因此使用者量相對比較多，覆蓋的人群型別也比較廣泛。

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

我們可以看到，答疑同學一個月大概需要解決 400 多個答疑工單，這些工單裡面有大量的使用問題和應用除錯問題。

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

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

• 答疑成本高，對於非前端研發同學來說，十分依賴答疑同學提供的支援，這樣會導致低程式碼平臺使用者量越多，答疑成本就越高，

• 學習門檻高：就算有足夠的答疑支援，非前端研發使用低程式碼平臺也有較高的學習成本，這就導致低程式碼平臺很難進行更大範圍的推廣。

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

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

在最開始的時候，使用者會跟答疑人員說遇到了一個報錯，需要答疑人員幫忙看看問題在哪裡。這時候一般都需要使用者提供可以讓答疑人員復現問題的步驟。比如說，需要提供報錯頁面的地址。在大多數情況下，這些頁面都有許可權管控，需要找對應的許可權管理員來新增許可權。甚至有的專案因為新增許可權太麻煩，只能通過截圖或者視訊來檢視和定位問題。

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

我們繼續看第二部分，當權限新增完成之後，使用者和答疑人員往往還要溝通復現路徑，由於使用者和答疑人員溝通過程往往存在資訊差，所以需要反覆溝通才能明確復現的步驟，答疑人員才能復現出報錯場景，才能找到到問題。

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

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

因此，一方面為了減少答疑的溝通成本、另外一方面為了降低非前端研發同學的學習成本。我們決定為低程式碼平臺提供低程式碼除錯工具。

低程式碼除錯能力建設

首先我們來看一下該低程式碼平臺除錯的現狀。這裡我們設計了一個頁面，這個頁面在設計器中是沒有問題的，但是當我們在某一個元件中配置了一個錯誤的表示式，我們在預覽的時候就會看到頁面出現報錯。對於前端來說，可以開啟控制檯檢視報錯資訊，報錯資訊就像圖中展示的這樣。

這個報錯資訊能幫助低程式碼開發師找到問題嗎？實際上，不管是對於前端研發人員來說，還是對於非前端研發來說，都是很難直接定位到問題的。

一方面，這個頁面很有可能有幾百上千個節點，每一個節點都有很多個配置。這個報錯資訊沒有告訴我們這個報錯的程式碼是配置在哪個元件節點裡面的。也不能讓使用者開啟每一個節點來檢查每一個配置。

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

為了讓低程式碼平臺的使用者能自己解決這類除錯問題，我們就需要提供一個除錯工具，讓使用者可以

• 直觀的知道如何檢視報錯的內容

• 可以根據報錯內容，知道報錯的程式碼在哪裡

• 在找到報錯的程式碼之後，知道如何去修改程式碼，修復問題。

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

對於第一個問題，我們需要讓低程式碼平臺的使用者知道“如何檢視報錯”，我們提供的解決方案是，在遇到報錯的時候，我們通過一個顯眼的標識來告訴使用者，你開發的頁面出現錯誤了，其中錯誤的個數有多少個。使用者看到這個標識之後，就會去點選這個標識。當用戶點選之後，就會在頁面中出現低程式碼除錯工具，來幫助使用者檢視報錯相關的資訊。

在這個除錯工具中，我們通過展示日誌的方式，來讓使用者更加直觀的找到跟錯誤有關的資訊。並且，慢慢的使用者就知道我們提供了一個工具來幫助他們開發低程式碼頁面。之後遇到其他問題也會自己開啟低程式碼除錯工具，相當於起到了鍛鍊使用者開發習慣的作用。

在使用者知道如何檢視報錯之後，接下來的問題就是如何通過日誌輸出的能力，讓使用者知道錯誤的程式碼在哪裡。

對於這個問題，我們通過給不同型別的報錯提供對應的錯誤碼，來幫助使用者找到報錯程式碼。

1. 首先對於不同型別的錯誤，我們會提供一個單獨的錯誤碼，並且還會提供對應的上下文資訊，比如元件 ID 是多少，使用者配置的表示式內容是什麼；

2. 當然有了這些資訊還是不夠的，我們還需要將上下文資訊用更語義化的方式展示給使用者。因此為了更好的組織這些錯誤碼、對應的上下文資訊以及展示給使用者的描述文案，我們利用錯誤碼管理後臺來管理這些資訊。

有了這些資訊，我們在低程式碼除錯工具的日誌面板中就可以展示出非常詳細的資訊來幫助使用者找到報錯的程式碼。

比如：之前我們在控制檯中看到的錯誤，在日誌面板中展示的內容就變成了：某某某元件表示式執行出現錯誤，並給出了錯誤的原因，給出了錯誤的表示式內容，錯誤的元件 ID 等資訊。使用者通過元件 ID 就可以在低程式碼平臺中進行搜尋，就可以找到對應的元件了。也就能找到報錯的程式碼了。

對於非前端研發來說，我們幫助使用者找到錯誤的程式碼還不能完全解決問題，我們還需要告訴他們如何修改程式碼來解決錯誤。

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

當然，對於一些相對複雜的報錯案例，使用者可能還是無法自己解決問題，還是需要答疑人員的幫助。為了減少使用者和答疑人員來回溝通的成本，我們還支援使用者上傳頁面日誌，日誌中會攜帶頁面的關鍵資訊，比如說日誌內容、搭建產生的 JSON 原始碼，環境資訊等等。這樣就可以減少工單處理的時長。

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

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

• 這個元件的配置表示式是什麼？

• 這個元件展示的文案是怎麼計算出來的？

之前為了解決這些問題，使用者需要回到設計器中，找到對應的元件，檢視這個元件的配置才能解決。而對於一些複雜的配置，比如三元表示式，使用者為了找到問題，還需要在很多地方新增 Console，檢視資料來源的值。因此為了幫助使用者快速的定位到單個元件配置的問題，我們提供了元件審查功能。

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

比如這裡有一個低程式碼開發的頁面，我們需要檢視頁面中某一個按鈕的展示邏輯。

1. 我們就可以點選這個按鈕，就可以看到這個元件的詳細資訊

2. 首先展示的詳細資訊，是這個元件根據配置計算出來的值，我們可以看到這個按鈕展示的文案來源是 content 這個引數的值。

3. 第二個展示的資訊是這個元件配置的原始內容，這裡我們就可以看到 content 這個引數值實際上配置的是一個表示式，也就是 content 的值是根據 state.text 的表示式計算來的。

4. 第三個我們展示的資訊是這個元件可以訪問到的上下文資訊，比如 this.state 的值是多少，比如 this.utils 下有哪些函式等等。

這樣使用者就可以通過這個工具，一步步檢視元件引數的配置，也可以推匯出它的計算過程，如果不符合預期也可以快速的發現並知道如何解決問題。

除了剛剛提到的這兩個工具之外，我們還提供了資料來源面板和 schema 面板兩個除錯工具。

• 資料來源面板：資料來源面板可以讓使用者檢視頁面資料來源的值，並且為了方便低程式碼平臺的使用者對資料來源進行除錯，資料來源面板還支援修改資料來源的值。

• schema 面板：對於低程式碼平臺來說，所有的視覺化操作和配置，實際上操作的都是一個 json 物件，這個 json 物件我們把它叫做 schema，我們也提供了 schema 面板來檢視頁面渲染時使用的 schema 原始碼。

以上就是我們針對該低程式碼平臺建設的低程式碼除錯能力。但是它只能解決一個低程式碼平臺的問題，為了幫助更多的低程式碼平臺解決類似的問題，我們還需要提供低程式碼除錯擴充套件能力。

低程式碼除錯擴充套件能力

在阿里，將近有200多個低程式碼平臺，而剛剛我們提到的低程式碼平臺只是這裡面中的一個。那麼其他低程式碼平臺需要除錯能力嗎？肯定也是需要的，不過他們需要的不只是我們之前提到的除錯能力，他們還需要根據自己平臺的特點，來定製適合自己平臺的除錯能力。

比如，

• 有的平臺的使用者是前端，就期望能通過瀏覽器外掛來進行除錯，這樣更符合前端使用者開發除錯的習慣；

• 而有的平臺，提供的是表單搭建能力，比如說宜搭。就更需要表單相關的除錯功能；

• 有的平臺就想在除錯能力上加一個按鈕，來幫助使用者找到答疑入口。

為了滿足不同低程式碼平臺對除錯能力的訴求，我們需要在低程式碼除錯能力的基礎上提供擴充套件能力，讓低程式碼平臺可以定製對應的除錯能力。

• 外掛化：首先我們需要將除錯能力進行外掛化，外掛化的意思是將每一個除錯能力都抽象為一個外掛。這樣可以方便不同的低程式碼平臺選擇不同的除錯能力，並且可以對除錯能力進行插拔，平臺需要什麼除錯能力就可以引用對應的外掛。

• 基礎除錯能力：在將除錯能力外掛化之後，我們就可以將之前建設的除錯能力作為基礎除錯能力，並且沉澱成基礎除錯能力外掛，比如日誌除錯能力外掛、元素審查除錯能力外掛等等。

• 除錯擴充套件能力：當基礎除錯能力不滿足低程式碼平臺的訴求時，低程式碼平臺就需要利用我們提供的除錯擴充套件能力，來開發自定義除錯外掛。

• 低程式碼平臺開發者：當我們有了基礎除錯能力和除錯擴充套件能力之後，低程式碼平臺的開發者就可以基於這兩個能力開發平臺的除錯能力了。

首先低程式碼平臺開發者可以看看現有的基礎除錯能力是否適合自己的低程式碼平臺，並且選擇適合自己低程式碼平臺的基礎除錯能力。

基礎除錯能力無法滿足的部分，低程式碼平臺就需要開發對應的除錯能力外掛。自定義除錯外掛開發完成之後，就可以和基礎除錯能力組合到一起。這樣，低程式碼平臺就擁有了更適合自己平臺的除錯能力。

比如：

• 低程式碼平臺 A，就選擇了元素審查的基礎除錯能力，並且基於自己平臺的搭建特點，開發了表單除錯能力。

• 低程式碼平臺 B，就選擇的是日誌的基礎除錯能力，並開發了圖表除錯能力。

這樣不同的低程式碼平臺就可以擁有更適合自己平臺的除錯能力，這個就是我們最終期望實現的低程式碼除錯擴充套件能力，

接下來的問題是：我們要如何實現低程式碼除錯擴充套件能力，並且它還能用於幾十、上百個低程式碼平臺。

幸運的是，在我們建設低程式碼除錯擴充套件能力之前，阿里集團大部分低程式碼平臺都是基於低程式碼引擎來建設的。也就是阿里內部 200 個低程式碼平臺中，有將近 130 個低程式碼平臺是基於低程式碼引擎來實現低程式碼搭建和渲染的。

有了這個前提，我們就可以站在巨人的肩膀上，通過給低程式碼引擎這個體系提供標準的低程式碼除錯能力，以及低程式碼除錯擴充套件能力，來服務越來越多的低程式碼平臺。

正如我們之前提到的，大多數低程式碼平臺，視覺化拖拽和配置實際上都是在操作一份 json 檔案。低程式碼引擎也不例外，並且低程式碼引擎還對這個 json 檔案制定了一份標準協議，也就是「低程式碼引擎搭建協議」。因此通過低程式碼引擎建設的低程式碼平臺，在視覺化操作之後，都會產生一份符合搭建協議的 json schema。

這份 json schema 瀏覽器是無法直接進行解析渲染的，因此還需要依託於「渲染引擎」來解析 schema，將低程式碼頁面繪製到瀏覽器中。那麼這個渲染引擎是不是隻有一套呢？並不是。由於渲染引擎在繪製頁面的時候，還會用到大量的基礎元件或者業務元件，這些元件用到的技術棧可能是不一樣的，為了讓不同技術棧的物料都能渲染到瀏覽器中，渲染引擎也需要根據不同的技術棧實現多套。

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

介紹了那麼多關於渲染引擎的資訊，那渲染引擎和除錯能力是什麼關係呢？

除錯能力需要通過渲染引擎才能獲取到頁面資訊。為什麼這麼說呢，我們先看一下低程式碼頁面繪製的過程。

1. 首先低程式碼平臺通過視覺化配置，會產生一份描述頁面的 json schema。

2. 在頁面渲染的時候，渲染引擎會根據 schema 的內容繪製頁面，並且除了 json schema 之外，渲染引擎還需要知道，json schema 中描述的元件和外掛是什麼樣的。所以也需要把整個頁面會用到的元件、第三方外掛等資訊給到渲染引擎。

3. 渲染引擎有了這些資訊之後，才會在瀏覽器上繪製出來頁面。

在整個繪製過程中，瀏覽器知道 schema 的內容嗎？以及知道每一個元件的引數值嗎？實際上，瀏覽器是不知道的，因為這些執行和解析的過程都是由渲染引擎完成的。那麼除錯能力需要知道這些資訊，就只能通過渲染引擎來獲取。

• 比如說需要通過渲染引擎來獲取頁面的 schema

• 比如說需要跟渲染引擎來獲取單個元件的引數值。

因此除錯能力需要通過某種方式和渲染引擎進行通訊，比如通過 API 來進行通訊。但是正如之前我們提到的，渲染引擎根據不同的技術棧實現了多套，而每一套渲染引擎提供的 API 都有可能是不一致的。因此我們不能基於渲染引擎的 API 來開發除錯能力。

這裡為什麼說不能呢？想象一下，如果有這樣一個低程式碼平臺，它即支援PC頁面的搭建也支援 H5 頁面的搭建，但是 PC 頁面使用的可能是 React 版本的渲染引擎，而 H5 頁面使用的是 Rax 版本的渲染引擎。那麼同樣的除錯能力就需要根據兩個不同版本的渲染引擎 API 來做相容，或者說可能需要開發兩套。這肯定是不合理的，那除錯能力和渲染引擎之間就需要一個溝通的標準。

這個通訊的標準就是低程式碼除錯協議。它通過定義渲染引擎和低程式碼除錯能力之間通訊的標準，來抹平不同版本渲染引擎在 API 和實現上的差異。比如：

• 它定義了渲染引擎如何主動通知除錯能力；

• 它也定義了除錯能力如何主動通過渲染引擎獲取到相關的資訊。

這樣的好處是，

• 對於低程式碼平臺的開發者來說，他們在開發低程式碼除錯能力的時候可以不用關注頁面用的是什麼技術棧的渲染引擎。也不需要做任何相容和適配的工作；

• 對於低程式碼引擎來說，不同技術棧得渲染引擎在實現了低程式碼除錯協議之後，就可以支援所有已經開發好的除錯能力。

接下來讓我們看看除錯協議是如何進行定義的。

首先在定義協議之前，我們再來明確一下我們定義協議的目的是什麼。它的主要的目的還是用來完成除錯能力的開發。而除錯能力開發需要的主要分為兩個方面：

1.schema 獲取和操作型別

第一個是 schema 的獲取或者修改相關的操作。比如獲取整個頁面的 schema，獲取單個元件節點的引數和狀態。這些操作本質上都是在獲取或者操作 schema。

基於低程式碼引擎建設的低程式碼平臺，產生的 schema 是根據低程式碼引擎搭建協議規範生成的。因此我們操作 schema 就是操作搭建協議描述的結構。為了讓除錯能力更方便的操作搭建協議，我們將搭建協議分成了三層。

• 第一層是搭建協議的頂層結構，為了操作這一層結構，我們在除錯協議中定義了 schema 除錯域。這樣就可以通過 schema 除錯域來獲取整個頁面的 json schema 或者說修改整個頁面的 json schema。

• 第二層是搭建協議中的容器結構，容器是一類特殊的元件，在元件能力基礎上還增加了一些特殊能力，比如說它有單獨的自定義方法和資料來源。因此我們定義了 Container 除錯域來操作容器這一層結構。這樣我們就可以在除錯能力中修改容器的資料來源或者呼叫容器中的自定義方法了。

• 第三層就是搭建協議中的單個元件結構，在除錯中肯定需要對單個元件進行操作，比如說需要知道元件計算後的引數值，元件的原始配置，獲取元件的 json schema 等等。因此我們定義了 Node 除錯域來操作這一層結構。

2.輔助型別

除了獲取或者修改 schema 相關的操作之外，在除錯的時候，我們還需要一些輔助型別的操作。比如說，除錯能力想開啟一個新的瀏覽器頁面，就需要在瀏覽器視窗中執行對應的表示式。這些需要執行的表示式我們就用 Runtime 這個除錯域來進行通訊。比如，當我們審查元素的時候，需要頁面出現遮罩，來標識使用者正在檢視的元件是哪個。因此我們定義了 Overlay 除錯域來進行相關通訊。

這樣我們的低程式碼除錯協議就定義好了。接下來我們看一下根據低程式碼除錯協議，我們實際上在除錯過程中除錯工具和渲染引擎通訊的示例。

輔助型別 - Runtime 除錯域

第一個例子，是一個輔助型別的域，也就是 Runtime 除錯域。當除錯能力期望在新的瀏覽器視窗中開啟一個新的頁面時，就會發送一個 Runtime 域的 JSON，這個 JSON 中的 expression 欄位就是定義了需要執行的表示式。當渲染引擎接收到這個 JSON 之後，通過解析，就知道了它的意圖，就會執行 JSON 中的表示式，執行完成之後，也會發送一個 JSON 通知除錯面板表示式執行完成。

schema 操作型別 - Schema 除錯域

第二個例子，是關於操作低程式碼引擎搭建協議頂層結構的域，也就是 Schema 域，當 Schema 變化的時候，渲染引擎就會發送圖中的 JSON 給到除錯工具，除錯面板就能知道當前頁面的 Schema 變化了，頁面渲染的內容也就變化了，除錯能力就需要執行相關的操作，比如更新 schema 除錯面板展示的內容，更新審查面板的大綱樹等等。

低程式碼除錯協議目前基本上介紹的差不多了，我們再考慮一個問題，之前我們提到這個協議由渲染引擎來發送，但是這樣是不是合適呢？實際上是不合適的，因為對於低程式碼平臺來說，線上環境和開發環境中用的渲染引擎都是同一個，在線上環境有那麼多冗餘的程式碼是有問題的。另外這種實現方案也會讓渲染引擎有較大的改動，同時也會讓使用舊版本渲染引擎的頁面無法使用除錯能力。

那麼由誰來發送除錯協議呢，以及它又通過什麼方式來和渲染引擎進行通訊呢？

為了解決這個問題，我們新增了一個代理人的角色，這樣：渲染引擎通知除錯能力的方式就變成了，渲染引擎通過事件讓代理人知道要傳送除錯協議了，代理人就傳送對應的除錯協議。除錯工具想獲取 schema 的內容就變成了，除錯工具傳送的除錯協議，由代理人來接收，接收之後代理人就會呼叫渲染引擎的 API 來獲取 schema 的內容。得到結果之後代理人再將結果通過除錯協議傳送給低程式碼除錯工具。

增加代理人的好處是：

• 渲染引擎只需要提供相關的 API，而不需要為了除錯能力進行大規模的改動。

• 代理人只有在開發低程式碼平臺頁面時才存在，這樣就不會影響到我們的線上環境。

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

1. 首先在頁面初始化的時候，代理人會呼叫渲染引擎的 API，來註冊日誌回撥事件，相當於跟渲染引擎說，有日誌了記得通知我；

2. 當渲染引擎出現日誌的時候，就會呼叫代理人註冊的回撥函式，相當於通知代理人，有日誌了，日誌內容是某某某。

3. 代理人收到通知之後，就會發送對應的除錯協議，也就是圖中的 Json 物件。

4. 低程式碼除錯能力就會接收到對應的協議，也就可以執行相關的操作，這裡就是將接收到的新日誌展示出來。

我們已經定義好了低程式碼除錯協議，也實現了渲染引擎和除錯能力之間的通訊能力。

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

根據展示的型別，我們將外掛分為兩種：

1. Tab 型別：比如之前的日誌面板。對應圖中的黃色區域。

2. Action 型別：當點選的時候，它只會執行一些操作，比如上傳日誌，比如跳轉到答疑頁面等等。這些外掛會展示在圖中的紅色區域。

使用者可以根據自己需要的除錯能力來選擇開發不同型別的外掛。

我們現在基本上已經實現基本的除錯擴充套件能力了，為了讓低程式碼平臺可以更便捷的開發低程式碼平臺除錯能力，我們還提供了除錯相關研發的工具鏈，讓使用者可以初始化開發外掛，除錯外掛以及整合外掛。除了工具鏈之外，我們還提供了更方便的 API 來操作除錯協議，這樣使用者開發除錯能力的時候就不用寫 JSON 了。

這樣我們的低程式碼除錯擴充套件能力就建設完成了。

低程式碼除錯能力實踐

在阿里的這款中後臺低程式碼平臺中，使用除錯能力的月活躍使用者有 300 人，平臺的答疑量降低了 10% 左右。

其中一些簡單的答疑基本上已經消失了，比如說由於跨域，一些介面請求會出現錯誤，之前也有很多同學因為這類問題找到我們答疑同學，現在之類答疑已經沒有了，並且由於元件表示式配置錯誤，而導致的頁面報錯，這種型別的答疑也少了很多。

此外，阿里對外的商業化低程式碼平臺，釘釘宜搭，由於大多數搭建場景是在搭建表單頁面，他們也根據表單頁面的特點，擴充套件了對應的除錯能力。可以支援查看錶單資料和錯誤請求。

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

下一步我們還會建設更多的基礎除錯能力：

• 比如使用者在低程式碼中寫的 JS 程式碼，我們可以在除錯工具中檢視和除錯對應的 JS 程式碼。而不是需要回到設計器中才能檢視。

• 比如可以在除錯工具中檢視頁面的資料來源請求資訊。

• 比如可以檢視頁面或者容器生命週期的執行等等。

此外，我們還會提供更多的低程式碼除錯容器：

• 比如 Web 容器，適合提供給非前端研發同學來使用。

• 比如瀏覽器外掛容器，適合提供給前端研發來使用，更適合前端研發同學的除錯習慣。

• 比如說客戶端除錯容器，提供給一些特殊除錯場景來使用，比如用於移動端除錯場景。

最後，我們也需要讓更多的渲染引擎支援低程式碼除錯能力，比如我們低程式碼引擎中不同技術棧的渲染引擎，React 版本的渲染引擎和 Rax 版本的渲染引擎，以及未來由社群支援的 Vue 渲染引擎。

歡迎關注阿里低程式碼引擎，瞭解更多低程式碼相關技術。也歡迎到低程式碼引擎官方微信群進行更多交流，加微訊號 wxidvlalalalal 並備註「低程式碼引擎，申請入群」即可。