前端渲染函數調用圖工具的設計與實現

孫衛真，孫 星，向 勇

(1.首都師范大學 信息工程學院，北京 100048；2.清華大學 計算機科學與技術系，北京 100084)

0 引 言

在分析復雜結構軟件或操作系統內核時，研究者會關注各模塊及函數之間的關系，借助源碼分析工具可以減少人工分辨模塊關系。傳統分析工具如LXR[1]、Kythe[2]通過檢索源碼，建立索引關系，以標記和鏈接的方式輔助分析。文獻[3]靜態數據獲取使用基于寄存器傳送語言方式，讀取內核編譯中間結果，形成更準確的調用關系。為更好表現模塊及函數間的調用關系，有研究和工具運用流程圖或有向圖[4]等方式展現。隨著Web技術的廣泛應用與在線工具的出現，用戶能夠在線進行源碼分析工作，減少研究者本地部署的操作，文獻[5]使用數據庫存儲調用數據，Web服務器讀取數據并渲染SVG格式的函數調用圖，通過靜態頁面展現。但服務器處理和渲染過程計算量大，傳輸數據存在大量冗余，導致等待時間過長。因此提高數據處理和渲染速度，減小傳輸數據量，能夠提高函數調用圖的生成速度。

本文工作概括如下：

(1)使用DBCG-RTL(date based call graph tool based on RTL)數據獲取方法，更新運行環境，生成新版本內核調用數據，存儲在MySQL數據庫中，用于服務器數據獲取；

(2)基于Node.js使用egg.js框架搭建API服務器，使用異步方式處理并返回客戶端所需數據；

(3)基于Vue.js搭建頁面，使用Antv-G6可視化庫，實現在線函數調用圖模塊，動態加載圖數據并更新調用圖；

(4)使用Linux-4.15.18 x64內核數據，對DBCG-RTL與FRCG工具進行測試，結果表明FRCG工具生成50節點以下函數調用圖時，平均減少60.09%等待時間，平均減少92.24%傳輸數據。

1 相關工作

在內核源碼的分析過程中，由于Linux源碼版本多、文件和函數間交叉引用數量巨大。傳統工具LXR[1]、Kythe[2]等通過檢索源碼，識別函數定義與調用的文件位置進行記錄，以鏈接方式展示調用關系，但大型項目或內核中存在大量同名函數，掃描靜態源碼，無法準確匹配調用函數，只能提供索引列表。

借助可視化工具，能夠更直觀查看函數調用關系。毛等[3]開發了DCG-RTL工具，將內核二次編譯讀取調用關系數據與模擬器動態監控數據結合，構建內核調用關系圖，但其采用文件形式存儲，在渲染過程中，查找速度較慢。在此基礎上，賈等[5]開發了DBCG-RTL工具，使用數據庫存儲函數調用關系，提高查詢速度，并將函數調用圖和函數調用列表等模塊集成在LXR的Web服務器中。由于LXR為服務器渲染生成頁面，數據讀取、處理與調用圖、頁面的渲染都在服務器上進行，造成計算量大，等待時間長等問題。同時頁面渲染和數據處理代碼耦合在一起，加大了維護和拓展的難度，造成工具難以移植和更新。

針對Web服務器處理時間長的問題，有研究人員對不同服務器進行對比，Chitra等[6]對比Node.js和傳統Web服務器性能，得出Node.js服務器具有輕巧高效的特點；Chaniotis等[7]對Apache，PHP，Node.js和Nginx進行性能分析，指出Node.js在內存和CPU的利用率明顯優于Apache 和PHP，并提出將Nginx與Node.js結合的框架，用于開發具有模塊化、實時信息通訊和拓展性強等需求的Web應用；有研究人員基于Node.js實現前后端分離的平臺系統，朱等[8]使用基于Node.js的Koa后端框架和Vue.js前端框架，對物流信息管理系統進行研究與實現，通過Node.js非阻塞I/O、事件驅動等特性，實現較快的頁面加載時間。Eric Wohlgethan[9]對Angular、React、Vue.js前端框架進行了分析，總結Vue.js用于開發單頁面應用，學習成本低，同時框架實現數據和視圖的雙向綁定，視圖的更新由框架提供，開發過程只需要專注于數據的處理。

