只有通過別人的眼睛，才能真正地了解自己 ——《云圖》

背景

作為全球最大的互聯(lián)網(wǎng) + 生活服務(wù)平臺，美團點評近年來在業(yè)務(wù)上取得了飛速的發(fā)展。為支持業(yè)務(wù)的快速發(fā)展，移動研發(fā)團隊規(guī)模也逐漸從零星的小作坊式運營，演變?yōu)榍思壯邪l(fā)軍團協(xié)同作戰(zhàn)。

在公司蓬勃發(fā)展的大背景下，移動項目架構(gòu)也有了全新的演進方向：需要支持高效的集成策略，支持研發(fā)流程自動化等等，最終提升研發(fā)效能，加速產(chǎn)品迭代和交付能力。

雖然高效的研發(fā)交付體系幫助 App 項目縮短了迭代周期，但井噴式的模塊發(fā)版和頻繁的項目集成，使得純?nèi)斯さ捻椖烤S護和質(zhì)量保證變得“獨木難支”。

上圖漫畫中，列舉了大型項目在持續(xù)優(yōu)化和維護過程中較為常見的幾類需求。這些需求主要包括以下幾個方面：

在 CI 流程中加入靜態(tài)準入檢查，避免繁瑣的人工 Review 以及減少人工 Review 可能帶來的失誤。

為了推進項目的優(yōu)化過程，需要方法數(shù)監(jiān)控、宏定義分析等代碼分析報表和監(jiān)控。

零 PV 報表、依賴分析和頭文件引用規(guī)范、無用代碼分析等項目優(yōu)化方案。

不難發(fā)現(xiàn)，這些需求的本質(zhì)是：借助代碼靜態(tài)分析能力，提升項目可持續(xù)發(fā)展所需要的自動化水平。針對 C/Objective-C 主流的靜態(tài)分析開源項目包括：Static Analyzer、Infer、OCLint 等。但是，這些分析工具對我們而言存在一些問題：

• 開發(fā)成本高，收益有限，研發(fā)參與積極性不夠。
• 針對局部代碼分析，跨編譯單元以及全局性分析較難。
• 增量分析困難，CI 靜態(tài)檢查效率低下。
• 工具性較強，大部分只作代碼規(guī)范檢查，應(yīng)用范疇局限。
• 接入和維護成本高，難以平臺化。

針對以上背景和現(xiàn)有方案的不足，我們決定自研基于語義的靜態(tài)分析框架。

Hades 項目簡介

