一級結構工程師論文范文一級結構工程師論文范文模板

人工處理崩潰報告的過程重復性高、過程繁瑣，令人十分痛苦。來自京東的王永杰老師帶來了京東手機京東 crash 自動分析處理系統的實踐經驗，并展望了利用機器學習實現的智能化崩潰信息分析的未來。

此外，ArchSummit 全球架構師峰會深圳站 將于 2016 年 7 月 7 日~8 日在深圳·華僑城洲際酒店召開，京東商城運營研發部總架構師者文明策劃了《低延遲系統架構設計》專題，將會為大家分享目前各大互聯網企業在低延遲系統架構設計上都有哪些新思路，歡迎關注。

　　引言：移動互聯網時代，質量是應用的生命

去年 618 活動中手機京東的單量占比已經超過了 80%，一度超過 85%。今年 618 活動才剛剛開始，很有可能會再創新高，毋容置疑現如今已是一個移動的時代。

手機客戶端是移動時代最為重要的載體之一，而質量又是客戶端的生命線。如果一個手機客戶端總是崩潰或者卡頓的話，用戶的體驗就會很差，轉化率等一系列核心數據指標就會收到嚴重影響。然而這種情況卻十分普遍，特別是面對安卓系統的千差萬別，廠商的定制乃至各種山寨機，不同的系統版本時，保證客戶端質量是一項非常嚴峻和有挑戰的事情。

很多因素會影響到 App 的質量，比如性能與穩定性。而穩定性的一個最重要的指標就是 crash 率。本文的主題就是圍繞著如何將 crash 的分析處理進行自動化甚至于智能化。

我現在主要負責手機京東開放平臺，本文分享的實踐來自于京東開放平臺的支撐體系的一部分，我們需要保證業務部門在這個平臺上進行業務開發的質量、性能以及開發效率等各個方面。

　　背景介紹

業內對于 crash 率的定義一般情況有兩個。一個叫”崩潰率“，通常來說定義是每天 0 點到 24 點的 crash 的數量除以啟動次數。還有一個比較重要的指標是”去重崩潰率“，大多數公司會更看重這個指標，它一般是影響用戶數除以 DAU。

有的應用的平均崩潰率在百分之幾， 游戲類的應用可能達到 9% 乃至更高，有興趣的可以看看騰訊 Bugly 年初發布的 2016 年度數據報告。

京東做了這么多年，最開始的時候 Crash 率指標也曾經到過百分位。因為京東的用戶量比較大，最開始的時候崩潰報告非常龐大，甚至需要分段分多次才能導出完整的數據。不過經過努力，崩潰率在之后減少到了千分位，而目前京東已經邁入了崩潰率萬分位的時代。

保持產品穩定性，降低崩潰率，是蠻痛苦的一個過程。因為它不僅涉及到崩潰信息要盡可能多收集的同時，還要去分析崩潰信息、定位問題并找出解決方案 。今天本文重點是崩潰的分析和處理過程。

　　（1）人工處理 Crash 的流程

首先來看一下人工處理崩潰報告的過程。這是比較遙遠的處理方式，在當時來說這種過程十分令人痛苦。

簡單來講 crash 首先會通過用戶主動提交，收集存儲到服務器。我們主要來看一下虛線框里的環節， 工程師需要從服務器中導出數據，對這些數據進行去重、排名，根據重要性篩選分析；經過初步分析后，定位相應的模塊，然后通過郵件分發給指定的工程師；工程師會具體分析和解決問題，最后將代碼提交到代碼倉庫。這個過程需要有人工來負責崩潰的統計、分析以及 Bug 的分派。還有一個沒提到的事是，問題處理過程不好跟蹤。如果沒有一個系統去管理的話，就不容易知道 crash 問題到底處理沒有處理，以及問題處理到哪個階段了。

有時候 crash 表面上起來看起來是屬于 A 模塊，但實際上它屬于 B 模塊，這種類似的問題很多。同時開發過程，一個是有灰度的階段；還有日常的階段，需要針對不同的階段使用不一樣的方式針對 crash 進行處理。

　　（2）人工處理 Crash 流程的問題

總結一下人工處理 crash 流程的問題。首先它比較繁瑣，特別在灰度期間，工程師可能需要每天把這數據導出一遍，然后去處理排名、分析，整個流程特別繁瑣，重復率高，而且效率比較低。處理的實時性不高，畢竟工程師不可能一直盯著 crash 報告的產出，一般情況都是一天一維度導出一份 crash 報告，處理完之后然后去分發給相應責任人。

人工處理可能會出現遺漏，比較典型的情況是在在線上運行的這個階段。這個階段的話可能有一個業務的 UV 并不太高，它有一些崩潰而且甚至是必現的問題，但是由于線上收集到的總的 crash 數量特別大，導致這個問題可能占比比較小，就被掩藏在其他的崩潰里邊，導致遺漏。 再一個是剛才提到的，我們如何去做 crash 的跟蹤與統計。