對于數據可視化，DBCG-RTL工具[5]處理調用圖數據后，使用Graphviz工具渲染生成SVG圖，該工具語法簡單，能夠自動布局節點分布。但腳本進行渲染和布局的速度慢，同時會增加服務器計算壓力；生成SVG中包含渲染后屬性，增加傳輸的數據量。基于前端可視化實現主要有：Cytoscape.js[10]是一個開源關系圖可視化庫，提供多種布局方式，功能完善，但其視圖操作基于選擇器實現，不適用在Vue模塊化的前端框架中；Echarts[11,12]為百度團隊開發的前端圖庫，支持基礎圖表，也支持樹圖、關系圖等，具有良好的可視化效果，但其對于關系圖的支持較為不足，需要自行實現相關功能；冉等[13]基于Echarts模塊，對專利數據進行可視化處理；AntV[14]作為阿里旗下螞蟻金服可視化解決方案，將不同類別圖進行了不同的劃分，G2可視化、G6圖可視化、F2移動可視化、L7地理空間可視化。其中G6對圖的數據關系，具有完善的功能支持，能良好兼容Vue模塊化前端框架，文檔豐富，便于二次開發；文獻[15]使用G2圖庫開發了LnCompare，可以對長非編碼RNA數據進行在線可視化分析。

本文目的是提高分析工具調用圖的生成速度，使用前后端分離方式，將數據處理和可視化獨立到前后端完成；轉移服務器渲染調用圖的計算量，從而提高數據處理速度，減小前后端傳輸數據量；前端頁面使用Vue框架降低頁面框架內容實現難度，調用圖使用AntV-G6實現調用數據的可視化，動態渲染調用圖，解決DBCG-RTL[5]調用圖渲染時間過長的問題，并提高調用圖的靈活性。同時前后端統一開發環境，降低工具拓展和維護難度。

2 FRCG工具總體框架

基于前后端分離思想，FRCG函數調用圖工具主要由Node.js搭建的API服務器和Vue.js搭建的單頁面應用兩個部分組成，通過docker容器進行部署，如圖1所示，框架分為MySQL、Node和Nginx這3個容器。Nginx容器提供頁面文件Web服務和對API接口的反向代理，Node容器提供處理API接口請求的服務器，MySQL容器作為數據存儲。

(1)MySQL容器：使用DBCG-RTL[5]方法，生成Linux 4.15版本之后內核調用數據，存儲在MySQL數據庫中。Node.js服務器從中查詢所需要的內核數據。

(2)Node容器：基于Node.js的egg.js框架搭建API服務器，使用異步方式處理請求內容和查詢數據庫，并將數據轉換成對應格式，作為請求的返回數據。為前端頁面提供數據接口。

(3)Nginx容器：基于Vue.js搭建的單頁面應用通過打包形成靜態頁面文件，使用Nginx部署頁面資源。用戶使用瀏覽器訪問，獲取頁面文件到本地瀏覽器中渲染執行，頁面中調用圖、調用表等模塊使用Http請求服務器對應API接口獲取數據，得到數據后，頁面腳本進行可視化渲染。作為FRCG工具的主要展現方式。

圖1 FRCG總體框架

圖2 服務器框架

3 服務器主要接口設計與實現

Node.js服務器框架，主要分為路由、控制器、服務、插件這4部分組成，如圖2所示。

路由(Router)中定義了接口URL對應的控制器模塊，根據獲取數據的不同設計為3種接口，分別是函數調用圖接口/graphs用于獲取調用圖數據；函數調用表接口/functions用于獲取調用表數據；配置信息接口/options用于頁面獲取配置模塊所需數據，實現頁面登錄和菜單列表功能。

控制器(Controller)負責解析路由分發請求中包含的參數，調用驗證插件進行合法性驗證，提取請求中的數據作為參數，調用對應的服務模塊函數進行數據處理，返回響應數據。