大眾點評靜態(tài)分析框架 Hades，取名源于古希臘神話中的冥王。冥王 Hades 公正無私，能夠?qū)徱曥`魂的是非善惡。

Hades 框架支持語義分析能力，我們希望這種能力不僅僅能夠去實現(xiàn)一個傳統(tǒng)的 Lint 工具，而且能成為創(chuàng)造更多能力的基礎(chǔ)，可以幫助我們更輕松地審視代碼，理解把控大型項目。

Hades 方案選型

文本處理方式

首先，最簡單的靜態(tài)分析是字符匹配和文本處理。這種方式雖然實現(xiàn)簡單，但是存在能力上限，也不可能在語義理解上有足夠的把控力。另外，以正則匹配為核心建立的工具棧難以得到持續(xù)優(yōu)化。為了分析項目的依賴關(guān)系，我們需要判斷代碼中的符號含義以及符號間關(guān)系（如包含哪些類，類中有哪些方法等），分析過程的正則表達式如下圖所示。

由此可見，繁瑣的文本匹配不僅可讀性差，也存在容易分析出錯的問題。

基于編譯器的靜態(tài)分析方案

我們需求的本質(zhì)是對代碼進行分析，而在源代碼編譯過程中，語法分析器會創(chuàng)建出抽象語法樹（Abstract Syntax Tree 縮寫為 AST）。AST 是源代碼的抽象語法結(jié)構(gòu)的樹狀表現(xiàn)形式，樹上的每個節(jié)點都表示源碼的一種結(jié)構(gòu)。

以上圖為例，代碼塊區(qū)域是用 Objective-C 和 TypeScript 編寫的一個簡單條件語句源碼，下面是其對應(yīng)的抽象語法結(jié)構(gòu)表達。這種樹狀的結(jié)構(gòu)表達，省略了一些細節(jié)（比如：沒有生成括號節(jié)點），從圖中的這種映射關(guān)系中我們也可以發(fā)現(xiàn)：

• 源碼的語法結(jié)構(gòu)是可以通過明確的數(shù)據(jù)結(jié)構(gòu)表示的。
• 大多數(shù)編程語言都可以用相似的 AST 表達的。

對于 C/Objective-C 而言，主流編譯器是 Clang/LLVM（Low Level Virtual Machine）的，它是一個開源的編譯器架構(gòu)，并被成功應(yīng)用到多個應(yīng)用領(lǐng)域。Clang（發(fā)音為/kl??/，不是C浪）是 LLVM的一個編譯器前端，它目前支持 C, C++, Objective-C 等編程語言。Clang 會對源程序進行詞法分析和語義分析，將分析結(jié)果轉(zhuǎn)換為 AST。現(xiàn)有方案中不少 Lint 工具便是基于 Clang 的，Clang 包含了以下特點：

• 編譯速度快：Clang 的編譯速度遠快于 GCC。
• 占用內(nèi)存小：Clang 生成的 AST 所占用的內(nèi)存是 GCC 的五分之一左右。
• 模塊化設(shè)計：Clang 采用基于庫的模塊化設(shè)計，易于 IDE 集成及其他用途的重用。

因此，借助 Clang 的模塊化設(shè)計和高效編譯等諸多優(yōu)點，Hades 也將更容易開發(fā)和升級維護。Clang 對源碼強有力的分析能力也是主流靜態(tài)分析工具的不二之選。

Clang AST 初識

Clang 項目非常龐大。僅僅是 Clang AST 相關(guān)代碼就超過 10W+ 行代碼。如何利用 Clang 實現(xiàn) AST 分析工作，這里可以參考官網(wǎng)提供的文檔 Choosing the Right Interface for Your Application ，以下是三種方式：

• LibClang

  提供 C 語言的穩(wěn)定接口，支持Python Binding。AST 并不完整，不能完全掌控 Clang AST。

• Clang Plugins

  提供 C++ 接口，更新快，不能保留上下文信息。插件的存在形式是一個動態(tài)鏈接庫，不能在構(gòu)建環(huán)境外獨立存在。

• LibTooling

  提供 C++ 接口，更新快，可以通過標準的 main() 函數(shù)作為入口，可獨立運行，能夠完全掌控 AST，相比 Plugin 更容易設(shè)置。

這里我們選擇可獨立運行并且能完全掌控 AST 的 LibTooling 作為 Hades 的基礎(chǔ)。

在使用 Clang 的學習過程中，基本的概念便是表示 AST 的節(jié)點類型，這里重要的幾點是：

• ASTContext。

ASTContext 是編譯實例用來保存 AST 相關(guān)信息的一種結(jié)構(gòu)，也包含了編譯期間的符號表。我們可以通過 TranslationUnitDecl * getTranslationUnitDecl()： 方法得到整個翻譯單元的 AST 的入口節(jié)點。

• 節(jié)點類型。

AST 通過三組核心類構(gòu)建：Decl (declarations)、Stmt (statements)、Type (types)。其它節(jié)點類型并不會從公共基類繼承，因此，沒有用于訪問樹中所有節(jié)點的通用接口。

• 遍歷方式。

為了分析 AST，我們需要遍歷語法樹。Clang 提供了兩種方式：RecursiveASTVisitor 和 ASTMatcher。RecursiveASTVisitor 能夠讓我們以深度優(yōu)先的方式遍歷 Clang AST 節(jié)點。我們可以通過擴展類并實現(xiàn)所需的 VisitXXX 方法來訪問特定節(jié)點。

ASTMatcher API 提供了一種域特定語言（DSL）來構(gòu)建基于 Clang AST 的謂詞，它能高效地匹配到我們感興趣的節(jié)點。

除了這兩種方式外，LibClang 也提供了 Cursors 來遍歷 AST。更多細節(jié)內(nèi)容可以前往 ：clang.llvm.org 。

常用開源工具的不足

通過上一章節(jié)的介紹，我們大致了解了 Clang 的基本特點。 但是在實踐開發(fā)過程中發(fā)現(xiàn)：通過 Clang API 去遍歷和分析 AST 的源碼樹形結(jié)構(gòu)較為復(fù)雜。現(xiàn)有靜態(tài)分析方案（如：OCLint），大多是直接給出封裝好的 Lint 工具，擴展方面也是提供腳手架生成 Rule 文件，然后在 Rule 中編寫訪問特定 AST 節(jié)點的方法（例如：VisitObjCMethodDecl 方法用來訪問 Objective-C 的方法定義）。

因此，現(xiàn)有方案大多數(shù)只提供了直接訪問 AST 的方式，而且這種方式較為“局部”。每實現(xiàn)一個實際需求需要耗費大量精力去理解如何從 AST 分析映射到源碼的語義邏輯。

但是，Code Review 時我們并不會將目標代碼轉(zhuǎn)換為 AST 然后再去分析代碼的語義如何，更多的是直接理解代碼的具體邏輯和調(diào)用關(guān)系。AST 樹狀結(jié)構(gòu)分析的復(fù)雜性容易帶來理解上的差異鴻溝。因此，這也不利于調(diào)動業(yè)務(wù)研發(fā)團隊的積極性，很多基于源碼分析工作也難以落地。

Hades 核心實現(xiàn)

為了讓分析過程更清晰，我們需要在 AST 的基礎(chǔ)之上再進行一次抽象。本章節(jié)主要內(nèi)容包含：Hades 的整體架構(gòu)、為什么要定義語義模型、定義什么樣的語義模型、如何輸出語義模型以及模型的序列化和持久化。

Hades 總體架構(gòu)

按照 Hades 的架構(gòu)目標進行基礎(chǔ)方案選型以后，我們來看下 Hades 的整體技術(shù)框架，可以用下圖所示的四層架構(gòu)表示：

下面簡述下這幾層的不同職責：

編譯器架構(gòu)層。Clang 的諸多優(yōu)勢前文已經(jīng)提到，這也是 Hades 的基礎(chǔ)依賴。

Hades 核心層。在編譯器架構(gòu)層，我們借助 Clang 得到了代碼的抽象語法結(jié)構(gòu)表示 AST。而 Hades 核心層的職責便是將 AST 解析成人們更容易理解的，更高層級的語義模型。

Hades 接口封裝層。抽象出的模型，能夠像 Clang 提供豐富 AST 訪問接口那樣，為開發(fā)者提供豐富的模型訪問接口。

靜態(tài)分析應(yīng)用。通過 Hades 接口封裝，我們無需清楚底層模型是如何生成的，在這一層我們可以制作 Lint 或者其它監(jiān)控、分析工具。

為什么 Hades 的架構(gòu)設(shè)計是這樣的呢？下面我們將一一道來。

為何要定義語義模型 ？

首先，正如「常用開源工具的不足」章節(jié)所述，大多現(xiàn)有方案是直接通過編譯器前端提供的接口實現(xiàn)對 AST 的操作，從而達到靜態(tài)分析的目的。

當然，除了現(xiàn)有方案的不足以外，在業(yè)務(wù)研發(fā)過程中出現(xiàn)的 Case ，其原因大多數(shù)并不是違反了現(xiàn)有的 Lint 工具中所定義的基本語法規(guī)范，這些規(guī)則分析的往往是“常識”類問題。在靜態(tài)分析中，更多的是對象的錯誤方法調(diào)用和非法的繼承/復(fù)寫關(guān)系等問題，即便具備良好的編碼規(guī)范也會疏忽。這里乍一看沒太大區(qū)別，但是從著重點來說，Hades 的設(shè)計理念上會存在本質(zhì)區(qū)別。

如上圖所示，現(xiàn)有方案如 OCLint 或者 Clang Static Analyser 等，其核心原理是在編譯器將源碼生成 AST 時，通過分析節(jié)點和節(jié)點間的關(guān)系，從而達到靜態(tài)分析的目的。這種方式不利于跨編譯單元分析，自然對項目級別的理解分析存在局限性。

所以，這里可以借助 AST 針對每個編譯單元建立更直觀的、更容易理解的結(jié)構(gòu)化表達。我們將這個更高層級的語義表達稱為 HadesModel。

定義什么樣的語義模型 ？

建立 HadesModel 以后的靜態(tài)分析中，我們的著重點變化如下圖所示：

下面我們可以簡單描述需要設(shè)計的 HadesModel 的基本特點：

• HadesModel 可以結(jié)構(gòu)化表達源碼的語義。它能夠表達一個編譯單元定義了哪些接口聲明、實現(xiàn)了哪些類/類別的方法、定義和展開了哪些宏定義、對象的方法調(diào)用和函數(shù)使用情況等等。
• HadesModel 使我們不需要了解 Clang 編譯器以及 AST 如何表達源碼。
• HadesModel 以一個完整的編譯單元為單位，支持 JSON 格式表達。
• 對于 Objective-C ，分析過程不必強依賴于 xcodebuild 編譯構(gòu)建過程。

通過以上幾點特征描述，我們得到了 HadesModel 更清晰的表述：

HadesModel 是基于 AST 的更高層級語義表達，它能夠序列化為 JSON 格式并描述完整的編譯單元，這種結(jié)構(gòu)化信息使得靜態(tài)分析能更接近于開發(fā)者閱讀理解源碼的思維習慣。

在介紹完 HadesModel 的基本目標后，我們用下面一段簡單的 Objective-C 代碼為例來明確 HadesModel 的具體表達形式：

在示例代碼中，我們簡單了解下包含的語義邏輯：

• 這是一段 Objective-C 代碼，實現(xiàn)文件名為 HadesViewController.m。
• 在實現(xiàn)文件中，定義了一個名為 HadesMacro 的宏定義。
• 實現(xiàn)文件中包含了 HadesViewController 類的實現(xiàn)部分，HadesViewController 是 UIViewController 的子類。
• HadesViewController 類中包含了兩個方法實現(xiàn)。其中第一個方法名為 sayHello ，里面包含了局部對象 testView 的初始化以及對象的方法調(diào)用，另外還包含了宏定義的使用。

可以發(fā)現(xiàn)，HadesModel 能夠表達開發(fā)者對語義信息的直觀理解即可。

如何生成語義模型：HadesModel ？

接下來介紹 Hades 基本架構(gòu)圖中 HadesCore 的核心實現(xiàn)，重點在如何生成前文所述的 HadesModel。

這里 HadesCore 借助 Clang LibTooling 分析源碼的 AST，然后將我們所需的語義信息抽象成 HadesModel。將數(shù)據(jù)抽象和轉(zhuǎn)換過程用以下簡要流程表示：

下面將從一個流程圖來看看 HadesCore 是如何生成 HadesModel 的實現(xiàn)細節(jié)：

流程圖中主要包括以下幾點內(nèi)容。

1. 構(gòu)建編譯數(shù)據(jù)庫

首先，Hades 是基于 Clang 的模塊化設(shè)計開發(fā)，所以它可以獨立運行，因此，可以利用 RubyGem 的方式將模型生成過程封裝并提供命令行工具。對于需要得到 HadesModel 的編譯單元.m，首先需要作為源文件集成到 workspace （iOS 可以用 CocoaPods），然后利用 Xcode 提供的 xcodebuild 結(jié)合 xcpretty 編譯得到項目的編譯數(shù)據(jù)庫 compile_commands.json。編譯數(shù)據(jù)庫用來指定每個編譯單元的命令行參數(shù)。

2. 創(chuàng)建 HadesDriver

在創(chuàng)建驅(qū)動器之前，可以使用 Clang 提供的 CommonOptionsParser 類，它將負責解析與編譯數(shù)據(jù)庫和輸入相關(guān)的命令行參數(shù)，然后將其作為驅(qū)動器的輸入。驅(qū)動器控制整個模型生成周期，它的輸出結(jié)果便是 HadesModel。

3. 構(gòu)建 HadesModel

在 HadesDriver 的驅(qū)動下，首先需要創(chuàng)建編譯器實例，執(zhí)行編譯前可以分析宏定義和頭文件展開等預(yù)處理信息，并將這些內(nèi)容初始化到 HadesModel 對象。接著，在編譯器實例中將 FrontendAction 接口作為擴展編譯過程的執(zhí)行入口，利用 Clang LibTooling 提供的 ASTVistor 訪問 AST 節(jié)點（更多 Clang 技術(shù)細節(jié)見：Clang 8 documentation），最終將所有翻譯單元的“元數(shù)據(jù)”填充到 HadesModel。

以前文的 HadesViewController.m 為例，我們得到 HadesModel 并序列化為 JSON 數(shù)據(jù)以后，如下圖所示：

顯然，示例 HadesModel 已經(jīng)能夠表達開發(fā)者 Code Review 時，絕大多數(shù)“直白”的語義信息了。

HadesModel 的序列化/持久化

由于 HadesModel 最終需要以 JSON 格式作為提供靜態(tài)分析的原始數(shù)據(jù)類型，所以需要保證 HadesModel 具備序列化的能力。

JSON 格式使 Hades 具備了全局分析能力，也符合設(shè)計之初的分析和平臺、語言無關(guān)的要求。再者，JSON 類型也方便利用具備較好類型系統(tǒng)的語言作為分析接口層。

實踐中，以 iOS 常用的 CocoaPods 的 Pod 為單位，在私有 Pod 發(fā)版時生成模型數(shù)據(jù)然后打包存儲在 Maven 中，以便于增量分析。

在 CI 系統(tǒng)中，特別是大型項目持久化的模型存儲非常重要。CI 中為了加快集成速度，不得不使用部分二進制的集成方式，但是這樣將無法對靜態(tài)庫進行源碼分析。利用 Hades 的模型緩存，我們可以解決二進制集成的局限性。緩存數(shù)據(jù)也不需要再次編譯、模型生成等耗時操作，所以接入 Hades 后基本不影響集成項目的集成速度。

Hades 應(yīng)用案例（1）：制作 Lint 工具

在這一章，我們將介紹 Hades 架構(gòu)中的接口層，以及在 Lint 工具上的應(yīng)用。

HadesLint 架構(gòu)描述

HadesLint 是基于 Hades 框架制作的靜態(tài)分析工具。作為平臺標準的 Lint 工具，目前在持續(xù)集成有了廣泛應(yīng)用（詳情見此篇文章：MCI：大眾點評千人移動研發(fā)團隊怎樣做持續(xù)集成？）。

HadesLint 開發(fā)語言是 TypeScript。它具備完善的類型系統(tǒng)，結(jié)合 VSCode 的智能補全和完善的 Debug 能力，使得 HadesLint 具備良好的開發(fā)體驗。

HadesLint 的實現(xiàn)細節(jié)如下圖所示：

在接入 HadesLint 的項目后，我們將項目以 Pod 為單位，從 Maven 中讀取緩存模型 Zip 包。如果不存在緩存，那么將利用前文所述封裝好的 HadesGem 通過編譯數(shù)據(jù)庫實時生成每個編譯單元的 HadesModel。

由于我們的項目較大，模型數(shù)據(jù)量也非常龐大，為了防止分析過程內(nèi)存泄露的危險，提升分析性能，可以通過Lazy.js進行惰性求值，漸進加載有效解決了模型數(shù)據(jù)龐大的問題。

被 Lazy.js 加載的 JSON 對象，需要通過 TypeScript 聲明來保證 HadesModel 具備類型。這樣，我們就可以在 VSCode 中編寫代碼時，享受自動補全、類型推斷，從而保證編寫過程更加安全、高效。借助 VSCode 對 TypeScript 的良好支持，在編寫分析過程中方便地 Debug。

最后 HadesLint Driver 會加載每個規(guī)則對象，在規(guī)則中分析 HadesModel 然后確定檢查項是否合法。

當然，如果希望程序執(zhí)行效率更高些，也可以嘗試 OCaml+ATD 來構(gòu)建 Lint 項目。

HadesLint 應(yīng)用案例：打印項目中的類名

需求描述：我們需要找到項目中定義的所有類名。

我們只需要通過腳手架創(chuàng)建新的規(guī)則，然后編寫以下代碼（HadesLint規(guī)則代碼）：

this.hadesModels.each((hadesModel: HadesModel.HModel) => {hadesModel.class_list.forEach((occlass: HadesNode.Class) => {console.log(occlass.name);}) });

編寫代碼以后，可以在 VSCode 的 Debug 面板中開啟調(diào)試：

當然，除了以上簡單的查詢功能以外，我們也可以定制相對復(fù)雜的檢查規(guī)則，比如繼承鏈管控、方法復(fù)寫檢查、非空檢查等。

在引出方法復(fù)寫管控之前，開發(fā)者往往會通過隨意繼承的方式復(fù)寫代碼，或者通過不合理擴展方式來滿足當前需求。但是，人工 Review 代碼很難保證集成項目中，這些擴展或者子類在運行時的行為。因此，對繼承鏈管控的需求非常有必要。我們的 App 之前就出現(xiàn)了擴展同名方法，意外導(dǎo)致方法復(fù)寫，從而在程序運行時出現(xiàn)問題，甚至導(dǎo)致 Crash。

為此，我們在集成準入檢查中加入了方法覆蓋檢查。當然，如果父類設(shè)計之初本身是希望子類復(fù)寫，我們在 Lint 過程中通常會忽略這些合法的復(fù)寫情況。

對于這類跨編譯單元的分析需求，如果我們按照 Clang Static Analyser 是較難分析的，但是 Hades 就可以非常輕松地做到，因為 Hades 可以輕松獲取整個繼承鏈以及每個類的實現(xiàn)定義。

Hades 應(yīng)用案例（2）：構(gòu)建 HadesDB

HadesModel 是結(jié)構(gòu)化數(shù)據(jù)，因此，我們也可以將這些模型數(shù)據(jù)以 Document 的形式存儲到文檔型數(shù)據(jù)庫中，例如：CouchDB。

在 CouchDB 的基礎(chǔ)上建立模型數(shù)據(jù)庫，這樣便能夠方便地通過 Map-Reduce 建立視圖文檔（Design Documents），然后，我們可以獲取項目中包含的類及其方法列表、分析每個 Document 的字段按需輸出結(jié)果。

例如，存儲建立完整的項目 HadesModel 數(shù)據(jù)后，在 CouchDB 中建立 Design Document，然后在 Map Function 中編寫以下代碼:

function (doc) {if (doc.extracontext.macro_list !== null) {emit(doc._id, doc.extracontext.macro_list);} }

CouchDB 支持 JS 代碼編寫 map-reduce，以上代碼表示在當前的數(shù)據(jù)庫中，對于每個 HadesModel Document 判斷是否存在宏定義，如果存在，那么輸出宏定義作為 Design Document 的結(jié)果。

最后，通過 CouchDB 接口返回可以獲取如下結(jié)果：

// App 項目中源碼中使用的所有宏定義信息： {"total_rows": xxx,"offset": 0,"rows": [{"id": "NVShopInfoBlackPearlMultiDealCell","key": "NVShopInfoBlackPearlMultiDealCell","value": [{"name": "NVActionSheet","expanded": true,"expandstr": "UIResponder<NVActionSheetDelegate> *","location": ${path_location},...}]},...] }

有了 HadesDB 以后，我們能賦予代碼語義分析更大的想象空間。比如，可以利用 HadesDB 制作 Web 項目，通過 Web 頁面搜索、查詢我們所需要知道的語義信息和分析數(shù)據(jù)。

總結(jié)

本文介紹了在美團點評業(yè)務(wù)快速發(fā)展背景下，針對大型移動項目的靜態(tài)分析需求，結(jié)合開源項目利弊，最終設(shè)計實現(xiàn)的靜態(tài)分析框架 Hades。

Hades 作為大眾點評移動研發(fā)的基礎(chǔ)設(shè)施之一，在實踐中得到了廣泛的應(yīng)用，為大型 App 項目的日常維護、代碼分析提供支持。基于 HadesModel 的靜態(tài)分析易上手，開發(fā)接入成本低，能夠理解代碼語義，具備全局分析能力等諸多優(yōu)點。

最后，我們也希望 Hades 的設(shè)計是賦予創(chuàng)造能力的能力，而不僅僅是作為傳統(tǒng)意義上的 Lint 輔助工具，這也是我們?yōu)槭裁床蝗∶麨椤肮ぞ摺?#xff0c;而是稱之為“框架”的原因。當然，基于 Hades 我們也是能夠很方便地制作出 Lint 工具的。

Hades 是否開源？不久將會開源，敬請期待。如果對我們平臺感興趣，歡迎小伙伴們加入大眾點評的大家庭。

參考資料

• [1] Clang 8 documentation
• [2] Infer static analyzer
• [3] Clang Tidy
• [4] OCLint static analyzer
• [5] Apache CouchDB
• [6] TypeScript
• [7] ATD
• [8] Lazy.js
• [9] xcpretty
• [10] Visual Studio Code

作者簡介

• 吳達，大眾點評 iOS 技術(shù)專家，Hades 項目開發(fā)者。目前專注于移動 CI 研發(fā)，靜態(tài)分析和點評 App 業(yè)務(wù)研發(fā)。
• 智聰，移動信息組件負責人，大眾點評 iOS 高級專家。專注于移動工具鏈開發(fā)，對移動持續(xù)集成、靜態(tài)分析平臺建設(shè)有深刻理解和豐富的實踐經(jīng)驗。

招聘信息

大眾點評移動研發(fā)中心，Base 上海，為美團提供移動端底層基礎(chǔ)設(shè)施服務(wù)，包含網(wǎng)絡(luò)通信、移動監(jiān)控、推送觸達、動態(tài)化引擎、移動研發(fā)工具等。同時團隊還承載流量分發(fā)、UGC、內(nèi)容生態(tài)、個人中心等業(yè)務(wù)研發(fā)工作，長年虛位以待專注于移動端研發(fā)的各路英雄豪杰。歡迎投遞簡歷：dawei.xing@dianping.com。

總結(jié)

以上是生活随笔為你收集整理的Hades：移动端静态分析框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。