　　（3）如何改進

接下來討論下怎么去改進 crash 的處理過程。我們都有什么資源可被利用呢？我們有工程師還有機器，工程師擅長創新，而機器不知疲倦，擅長重復性的工作。我們知道，人類進化的標志之一是直立行走，那人跟動物最大的區別是什么呢？ 制造并使用生產工具，提高生產效率和生產力。所以我們思考如何讓工程師發揮創造性，把精力聚焦到使用創造性解決疑難問題上，而繁瑣的問題交給機器，因為它擅長執行又不知疲倦。

　　（4）自動化處理 Crash 的流程

首先看一下目標的自動化流程是什么樣子。整個環節除了最后的環節需要人去處理這些疑難問題，比如去定位問題根源，修改代碼之外，希望其他環節盡可能做到自動化流程。

從 crash 提交開始，系統就能做自動分析，把問題聚類、分類、排名；之后自動創建 Bug 報告，提交到 Bug Tracker，使我們更方便的追蹤 crash 的 bug 是什么時候出現的，它的狀態是什么樣子的，怎么在系統中流轉。整個流程在相關系統上全部打通之后，信息就會流動起來。

接下來講一下結果的分析過程。京東有一個 crash 展示的系統，可以很方便的查看 crash 排名、責任人、處理的狀態、具體的信息，模塊的情況等，然后根據這些信息進行詳細分析。每一條 crash 的上報，系統都會自動分析，定位到這個問題是誰，然后分發給責任人。

對于比較明顯的問題、或者問題能定位清楚的話，系統會直接就告訴我們這個問題是什么，代碼的哪一行出錯了，代碼修改的提交時間和 commit ID 是什么，將問題交給相關開發人員。這種信息十分受開發者歡迎，他看一下那個郵件，就知道是大概是哪出問題了，然后解決問題，提交代碼。對于一些比較簡單的問題，系統甚至可以做到自動化修改和代碼提交，不需要經過人工干預。

代碼提交之后，系統會自動在 Bug Tracker 中修改 bug 的狀態，然后把 crash 展示系統里邊的狀態也改掉。信息的打通，會自動觸發 CI 系統編譯打包發布到灰度系統，再之后升級推送到用戶。

這個環節也是可以做到自動化的，包括打通 Hotfix。比如說有些用戶經常出現 crash，在處理完之后就針對性的自動生成一個 Hotfix 包，定向灰度分發，然后目標用戶升級之后就把這個問題解決掉了，而其他用戶也不會受到影響。

這個目標流程看起來很美好，那怎么去實現它呢？

　　總體架構

簡單介紹一下整體系統架構設計， 設計時考慮的自動處理分析系統其實不止可以處理 crash，對于其他問題的思路是一樣的，比如用戶的意見反饋。中間的虛線部分是自動分析處理系統；而下面的編譯系統、代碼管理系統、Hotfix 系統、Bug 管理系統以及灰度系統都可以通過這個架構有機的結合在一起。

　　自動分析處理系統的總體架構

自動分析處理系統可以劃分成四大部分。

上面提到的前端展示部分，可以展示用戶感興趣的個性化內容、分模塊匯總的數據情況和分析報告等。

后臺管理系統，用于實現各種自動化配置。比如代碼里有很多的嵌套關系與各種模塊，同時也支持插件化，總體大概有五六十個插件。它們之間的關系與配置，以及相關的維護人員，以及各大小版本和灰度版本，都需要主動去完善配置。

中間層主要負責數據同步。如 crash 信息收集系統的同步，包括原始數據的格式化，以及分析、匯總的郵件發送等。Crash 詳情分析一般都會發給責任人，抄送相關，以便具體問題具體分析。Crash 分析也會有匯總郵件，發送給相關負責人，用以了解總體的情況。

其中最重要的部分是 crash 的分析處理的這個環節。對于安卓系統收集的報告來說代碼都有混淆過；對于 iOS，包括安卓的 native code 話，線上 Crash 沒有符號表，需要把混淆后的代碼對應回去。我們希望把這份工作全交給機器來去做，比如解混淆、解析過濾，還原去定位到具體文件某一行，這次修改的提交的相關信息等。深度分析未來計劃會繼續深入做，比如代碼庫的分析，報告的生成等。

　　關鍵實踐

整個架構涉及的環節特別多，由于篇幅關系，分享實踐的過程中一些關鍵點。關鍵問題如果搞定的話，其他的問題都對于各位資深工程師，甚至對于普通的工程師的話應該都都不會有太大的難度。這些難點首先需要你要敢想，然后真正的去分析去做，一切都是可以實現的。

　　（1）崩潰分析結果