服務(Service)負責處理數據，簡化控制器代碼，獨立數據的處理函數。模塊根據調用參數，進行數據查詢和特定規則的計算，生成所需數據，根據需求寫入數據庫并返回給控制器。

插件(Plugin)主要為官方或三方實現的功能模塊，如安全驗證、數據驗證、MySQL訪問等。

3.1 API設計

根據頁面模塊所需數據為調用圖的節點及邊數據和調用表的詳細數據，將服務器API接口設計為獲取調用圖數據的API接口和獲取調用表數據的API接口。

3.1.1 調用圖API設計

頁面調用圖所需數據主要為：獲取對應內核版本、編譯環境下，兩個路徑間的調用關系圖數據；獲取調用圖中某節點下一級節點與當前圖中節點調用關系的圖數據；上傳調用圖數據，存儲并返回分享id；獲取分享id對應的調用圖數據。

根據頁面需求調用圖API需要實現：依據請求參數返回調用圖數據、存儲請求中上傳的調用圖數據并返回存儲id、獲取對應id的調用圖數據。具體接口定義見表1。

表1 調用圖API定義

根據生成內核函數調用圖的不同，需求的參數列表見表2。請求中包含內核版本、平臺、生成調用圖的源路徑、目標路徑的必須參數，根據調用圖的功能不同，請求中可以增加配置參數：用于獲取不顯示同級路徑調用圖的per參數、用于獲取展開節點數據的id、expand和expanded參數。

表2 調用圖API參數

服務器讀取參數后，根據配置進行數據處理，以JSON格式返回，返回數據中，包含圖id、節點數據、邊數據等。以請求Linux-4.15.18內核fs和mm模塊返回數據為例，部分內容如代碼1所示。

代碼1：調用圖返回數據

params: {

id: "4-15-18 x86_64 /fs /mm"

data: {n

nodes:[

{id: "/mm/gup.c", type: 0},

…

],

edges:[

{source: "/mm/gup.c", target: "/fs", sourceWeight: 8, type: 2},

…

]

}

}

3.1.2 調用表API設計

頁面中調用表需要內核版本、編譯環境下，兩個路徑間的調用數據，同時為了實現源碼跳轉功能，會獲取某個函數的詳細數據。調用表API功能簡單，主要為獲取路徑間調用表和獲取函數定義，具體定義見表3。

表3 調用表API定義

請求中需求參數為內核版本、平臺、源路徑、目標路徑，見表4。請求返回數據中包含函數調用的數據：源函數名、源函數所在文件、行號、調用行號、目標函數名、目標函數所在文件、行號、調用次數等。

表4 調用表API參數

3.2 API實現

服務器中請求處理過程相似，流程為路由分配，控制器調用服務生成數據并返回響應數據。不同模塊控制器會根據功能需求對數據進行驗證，調用對應服務進行處理，通過不同的處理方式，生成不同請求所需的數據。

3.2.1 調用圖數據處理實現

客戶端請求經路由分配到使用GET方法的/graphs接口后，處理過程如下：

(1)控制器處理請求：控制器驗證請求數據，驗證通過后，控制器提取請求數據作為參數，調用對應服務進行處理;

(2)服務模塊讀取調用參數：獲取參數中的內核版本、平臺和路徑等數據，并讀取非必須的配置項，用于區分所需函數調用圖功能，如：存在expand屬性則此請求為對現有函數調用圖節點展開數據的請求，存在per屬性為false則此請求為不需要同級節點數據的內部函數調用圖。對于無額外配置項的參數，默認為獲取對應內核版本下兩路徑之間的函數調用圖;

(3)初始化配置數據：使用參數中的內核版本等數據，初始化調用圖配置數據，如查詢數據庫的表名、圖id等;

(4)檢索歷史數據庫：根據初始化后的圖id，檢索歷史數據中是否存在該圖數據，若存在歷史數據，將數據返回給控制器。若無歷史數據，則通過異步方式查詢數據庫生成調用圖數據，將生成數據返回給控制器，并寫入歷史數據庫;

(5)返回數據：控制器得到服務文件返回數據，作為請求數據返回給客戶端，請求處理完成。

過程優化:

DBCG-RTL中計算調用圖數據主要過程為：

(1)查詢靜態函數定義表(FDLIST)，獲取源路徑和目標路徑的下級路徑。若輸入為路徑，下一級則為子路徑DBCG-RTL或文件，若輸入為文件，下一級為文件內函數名。同時使用遞歸方式逐級查找同級和上級路徑。將查找到的路徑，所屬類別轉換成節點集合;

(2)得到節點的集合后，依次遍歷節點集合中不同的兩個節點，查詢靜態外部引用列表(SOLIST)獲取兩個節點間的調用次數;

(3)函數調用圖所需數據查詢完畢，需要對數據格式進行處理，生成符合Graphviz需求格式的數據;

(4)針對調用圖計算過程中，對調用關系的大量查詢，本文采用異步處理方式提高處理速度；同時前后端統一使用JSON數據傳輸，減少傳輸圖數據的大小。

提高計算速度:

查詢節點間的調用關系可以看作查詢N節點的有向圖，遍歷不同節點間的調用關系需要進行復雜度為O(N2)的查詢。DBCG-RTL通過Ruby腳本線性執行SQL語句直接查詢MySQL數據，本文通過egg-mysql插件代理訪問，線性執行相同的查詢操作，處理時間比Ruby腳本慢。

基于Node.js的事件循環和非阻塞I/O機制：對于連續的查詢操作，Node.js將其視為一組事件隊列，依次執行其中的查詢操作。在發起查詢數據庫操作后，不會阻塞查詢的繼續執行，而是將返回數據的操作放在回調函數中，并繼續下一次查詢。當數據庫查詢操作返回結果后，將處理數據的回調函數插入事件隊列，等待執行。Node.js會不斷檢查當前事件隊列，并以一定順序去執行各類回調函數。

而在處理請求所需的節點調用數據過程中，通過異步方式發起查詢，在回調函數還未執行時，請求處理函數就已經執行完成并返回，造成返回數據列表為空的情況。為解決返回數據為空的問題，本文構造Promise對象列表，每個Promise對象為查詢數據庫中兩節點間的調用頻度函數，數據返回后通過回調函數將調用數據添加到邊數據列表中。執行Promise.all(list)函數，實現以非阻塞的方式執行對象列表中全部查詢，以阻塞的方式執行回調函數，得到全部節點間的調用數據。同步執行和異步讀取結合，提高數據獲取速度。

減小數據大小:

DBCG-RTL生成的SVG圖，節點和邊存在大量未進行優化的冗余內容和渲染屬性數據，導致傳輸數據較大；Node.js服務器提供處理后的圖數據，只包含節點和邊的基礎屬性數據，如節點id、節點類型、邊類型、邊源和目標等數據，能夠大幅度減少傳輸數據。如圖3所示：本文分離頁面文件和數據的傳輸，減小了每次請求所需的頁面文件，調用圖數據由頁面動態請求；前后端使用JSON格式傳輸數據，減小SVG中的渲染數據和XML標簽結構數據，降低傳輸數據大小，提升傳輸速度。

圖3 傳輸內容對比

3.2.2 調用表數據處理實現

Get/functions接口數據處理流程與調用圖處理流程相似，具體差異在數據的查詢和處理部分。

調用表數據查詢過程與DBCG-RTL方法相似，查詢SOLIST表得到兩路徑之間存在調用關系的函數、所在文件和調用次數；根據函數名和所在文件查詢FDLIST表，得到函數在數據庫中的id和文件內起始行號；根據源函數id和被調用函數id查詢SLIST表得到全部調用行號。

過程優化:

計算調用表數據優化與調用圖優化相似，使用異步處理大量查詢。處理流程中查詢SOLIST可以得到調用關系數據，數據中缺少函數定義數據和調用行號數據；函數定義數據，通過構造Promise對象實現異步查詢FDLIST表，得到函數在數據庫中的id和文件內起始行號；調用行號數據，通過構造Promise對象實現異步查詢SLIST表得到全部調用行號。使用Promise.all()函數同步得到全部查詢結果。

4 調用圖頁面實現

