從Crasheye項目看開發團隊如何建立質量反饋機制

最新 07-13

導讀ID:TOP100case

導讀：Crasheye項目是金山西山居質量中心對移動遊戲質量反饋、分析、統計的一個實踐案例。該項目立足於移動端，在結合了西山居多年端游崩潰分析平台開發經驗的基礎上完成的項目，並且正逐步從適用於移動遊戲拓展到適用於移動端各類APP的崩潰反饋、分析、統計和監控，進而協助開發人員定位、制定產品缺陷的整套解決方案。

（全文共2915字預計閱讀時長：4分鐘）

Crasheye項目的起源

在傳統的端游時代，西山居內部建立了一套崩潰收集系統，主要是支持C++語言。使用線程注入的方式實現對端遊客戶端崩潰的捕獲，然後把捕獲到的崩潰信息上傳到服務端，進而在服務端進行批量的分析，並對分析結果進行簡單的排序。

隨著移動互聯網的發展，西山居作為國內領先的遊戲研發廠商已研發和推出多款移動端遊戲。為了更好的跟蹤自研遊戲的質量數據、崩潰錯誤、腳本錯誤等各類問題，我們迫切需要建立一套針對移動平台遊戲的質量反饋、分析、統計系統。

移動平台的挑戰

起初，我們在公司內部以某一移動遊戲項目作為基礎，直接參与項目研發，在項目中嵌入崩潰收集代碼，然後對上傳的崩潰信息進行分析和簡單數量統計，並且以端游的崩潰分析系統作為查看平台展示。

這套移動平台遊戲崩潰追蹤雛形方案建立之後，隨著公司業務的推進，平台遇到了越來越多的困難和挑戰，急需建立一套完善的專門針對移動平台遊戲的質量追蹤方案：

兼容iOS、Android平台；

同時支持Lua、C#、Java等腳本語言；

支持Unity3D、Cocos2D和Unreal遊戲引擎；

同時手游的質量追蹤方案，和手游本身一樣還需要兼具很多移動互聯網的特性，比如需要兼顧各種系統版本、各種手機開發商的ROM、各種網路環境等多場景的兼容性問題；

移動平台的遊戲相對端游來說周期短、更新快、產品多、渠道廣。

為了適應上述環境和要求，我們把這套系統升級為一個「產品」級別的系統來進行徹底改進，而不再是一個僅僅「內部」使用的平台，它是一個定位於具備通用性的「產品」。

解決思路

結合移動互聯網的特點，我們一開始就把這套升級後的產品——Crasheye核心點定位在「快」字上，我們希望能夠做到：

快速接入；

快速分析、統計問題；

快速展示、定位問題；

快速反饋。

結合移動端的特點，利用Crasheye系統作為基礎，把移動遊戲的質量跟蹤形成一個閉環，如圖1所示。

圖1 質量跟蹤閉環

Crasheye項目的實踐過程

4.1快速接入

Crasheye是基於某一手游項目研發的崩潰收集系統，所以當時採取了直接在客戶端嵌入代碼的方式。但是，這樣的方式不利於在其他項目推廣使用，接入代價高，也不利於接入者的快速使用。於是我們把客戶端的崩潰收集代碼封裝為SDK，並且在Android下可以使用一行代碼即可接入，極大簡化了接入流程，如圖2所示。

圖2 一行代碼接入

在iOS下，為了更進一步方便接入，我們還提供了Xcode的插件，支持接入代碼的自動撰寫、插件在線更新等功能，如圖3所示。

圖3 Crasheye SDK iOS插件

經過改進形式以及接入的方法，Crasheye的接入易用性得到了很大的提高。

4.2快速分析、統計問題

完善異常捕獲機制

在完成Crasheye接入改進的同時，為了適用於更多的項目，我們逐步改進了SDK在客戶端的崩潰捕獲方法，主要是完善了對Cocos2D、Unity3D遊戲引擎的支持，並在國內率先增加了對Unreal引擎的支持；同時也改進了對Java、Lua等腳本語言的回溯支持，配合服務端的崩潰分析系統改造，實現了對多種引擎、多種腳本語言崩潰異常的捕獲和快速分析能力。如圖4所示。

圖4 Crasheye捕獲的Lua腳本異常

深入mono層，獲得C#腳本的代碼堆棧

在針對主流的遊戲引擎做崩潰捕獲同時，我們還進行更加深入的問題定位和跟蹤策略，發現在使用Unity3D引擎開發的遊戲時候，會碰到以下問題：遊戲經常會出現莫名其妙的閃退。而當我們嘗試回溯C++的堆棧時候，發現未能達到我們想要的效果。在堆棧中也沒有發現任何與我們腳本相關的代碼信息，宕機堆棧信息只能表現為Unity3D底層處理異常。

為了解決這個問題，我們採用了下面的手段：

當異常觸發的時候，嘗試提供給C#的一個生存介面，並獲取C#自身的運行狀況；

通過mono層的信息，回溯當前正在運行的C#代碼堆棧。如圖5所示。