首先看郵件中的崩潰分析結果。每當遇到了一個 crash，系統就會分析出一些信息，匯總到郵件發出來。

現在看的是一個崩潰分析的結果。由于交給機器來處理崩潰信息，可以通過聚類分析把客戶端所有歷史數據進行分析，去重等，比如我們可以知道這個 crash 之前出現過多少次。上面這個結果包含四個部分，崩潰類型、崩潰次數，相關代碼的上下文以及提交版本 ID、修改日志和歷史，這些信息附在郵件正文里發送給相關責任人。

　　（2）崩潰分析結果 - 預覽

這個是崩潰信息的預覽。可以看到崩潰的異常類型、描述、版本號、build 號、代碼的文件對應的行數和 tag 這都有，還有復原過的具體導致出錯的崩潰堆棧，函數名及返回值和參數等。堆棧本來是被混淆過的，這里會通過機器復原回來，方便工程師分析查看。他如果覺得這信息啊不夠，覺得機器分析的有問題，他可以通過原是崩潰信息鏈接去查看。

　　（3）崩潰分析結果 - 代碼信息

通過代碼信息可以看出當時出問題的代碼行的上下文共有二十行左右的代碼，用顏色進行語法格式化，錯誤的代碼會被高亮，左側還附有行號。這種風格貼近于工程師會比較喜歡的代碼樣式，函數和變量什么都很清楚。 整個工具腳本主要是用 python 寫的，代碼高亮應用 pygments 實現，一般的工程師都可以做。即使有些關鍵點和難點，克服一下，就能解決。

　　（4）關聯 Bug 系統

還有一個比較重要的功能，就是要把 crash 跟 Bug Tracker 關聯起來。不管是開發者還是 QA 或者是其他人，都可以方便的跟蹤 crash 的狀態。

Bug Tracker 使用的 Jira（下圖左側）。收到 crash 并完成分析之后，系統就會在 Jira 上面創建一條 bug，把它的責任人、所屬模塊和崩潰的堆棧以及其他相關的信息全都給貼到 bug 詳情中，以供查看。責任人既會收到 crash 的通知郵件，也會收到 Jira 的通知郵件。他可以上 Jira 查看和處理 Bug 的狀態。整個 crash 的處理和流轉過程都是透明的，如果有工程師輕易的做不負責任的流轉的話，QA 就會找他的麻煩，這樣就沒人會輕易的踢皮球了 。

右側是展示系統，跟 Bug Tracker 是關聯起來的。第一列是 crash 的占比，占比排名靠前的是我們最需要關注的， 比如占比前三名的問題 。右邊是它的類型，還有它所所屬的模塊，責任人是誰以及一些基本信息。最重要的是這里跟 Jira 里邊同步的狀態，是已解決，還是新建還是說是流轉的狀態。這樣匯總起來的信息就會使得 QA 很方便地查看和跟蹤 。

　　（5）多庫還原

之前講了下自動化系統如何與 Bug Tracker 關聯。大家肯定也很關注，京東是如何還原混淆過的代碼，而且做到了多庫的還原。這里面包含主工程，幾十個的插件，還有一些 Jar 包、AAR 等。現在為了降低 Git 代碼倉庫的體積，我們還把幾乎所有的二進制文件，包括 Jar 包和這個 AAR 都放到 Maven 上。不管是哪種方式，我們都需要把出錯的代碼還原到具體代碼的哪個文件，并定位到 具體行和具體 commit ID。

　　（6）配置表

為了實現這個多庫還原，我們定義了一個配置表。其實別看剛才那么多的類型，其實主要的把它給分成兩類即可。一類是主工程或者是已經混淆過了的，有 mapping 文件的；另一類是沒有混淆過的。他們最大的區別就是有沒有 mapping 文件。

紅框里面，這個目錄第一層是那個模塊的名字，每個模塊下面一級以版本號和 build 號為子目錄，在這個目錄里有一個 mapping 文件和 json 文件。紅框內的定義就是混淆過的代碼，有 mapping 文件，跟下面藍色框的主要差別就是多了這個映射表。

　　（7）多庫還原過程

接下來看一下如何通過映射表恢復混淆的代碼。

映射表最關鍵的是要建立起來一個映射樹，這個樹是從無數的 mapping 文件生成出來的。這里可以大概分成三類。可以先說 com.jingdong.cc，它本來沒有被混淆過，只在最后混淆了一下，只有一個映射關系，對應到 com.jingdong.Test3，在恢復出來的映射樹中代表一個葉子節點。對于主工程內的也比較簡單，com.jingdong.aa 對應 com.jingdong.test1。

最麻煩的是 com.jingdong.bb，在混淆中對應的是 com.jingdong.test2，在主工程內可能又被混淆。簡化一點，你可以設定已經混淆過的代碼不能再次被混淆。這樣去建映射表的時候會有個順序，要先去用主工程的映射，依賴別人的先去建，被依賴的放在后邊，最后建出來的就是一個正確的樹。