前端頁面作為FRCG工具的主要展示途徑，提供了可交互的調用圖和詳細數據的調用表。同時提供自定義布局模塊，實現對調用圖和調用表模塊布局的自定義。頁面各部分框架如圖4所示，本文通過EventBus構建事件總線，完成調用圖組件對其它組件的事件傳遞，實現調用圖的復雜交互功能。

圖4 頁面交互事件

調用圖頁面中，用戶通過選擇器組件修改頁面配置數據(config)，此配置作為頁面子組件：調用圖組件和調用表組件的輸入參數。圖組件中用戶的操作，如點擊右鍵菜單執行切換調用圖，會向頁面發布修改配置數據的事件，觸發頁面修改對應配置數據，調用圖組件會根據輸入配置參數的變化，更新圖數據重新渲染生成調用圖。

4.1 選擇器組件

圖頁面的一組選擇器，供用戶配置圖所需的參數：內核版本、內核平臺、源路徑、目標路徑、僅顯示內部節點、圖布局方式。內核版本及平臺等數據，在頁面初始化過程中，會向服務器請求獲取，用戶選擇版本內核后，會動態加載對應內核的路徑數據。這些數據存儲在內存中，切換同一內核版本調用圖時，能夠直接獲取內核版本數據；切換不同內核調用圖時，當選擇器選中后，會更新內存中的內核版本數據。

組件中選中的配置數據，綁定到圖組件和表組件的輸入參數，當調用圖顯示時，用戶通過選擇器組件更改配置數據，會觸發調用圖的更新。

4.2 自定義布局組件

在頁面中引入Vue-grid-layout組件實現拖拽布局，將調用圖模塊和調用表模塊嵌套在布局組件中，并綁定布局組件大小變化事件到調用圖組件size傳入數據上，通過調用圖組件中監控size變化，執行調用圖的更新寬高函數。自定義布局可以改變調用圖和調用表大小和位置，默認頁面布局為上下兩部分，用戶通過改變模塊尺寸，拖拽模塊等操作來實現左右或交換上下位置的布局。

4.3 調用圖組件

圖組件接收頁面傳入的配置數據(config)，用戶通過選擇器選擇配置時會更新圖組件傳入的config，當配置項完整后頁面才會顯示圖組件，避免由于配置數據不完整而造成請求調用圖數據失敗。

調用圖組件由：篩選開關組件、G6圖組件、右鍵菜單組件、彈窗組件組成。

(1)篩選開關組件：通過一組開關組件，綁定一組篩選配置數組，用于過濾圖中不同種類邊，輔助使用者找到分析的目標節點和調用邊，提供分類有：源為非所選路徑節點、目標為非所選路徑節點、源路徑節點到目標路徑節點、目標路徑節點到源路徑節點、源路徑節點到源路徑節點、目標路徑節點到目標路徑節點。開關組件綁定數據改邊時，會對當前調用圖中全部邊進行遍歷，根據篩選配置數組，編輯邊的顯示屬性。同時，當調用圖更新時，也需要對邊的顯示屬性進行檢查;

(2)G6圖組件：作為調用圖組件的主體，用于顯示函數調用圖，還包含大量圖交互事件，如右鍵彈出對應菜單；鼠標覆蓋節點和邊進行高亮相關元素；拖拽移動圖和節點；縮小放大調用圖等;

(3)右鍵菜單組件：作為切換和跳轉的主要途徑，如圖所示組件中包含大量傳遞給其它組件的事件，為統一事件傳遞方式，采用EventBus(事件總線)進行傳遞，由組件根據用戶點擊菜單內容，向總線中發布事件，其它組件訂閱相應事件，執行相應操作;

(4)彈窗組件：用于顯示錯誤信息及顯示分享圖的鏈接信息。

4.4 調用表組件

調用表組件接收頁面提供的config，其中包含內核版本、平臺、源路徑、目標路徑，當配置項完整時，使用element-ui中的表格組件進行渲染，在組件聲明表格列，并配置列的屬性項如：列排序依據、列內元素類型等。當列內元素為按鈕類型時，需要在列中定義按鈕組件，并傳遞數據顯示，綁定函數實現點擊行號跳轉源碼頁面操作。

通過調用圖邊的右鍵菜單發出事件show function list、頁面補全調用表配置、渲染顯示調用表。

4.5 主要功能實現

調用圖組件基于G6模塊實現，通過定義初始化函數，對調用圖的顯示和交互進行定制和拓展，通過G6模塊提供的函數，實現更新數據、渲染調用圖、保存當前圖數據等功能。FRCG實現對圖數據的更新、添加和拷貝，調用圖的顯示、切換、局部更新和服務器備份等功能，對比DBCG-RTL通過靜態圖文件的方式展示調用圖，FRCG基于數據的操作具有更多靈活性，同時數據能夠進行二次利用和分析，具有更多的拓展性。

4.5.1 調用圖實現

用戶通過選擇器組件配置完整后，圖組件進行渲染顯示，生成調用圖過程如下：

(1)圖組件將輸入的配置參數進行處理，提取并保存為內部配置;

(2)初始化G6圖組件，綁定圖組件內部響應事件，如鼠標覆蓋高亮、提示框彈出、右鍵菜單彈出與關閉等;

(3)根據當前配置數據，向服務器發起圖數據請求，得到返回數據后，對數據進行處理，根據節點id信息，增加節點label屬性，用于提示框顯示，根據節點和邊的type屬性，為節點和邊增加顯示顏色;

(4)將處理后的數據加載到G6圖組件中，調用組件render()函數渲染調用圖;

(5)模塊會監控輸入配置參數，當屬性發生變化時，根據配置參數獲取新的調用圖數據，調用組件data()方法更新數據，并使用render()方法重新渲染調用圖。

4.5.2 局部更新數據

將函數調用數據作為操作對象后，調用圖的更新能夠通過增加部分數據，達到增量更新的效果。在請求數據時，配置非必須參數：id、expand、expanded，用于獲取符合對應圖中展開節點后的新增數據。頁面通過事件總線將更新函數綁定右鍵菜單中的節點展開按鈕，展開節點時，調用圖組件會遍歷當前圖中節點與邊，刪除被展開節點與相關聯的邊，以代碼2所示請求數據向服務器請求展開節點數據：

代碼2：請求數據

params: {

version: "4-xx-xx",

source: "/xx",

target: "/xx",

id: "4-xx-xx /xx /xx",

espand: "/xx/xx"

}

得到請求返回的數據，將數據和現有數據合并，使用合并后的數據重新渲染調用圖，實現增量更新展開節點。

需要注意的是，當圖中存在多個展開節點時，頁面會提示“存在多個展開節點，展開節點之間的邊不會顯示”當圖中展開節點，達到3個時，將會彈出錯誤提示，并拒絕繼續加載新的展開節點。

4.5.3 分享調用圖

通過G6模塊graph.save()方法，可以保存當前圖中的節點數據，數據中包含節點坐標等渲染后的圖數據。將此數據上傳到服務器，實現保存特定調用圖的目的。在調用圖中，通過右鍵彈出菜單選擇分享圖。點擊后，頁面將通過G6圖中graph.save()函數獲取當前圖中節點和邊的詳細數據，對數據進行過濾，只將當前圖的必要數據上傳給服務器。服務器收到數據進行存儲，將圖的版本、源路徑和目標路徑等標志信息進行MD5處理，得到哈希值作為數據的索引，返回給頁面此哈希數據。頁面補全URL路徑生成分享鏈接，并彈窗顯示分享鏈接。

在新的頁面中打開分享鏈接，頁面初始化過程中會根據URL中包含的哈希數據，向服務器獲取分享頁面的配置和圖數據。獲取到數據后會先根據數據中的原有配置更新頁面和圖配置，將頁面得到圖數據通過圖組件的ex_data進行傳遞，同時將圖配置的ex屬性設為true。圖組件初始化后，加載數據時ex屬性為true則使用外部數據，保存的圖數據具有節點坐標，在圖渲染完成后，會使用數據中的坐標信息更新節點位置，使接收方查看的圖與分享方圖一致。