如果這個樹又被混淆了一次就比較麻煩了，需要引入有多個樹，因為 com.jingdong.test1 可能會影射成 com.jingdong.bb，然后又混淆一次，映射成一個 com.jingdong.dd 或者一個什么別的，然后你只能多次建樹。

最終這個映射樹建出來的話，多庫代碼還原就容易了。

　　（8）代碼追蹤

還有一個比較大的問題，是這個代碼追蹤，同一個工程的多代碼庫，為什么會有多個倉庫呢？

我不知道其他公司有沒有遇到這個情況。因為客戶端體量大，每個版本 commit 越來越多，僅日志信息就特別大，很快就會漲到超過 1G，甚至幾個 G，Git 服務隨之會越來越慢。為了提高訪問速度，每當膨脹到一定量級的時候，就會拉出一個快照再建一個庫，然后基于新庫繼續開發 。

這樣雖然可以提升效率，但帶來一個問題。同一個工程，但有很多歷史倉庫，出錯的代碼最后一次提交有可能是在 A 這個倉庫里邊，有可能在 B 倉庫里面，有可能在歷史的 Z 倉庫里邊。怎么把這個關系去找回來呢？在此之前， 讓工程師手工去找是特別麻煩的。

另外還有拆分倉庫的情況。一個倉庫在發展的過程中，難免需要解耦分拆子庫，這樣也會面臨有多倉庫的問題。

更常見的問題是這個文件路徑的變更。不管是類名還是 package 的修改，在重構的過程中都是難以避免的，怎么去找到它的歷史。不是到這就斷了，找不到責任人了，這些其實都是問題。

　　（9）代碼庫的配置?式

為了解決多代碼庫的追蹤問題，也需要有一個配置的信息。大家可以看到，這里邊主要分為兩種，一種是嵌套的工程，一種是單倉單代碼的倉庫。單代碼倉庫的配置（紅色框）比較簡單，它有它這個 project、name，還有它是跟誰一塊編譯的，也就是嵌套工程標識，就可以了。

最重要的就是這個嵌套工程的歷史，這里邊會有不光有 project 和 name，還有它的 sources，甚至會有多個 sources。source 的 id 可以簡單的理解為歷史順序，先在最新的 id:3 里找代碼，如果沒有繼續找 id:2，還沒有，繼續 在 id:1 里找，這樣逐級地往前找，直到找到。

　　（10）代碼追蹤過程

解混淆后就有了復原后的堆棧 、package、類名和方法名以及行號。通過這些信息和 映射表就可以找到文件和出錯行的上下文。用 git blame 可以找到這一行的最后修改人及 commit ID 等信息，同時也可以找到 diff 信息進行輸出。但是由于有可能有文件更名的情況，還可能需要計算偏移量從而找到原始行號，否則會出現錯位的清涼。另外針對代碼庫遷移的情況，也需要不停的切換代碼庫，直到找到最后一次修改的 commit 為止。追蹤的流程如下圖所示。

整個過程就描述了完整的代碼復原和追蹤過程，不管是多代碼倉庫， 還是倉庫拆分、遷移或是文件移動, 都可以根據這一套方案進行原始修改信息的復原和追蹤 。

　　未來?向

上面就介紹完了整個 Crash 自動分析處理系統，目前系統運行效果非常好，尤其是在灰度階段，近四成的 crash 可以較準確定位。未來發展的方向我們定位由自動化向智能化發展， 這也是人工智能發展的大勢所趨。 未來 crash 等問題不僅能自動分析和處理，而且還能智能分析定位，給出解決方案，甚至直接給出修復 patch 包 。

簡單舉個例子，比如可以對 crash 進行深度的分析， 向工程師提供一些輔助建議，提高解決問題的效率。首先可以用代碼、patch、還有崩潰信息等數據參數化，利用機器學習平臺進行訓練，建立代碼相關度的模型。 之后利用建好的模型對 crash 進行輔助定位和分析，并在日常運行中繼續學習和訓練，提升準確度。

作者簡介

王永杰，國防科大學士，北交大碩士，首屆 GMTC 大會特邀嘉賓，曾擔任盛大創新院高級研究員。2013 年加入京東，任平臺產品研發部技術專家、架構委員會主任架構師、手機京東開放平臺負責人，是最早一批投身 Android 研究和開發的工程師。目前重點負責手機京東開放平臺的建設，將各環節進行工具化、自動化、系統化，提升研發效率和質量，降低業務開發門檻。

活動推薦

　　大會將于7月7日深圳開幕，目前9折最后一周，點擊“閱讀原文”獲取100+落地案例，看看對你有何啟發？