5 應用實例

研究Linux系統的啟動過程是對其優化和定制的基礎，通過分析平臺輔助去了解和認識啟動函數，圖形化的調用圖、詳細的調用表與源碼結合，更直觀認識模塊調用和函數信息。

內核啟動函數start_kernel所在文件為/init/main.c，在FRCG工具頁面中，選擇內核版本和平臺，通過輸入查找，快速找到源路徑/init/main.c，目標路徑選為/，配置完整調用圖自動加載，使用調用圖篩選和拖動等功能，實現調用如圖5所示，鼠標停留在啟動函數節點上，高亮顯示關聯模塊和函數節點，無調用關系路徑和函數節點透明度降低，排除干擾。

圖5 內核啟動函數調用

對于需要分析的模塊，可以通過右鍵菜單中節點展開、查看函數調用表等，獲取詳細信息。如圖6為查看start_kernel函數中對fs模塊的調用表。

圖6 啟動函數對fs模塊的調用列表

調用表中點擊所在文件和行號列內容可以在新頁面顯示對應源碼，提供研究者分析模塊間調用關系的同時快速確定源碼中函數所在位置及模塊間調用關系。

FRCG工具使研究人員快速查看函數調用關系，區分模塊間是否存在調用，跳轉查看文件或函數源碼。傳統源碼分析平臺，對于調用的函數無法提供詳細信息，遇到重名函數時，檢索函數，并羅列出該函數名的全部定義和調用，用戶需要自行區分，找到當前文件中對應的函數位置，進行查看。

函數調用圖模塊的鏈接源碼功能，源數據確定的函數調用，包含函數的文件路徑和所在行等信息，用戶可以在右鍵菜單中選擇查看對應源碼，平臺會跳轉到當前顯示節點的源碼位置，用戶無須分辨重名函數。

6 評估與比較

本文FRCG工具針對DBCG-RTL靜態函數調用圖部分使用前后端分離方式重構優化，保留原有靜態調用圖部分全部功能，并大幅提高調用圖生成速度，增加系統部署的靈活性。本文使用i5-6500，8 G RAM，Win10-1909搭建測試平臺，使用VMware 15，分配4核，4 GB內存虛擬機運行Ubuntu 1804操作系統、Node.js 12.16.2、MySQL 8作為服務器；測試數據為Linux-4.15.18內核在x64平臺下的頂層路徑之間調用關系。

6.1 調用圖顯示總時間

根據調用圖從請求到查看流程，DBCG-RTL中包含服務器Ruby腳本查詢數據庫、處理數據、服務器Ruby腳本渲染SVG圖、網絡傳輸和用戶瀏覽器顯示，本文測試階段忽略瀏覽器渲染SVG圖時間，將處理、渲染、傳輸的分段時間進行統計；FRCG工具包含Node.js服務器讀取數據庫并處理、請求數據傳輸和前端頁面渲染生成調用圖，將處理、傳輸、渲染的分段時間進行統計，結果如圖7所示。

由于DBCG-RTL工具Ruby腳本在查詢數據庫階段為線性執行，大量查詢等待時間堆積造成處理時間過長，而渲染階段需要先生成中間文件，存儲到文件系統，調用外部腳本處理生成為SVG圖格式，再次寫入文件存儲，最后讀取文件進行返回。多次文件讀寫和外部腳本調用，隨著文件容量的增加造成過長的等待時間。而FRCG工具，實現異步讀取數據庫，提高查詢速度，查詢完成后直接轉換為JSON格式返回，內存級數據讀寫，大幅提高處理速度，同時渲染過程在客戶端進行，不占用服務器的計算資源，服務器能夠更快返回數據。

對更大范圍路徑進行測試，將工具階段時間匯總，統計處理、渲染、傳輸的總時間，對比結果如圖8所示。

圖8 總時間對比

增加冪函數回歸[16]趨勢線輔助觀察數據變化趨勢，如圖8所示，FRCG處理總時間低于DBCG-RTL總時間。隨元素數上升，總時間差距越大。查看統計數據，當前測試平臺下全部測試路徑內：DBCG-RTL工具總時間平均為273 288 ms，即4 min 33 s，而FRCG總時間平均為3125 ms即3.1 s。耗時最長的路徑fs-kernel DBCG-RTL渲染階段用時5222.512 s，長達1 h 27 min，而FRCG處理總時間，只有11.818 s，FRCG處理速度明顯快于DBCG-RTL工具。

6.2 傳輸數據大小

對比兩工具傳輸數據，DBCG-RTL生成的SVG圖，存在如點擊響應的鏈接和渲染后的坐標信息等冗余內容，同時XML的標簽結構數據隨著元素數量上升而增加，導致數據量大；Node處理后的圖數據，只包含節點和邊的屬性信息，節點和邊的跳轉事件由頁面動態創建，節點和邊無需存儲跳轉鏈接數據。同時圖的渲染由頁面組件實現，數據中無需包含渲染坐標等信息。實現大幅度減少傳輸數據，并隨著圖上元素數量的增多，傳輸數據量減小的比例更大。

對數據減小率散點數據，如圖9所示，增加冪函數回歸[16]趨勢線輔助，隨著圖中元素數量增加FRCG傳輸數據減小比例越大，對于全部測試路徑，最小減少90%傳輸數據大小，平均減少93.53%傳輸數據大小。

圖9 數據減小比

6.3 考慮服務器緩存進行對比

Node.js服務器開啟歷史記錄，將歷史數據寫入數據庫，并設置過期清除。對比無歷史數據時，平均減少72.64%等待時間。

考慮SVG圖靜態內容存放在服務器中，用戶訪問已有SVG圖時，直接獲取資源。對比用戶查看已有SVG圖和存在歷史記錄的Node.js服務器的加載時間最值見表5，平均時間差為506 ms。

表5 DBCG-RTL與FRCG調用圖加載時間最值對比/ms

在實際分析工作中，研究人員需要經常查看的調用圖大概率存在歷史緩存，而詳細路徑下函數關系圖存在緩存的概率較低。故對研究人員連續查看多個路徑函數調用圖的情況進行模擬，假設部分路徑存在歷史數據，部分路徑沒有歷史記錄需要計算，隨機取10，20，30，40個路徑，每個路徑存在歷史數據概率為20%，50%，80%，90%，100%，重復10次取平均得到實驗結果如圖10所示。

圖10 服務器存在歷史記錄的加載時間對比

當緩存概率大于90%時，DBCG-RTL工具才能比FRCG工具更快顯示。連續多次查看存在歷史緩存的調用圖時，SVG圖的獲取時間明顯快于FRCG工具，但SVG圖中包含大量冗余數據，全部存儲會占用大量存儲空間。而FRCG工具，能夠在犧牲少量加載時間的情況下，減少歷史記錄所占用空間，同時對于查看無緩存的調用圖，FRCG能夠大幅提高加載速度。

綜上所述，FRCG工具在調用圖的數據計算和渲染速度上優于DBCG-RTL，同時網路傳輸數據量更小。DBCG-RTL的優勢在于能夠存儲靜態調用圖進行顯示，FRCG使用緩存數據時，仍需在頁面中渲染生成調用圖，查看調用圖過程無法避免頁面的渲染過程。

7 結束語

本文將前后端分離框架與分析工具結合實現FRCG工具，將調用圖的生成過程，拆分為后端處理數據，前端渲染調用圖，平均減少了83.02%的調用圖等待時間。服務器處理階段，采用Promise對象異步讀取數據庫，提高圖數據的處理速度，同時優化傳輸的數據結構，平均減小93.53%傳輸數據量。前端頁面通過對數據操作實現切換調用圖和增量更新調用圖，提高了調用圖的靈活性。

FRCG工具主要實現靜態調用數據的處理和展現，源碼查看由鏈接外部頁面實現，要形成完善的分析工具，需要將多種分析工具整合到工具中，下一步工作目標為增加源碼模塊，并實現源碼模塊與調用圖和調用表的有效結合；同時增加系統監控模塊，通過動態監控工具，實現顯示運行中系統調用，力求實現靜態分析與動態分析的結合。