一種日誌處理方法及裝置、設備與流程
2023-08-10 08:41:16 2

本發明涉及智能終端技術,尤指一種日誌處理方法及裝置、設備。
背景技術:
android是基於java和c/c++編寫而成的作業系統,同樣android應用也可以使用java和c/c++編寫應用代碼,java和c/c++之間通過jni進行溝通,java代碼運行在java虛擬機之上,c/c++代碼編譯成so庫,被java虛擬機調用。android應用的這種可以使用java和c/c++編寫代碼的屬性,決定了android應用會出現java層的應用崩潰和native層的應用崩潰(即c/c++代碼出錯)。一般來說,native應用崩潰、java應用崩潰是由於空指針、引用越界、內存洩露等導致。
目前各大手機廠商都在機器預製了當系統出現異常時,自動上傳異常信息到伺服器供開發人員分析的模塊。其一般實現原理是在系統中出現異常時,抓取系統的一些信息,並將這些信息壓縮後通過網絡上傳到伺服器上,伺服器端根據上傳的機器imei號定位該機器具體出現了什麼異常。相關技術中,伺服器端收到終端上傳的大量應用崩潰日誌之後,開發人員需要對每一條日誌進行分析,不僅費時耗力,成本高,而且不能及時準確的找到終端存在的問題,從而無法及時完成終端的系統維修,以至於降低了用戶體驗。
技術實現要素:
針對上述技術問題,本發明提供了一種日誌處理方法及裝置,能夠將相同原因導致的崩潰日誌進行歸併,使開發人員更快速對崩潰日誌進行分析,以快速、準確的找到終端存在的問題。
本申請提供了:
一種日誌處理方法,應用於伺服器端,包括:
接收來自客戶端的崩潰異常堆棧;
將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
其中,所述應用崩潰日誌為如下之一:
java層崩潰日誌;
native層崩潰日誌。
其中,所述將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併,包括:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、原因和堆棧相同的應用崩潰日誌歸併。
其中,所述將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併,包括:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、問題信號、崩潰返回碼、崩潰信息以及堆棧相同的應用崩潰日誌歸併。
一種日誌處理裝置,包括:
接收模塊,用於接收來自客戶端的崩潰異常堆棧;
歸併模塊,用於將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
其中,所述應用崩潰日誌為如下之一:
java層崩潰日誌;
native層崩潰日誌。
其中,所述歸併模塊,具體用於:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、原因和堆棧相同的應用崩潰日誌歸併。
其中,所述歸併模塊,具體用於:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、問題信號、崩潰返回碼、崩潰信息以及堆棧相同的應用崩潰日誌歸併。
一種設備,包括存儲器、處理器及存儲在所述存儲器上並可在所述處理器上運行的電腦程式,所述處理器執行所述電腦程式時實現以下步驟:
接收來自客戶端的崩潰異常堆棧;
將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
一種計算機可讀存儲介質,其上存儲有電腦程式,所述電腦程式被處理器執行時實現以下步驟:
接收來自客戶端的崩潰異常堆棧;
將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
本申請能夠將相同原因導致的崩潰日誌進行歸併,歸併後大量的應用崩潰日誌將歸併成少量的不同崩潰原因導致的應用崩潰日誌,開發人員只對這些經過歸併的應用崩潰日誌進行分析即可,一次即可對同一類應用崩潰日誌進行分析,不僅省時省力,成本低,而且使開發人員能夠快速完成崩潰日誌的分析,以快速、準確的找到終端存在的問題。
此外,便於終端生產商根據歸併後的應用崩潰日誌,獲取各類型終端的崩潰日誌中各種問題出現的比率等數據,能夠更加有針對性的進行處理,有利於改善終端的整體性能,並提高用戶體驗。
附圖說明
此處所說明的附圖用來提供對本發明的進一步理解,構成本申請的一部分,本發明的示意性實施例及其說明用於解釋本發明,並不構成對本發明的不當限定。在附圖中:
圖1為實現本發明各個實施例的移動終端的硬體結構示意;
圖2為支持本發明移動終端之間進行通信的通信系統的示意圖;
圖3為本申請日誌處理方法的流程示意圖;
圖4為本申請java層崩潰日誌處理的流程示意圖;
圖5為本申請native層崩潰日誌的流程示意圖;
圖6為本申請日誌處理裝置的組成結構示意圖;
圖7為本申請中伺服器的結構示意圖。
具體實施方式
下面將結合附圖及實施例對本發明的技術方案進行更詳細的說明。
現在將參考附圖描述實現本發明各個實施例的終端。在後續的描述中,使用用於表示元件的諸如「模塊」、「部件」或「單元」的後綴僅為了有利於本發明的說明,其本身並沒有特定的意義。因此,"模塊"與"部件"可以混合地使用。
終端可以以各種形式來實施。例如,本發明中描述的終端可以包括諸如行動電話、智慧型電話、筆記本電腦、數字廣播接收器、pda(個人數字助理)、pad(平板電腦)、pmp(可攜式多媒體播放器)、導航裝置等等的移動終端以及諸如數字tv、臺式計算機等等的固定終端。下面,以終端是移動終端為例進行說明。然而,本領域技術人員將理解的是,除了特別用於移動目的的元件之外,根據本發明的實施方式的構造也能夠應用於固定類型的終端。
圖1為實現本發明各個實施例的移動終端的硬體結構示意圖。
移動終端100可以包括無線通信單元110、a/v(音頻/視頻)輸入單元120、用戶輸入單元130、感測單元140、輸出單元150、存儲器160、接口單元170、控制器180和電源單元190等等。圖1示出了具有各種組件的移動終端,但是應理解的是,並不要求實施所有示出的組件。可以替代地實施更多或更少的組件。將在下面詳細描述移動終端的元件。
無線通信單元110通常包括一個或多個組件,其允許移動終端100與無線通信系統或網絡之間的無線電通信。例如,無線通信單元可以包括廣播接收模塊111、移動通信模塊112、無線網際網路模塊113、短程通信模塊114和位置信息模塊115中的至少一個。
廣播接收模塊111經由廣播信道從外部廣播管理伺服器接收廣播信號和/或廣播相關信息。廣播信道可以包括衛星信道和/或地面信道。廣播管理伺服器可以是生成並發送廣播信號和/或廣播相關信息的伺服器或者接收之前生成的廣播信號和/或廣播相關信息並且將其發送給終端的伺服器。廣播信號可以包括tv廣播信號、無線電廣播信號、數據廣播信號等等。而且,廣播信號可以進一步包括與tv或無線電廣播信號組合的廣播信號。廣播相關信息也可以經由移動通信網絡提供,並且在該情況下,廣播相關信息可以由移動通信模塊112來接收。廣播信號可以以各種形式存在,例如,其可以以數字多媒體廣播(dmb)的電子節目指南(epg)、數字視頻廣播手持(dvb-h)的電子服務指南(esg)等等的形式而存在。廣播接收模塊111可以通過使用各種類型的廣播系統接收信號廣播。特別地,廣播接收模塊111可以通過使用諸如多媒體廣播-地面(dmb-t)、數字多媒體廣播-衛星(dmb-s)、數字視頻廣播-手持(dvb-h),前向鏈路媒體(mediaflo@)的數據廣播系統、地面數字廣播綜合服務(isdb-t)等等的數字廣播系統接收數字廣播。廣播接收模塊111可以被構造為適合提供廣播信號的各種廣播系統以及上述數字廣播系統。經由廣播接收模塊111接收的廣播信號和/或廣播相關信息可以存儲在存儲器160(或者其它類型的存儲介質)中。
移動通信模塊112將無線電信號發送到基站(例如,接入點、節點b等等)、外部終端以及伺服器中的至少一個和/或從其接收無線電信號。這樣的無線電信號可以包括語音通話信號、視頻通話信號、或者根據文本和/或多媒體消息發送和/或接收的各種類型的數據。
無線網際網路模塊113支持移動終端的無線網際網路接入。該模塊可以內部或外部地耦接到終端。該模塊所涉及的無線網際網路接入技術可以包括wlan(無線lan)(wi-fi)、wibro(無線寬帶)、wimax(全球微波互聯接入)、hsdpa(高速下行鏈路分組接入)等等。
短程通信模塊114是用於支持短程通信的模塊。短程通信技術的一些示例包括藍牙tm、射頻識別(rfid)、紅外數據協會(irda)、超寬帶(uwb)、紫蜂tm等等。
位置信息模塊115是用於檢查或獲取移動終端的位置信息的模塊。位置信息模塊的典型示例是gps(全球定位系統)。根據當前的技術,gps模塊115計算來自三個或更多衛星的距離信息和準確的時間信息並且對於計算的信息應用三角測量法,從而根據經度、緯度和高度準確地計算三維當前位置信息。當前,用於計算位置和時間信息的方法使用三顆衛星並且通過使用另外的一顆衛星校正計算出的位置和時間信息的誤差。此外,gps模塊115能夠通過實時地連續計算當前位置信息來計算速度信息。
a/v輸入單元120用於接收音頻或視頻信號。a/v輸入單元120可以包括相機121和麥克風1220,相機121對在視頻捕獲模式或圖像捕獲模式中由圖像捕獲裝置獲得的靜態圖片或視頻的圖像數據進行處理。處理後的圖像幀可以顯示在顯示單元151上。經相機121處理後的圖像幀可以存儲在存儲器160(或其它存儲介質)中或者經由無線通信單元110進行發送,可以根據移動終端的構造提供兩個或更多相機1210。麥克風122可以在電話通話模式、記錄模式、語音識別模式等等運行模式中經由麥克風接收聲音(音頻數據),並且能夠將這樣的聲音處理為音頻數據。處理後的音頻(語音)數據可以在電話通話模式的情況下轉換為可經由移動通信模塊112發送到移動通信基站的格式輸出。麥克風122可以實施各種類型的噪聲消除(或抑制)算法以消除(或抑制)在接收和發送音頻信號的過程中產生的噪聲或者幹擾。
用戶輸入單元130可以根據用戶輸入的命令生成鍵輸入數據以控制移動終端的各種操作。用戶輸入單元130允許用戶輸入各種類型的信息,並且可以包括鍵盤、鍋仔片、觸摸板(例如,檢測由於被接觸而導致的電阻、壓力、電容等等的變化的觸敏組件)、滾輪、搖杆等等。特別地,當觸摸板以層的形式疊加在顯示單元151上時,可以形成觸控螢幕。
感測單元140檢測移動終端100的當前狀態,(例如,移動終端100的打開或關閉狀態)、移動終端100的位置、用戶對於移動終端100的接觸(即,觸摸輸入)的有無、移動終端100的取向、移動終端100的加速或減速移動和方向等等,並且生成用於控制移動終端100的操作的命令或信號。例如,當移動終端100實施為滑動型行動電話時,感測單元140可以感測該滑動型電話是打開還是關閉。另外,感測單元140能夠檢測電源單元190是否提供電力或者接口單元170是否與外部裝置耦接。感測單元140可以包括接近傳感器1410將在下面結合觸控螢幕來對此進行描述。
接口單元170用作至少一個外部裝置與移動終端100連接可以通過的接口。例如,外部裝置可以包括有線或無線頭戴式耳機埠、外部電源(或電池充電器)埠、有線或無線數據埠、存儲卡埠、用於連接具有識別模塊的裝置的埠、音頻輸入/輸出(i/o)埠、視頻i/o埠、耳機埠等等。識別模塊可以是存儲用於驗證用戶使用移動終端100的各種信息並且可以包括用戶識別模塊(uim)、客戶識別模塊(sim)、通用客戶識別模塊(usim)等等。另外,具有識別模塊的裝置(下面稱為"識別裝置")可以採取智慧卡的形式,因此,識別裝置可以經由埠或其它連接裝置與移動終端100連接。接口單元170可以用於接收來自外部裝置的輸入(例如,數據信息、電力等等)並且將接收到的輸入傳輸到移動終端100內的一個或多個元件或者可以用於在移動終端和外部裝置之間傳輸數據。
另外,當移動終端100與外部底座連接時,接口單元170可以用作允許通過其將電力從底座提供到移動終端100的路徑或者可以用作允許從底座輸入的各種命令信號通過其傳輸到移動終端的路徑。從底座輸入的各種命令信號或電力可以用作用於識別移動終端是否準確地安裝在底座上的信號。輸出單元150被構造為以視覺、音頻和/或觸覺方式提供輸出信號(例如,音頻信號、視頻信號、警報信號、振動信號等等)。輸出單元150可以包括顯示單元151、音頻輸出模塊152、警報單元153等等。
顯示單元151可以顯示在移動終端100中處理的信息。例如,當移動終端100處於電話通話模式時,顯示單元151可以顯示與通話或其它通信(例如,文本消息收發、多媒體文件下載等等)相關的用戶界面(ui)或圖形用戶界面(gui)。當移動終端100處於視頻通話模式或者圖像捕獲模式時,顯示單元151可以顯示捕獲的圖像和/或接收的圖像、示出視頻或圖像以及相關功能的ui或gui等等。
同時,當顯示單元151和觸摸板以層的形式彼此疊加以形成觸控螢幕時,顯示單元151可以用作輸入裝置和輸出裝置。顯示單元151可以包括液晶顯示器(lcd)、薄膜電晶體lcd(tft-lcd)、有機發光二極體(oled)顯示器、柔性顯示器、三維(3d)顯示器等等中的至少一種。這些顯示器中的一些可以被構造為透明狀以允許用戶從外部觀看,這可以稱為透明顯示器,典型的透明顯示器可以例如為toled(透明有機發光二極體)顯示器等等。根據特定想要的實施方式,移動終端100可以包括兩個或更多顯示單元(或其它顯示裝置),例如,移動終端可以包括外部顯示單元(未示出)和內部顯示單元(未示出)。觸控螢幕可用於檢測觸摸輸入壓力以及觸摸輸入位置和觸摸輸入面積。
音頻輸出模塊152可以在移動終端處於呼叫信號接收模式、通話模式、記錄模式、語音識別模式、廣播接收模式等等模式下時,將無線通信單元110接收的或者在存儲器160中存儲的音頻數據轉換音頻信號並且輸出為聲音。而且,音頻輸出模塊152可以提供與移動終端100執行的特定功能相關的音頻輸出(例如,呼叫信號接收聲音、消息接收聲音等等)。音頻輸出模塊152可以包括揚聲器、蜂鳴器等等。
警報單元153可以提供輸出以將事件的發生通知給移動終端100。典型的事件可以包括呼叫接收、消息接收、鍵信號輸入、觸摸輸入等等。除了音頻或視頻輸出之外,警報單元153可以以不同的方式提供輸出以通知事件的發生。例如,警報單元153可以以振動的形式提供輸出,當接收到呼叫、消息或一些其它進入通信(incomingcommunication)時,警報單元153可以提供觸覺輸出(即,振動)以將其通知給用戶。通過提供這樣的觸覺輸出,即使在用戶的行動電話處於用戶的口袋中時,用戶也能夠識別出各種事件的發生。警報單元153也可以經由顯示單元151或音頻輸出模塊152提供通知事件的發生的輸出。
存儲器160可以存儲由控制器180執行的處理和控制操作的軟體程序等等,或者可以暫時地存儲己經輸出或將要輸出的數據(例如,電話簿、消息、靜態圖像、視頻等等)。而且,存儲器160可以存儲關於當觸摸施加到觸控螢幕時輸出的各種方式的振動和音頻信號的數據。
存儲器160可以包括至少一種類型的存儲介質,所述存儲介質包括快閃記憶體、硬碟、多媒體卡、卡型存儲器(例如,sd或dx存儲器等等)、隨機訪問存儲器(ram)、靜態隨機訪問存儲器(sram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、可編程只讀存儲器(prom)、磁性存儲器、磁碟、光碟等等。而且,移動終端100可以與通過網絡連接執行存儲器160的存儲功能的網絡存儲裝置協作。
控制器180通常控制移動終端的總體操作。例如,控制器180執行與語音通話、數據通信、視頻通話等等相關的控制和處理。另外,控制器180可以包括用於再現(或回放)多媒體數據的多媒體模塊1810,多媒體模塊1810可以構造在控制器180內,或者可以構造為與控制器180分離。控制器180可以執行模式識別處理,以將在觸控螢幕上執行的手寫輸入或者圖片繪製輸入識別為字符或圖像。
電源單元190在控制器180的控制下接收外部電力或內部電力並且提供操作各元件和組件所需的適當的電力。
這裡描述的各種實施方式可以以使用例如計算機軟體、硬體或其任何組合的計算機可讀介質來實施。對於硬體實施,這裡描述的實施方式可以通過使用特定用途集成電路(asic)、數位訊號處理器(dsp)、數位訊號處理裝置(dspd)、可編程邏輯裝置(pld)、現場可編程門陣列(fpga)、處理器、控制器、微控制器、微處理器、被設計為執行這裡描述的功能的電子單元中的至少一種來實施,在一些情況下,這樣的實施方式可以在控制器180中實施。對於軟體實施,諸如過程或功能的實施方式可以與允許執行至少一種功能或操作的單獨的軟體模塊來實施。軟體代碼可以由以任何適當的程式語言編寫的軟體應用程式(或程序)來實施,軟體代碼可以存儲在存儲器160中並且由控制器180執行。
至此,己經按照其功能描述了移動終端。下面,為了簡要起見,將描述諸如摺疊型、直板型、擺動型、滑動型移動終端等等的各種類型的移動終端中的滑動型移動終端作為示例。因此,本發明能夠應用於任何類型的移動終端,並且不限於滑動型移動終端。
如圖1中所示的移動終端100可以被構造為利用經由幀或分組發送數據的諸如有線和無線通信系統以及基於衛星的通信系統來操作。
現在將參考圖2描述其中根據本發明的移動終端能夠操作的通信系統。
這樣的通信系統可以使用不同的空中接口和/或物理層。例如,由通信系統使用的空中接口包括例如頻分多址(fdma)、時分多址(tdma)、碼分多址(cdma)和通用移動通信系統(umts)(特別地,長期演進(lte))、全球移動通信系統(gsm)等等。作為非限制性示例,下面的描述涉及cdma通信系統,但是這樣的教導同樣適用於其它類型的系統。
參考圖2,cdma無線通信系統可以包括多個移動終端100、多個基站(bs)270、基站控制器(bsc)275和移動交換中心(msc)280。msc280被構造為與公共電話交換網絡(pstn)290形成接口。msc280還被構造為與可以經由回程線路耦接到基站270的bsc275形成接口。回程線路可以根據若干己知的接口中的任一種來構造,所述接口包括例如e1/t1、atm,ip、ppp、幀中繼、hdsl、adsl或xdsl。將理解的是,如圖2中所示的系統可以包括多個bsc2750。
每個bs270可以服務一個或多個分區(或區域),由多向天線或指向特定方向的天線覆蓋的每個分區放射狀地遠離bs270。或者,每個分區可以由用於分集接收的兩個或更多天線覆蓋。每個bs270可以被構造為支持多個頻率分配,並且每個頻率分配具有特定頻譜(例如,1.25mhz,5mhz等等)。
分區與頻率分配的交叉可以被稱為cdma信道。bs270也可以被稱為基站收發器子系統(bts)或者其它等效術語。在這樣的情況下,術語"基站"可以用於籠統地表示單個bsc275和至少一個bs270。基站也可以被稱為"蜂窩站"。或者,特定bs270的各分區可以被稱為多個蜂窩站。
如圖2中所示,廣播發射器(bt)295將廣播信號發送給在系統內操作的移動終端100。如圖1中所示的廣播接收模塊111被設置在移動終端100處以接收由bt295發送的廣播信號。在圖2中,示出了幾個全球定位系統(gps)衛星300。衛星300幫助定位多個移動終端100中的至少一個。
在圖2中,描繪了多個衛星300,但是理解的是,可以利用任何數目的衛星獲得有用的定位信息。如圖1中所示的gps模塊115通常被構造為與衛星300配合以獲得想要的定位信息。替代gps跟蹤技術或者在gps跟蹤技術之外,可以使用可以跟蹤移動終端的位置的其它技術。另外,至少一個gps衛星300可以選擇性地或者額外地處理衛星dmb傳輸。
作為無線通信系統的一個典型操作,bs270接收來自各種移動終端100的反向鏈路信號。移動終端100通常參與通話、消息收發和其它類型的通信。特定基站270接收的每個反向鏈路信號被在特定bs270內進行處理。獲得的數據被轉發給相關的bsc275。bsc提供通話資源分配和包括bs270之間的軟切換過程的協調的移動管理功能。bsc275還將接收到的數據路由到msc280,其提供用於與pstn290形成接口的額外的路由服務。類似地,pstn290與msc280形成接口,msc與bsc275形成接口,並且bsc275相應地控制bs270以將正向鏈路信號發送到移動終端100。
基於上述移動終端硬體結構以及通信系統,提出本發明方法各個實施例。
在程序開發過程中,log是廣泛使用的用來記錄程序執行過程的機制。android為用戶空間的程序開發人員提供了輕量級的logger日誌系統,該日誌系統是以驅動程序的形式實現在內核空間中的,產生的log是以設備文件的形式存儲在文件夾/dev/log/中,該日誌系統提供了寫log到設備文件和從設備文件中讀log接口。android在用戶空間提供了使用logger日誌系統的java接口和c/c++接口供開發人員使用,log文件的寫入是android框架層代碼通過jni調用系統運行庫,並通過系統運行庫將log寫入設備文件中;log文件的讀取通過android提供的logcat工具執行,logcat工具根據開發人員輸入的命令從設備文件中讀取log,並根據開發人員的要求將經過格式化的log信息輸出。
實際應用中,終端將大量的應用崩潰日誌(如java層崩潰日誌、native層崩潰日誌等)上傳給伺服器,伺服器接收終端上傳的應用崩潰日誌,開發人員需要對伺服器上終端的大量應用崩潰日誌進行分析,以找出終端存在的問題。
假如某終端廠商在市場上有1000萬臺機器,在終端的生命周期範圍內應用java層崩潰異常上報率為10%,則伺服器上將有100萬條應用java層崩潰日誌信息。假如某廠商在市場上有1000萬臺機器,手機生命周期範圍內應用native層崩潰異常上報率為5%,則伺服器上將有50萬條應用native層崩潰日誌信息。
如果開發人員對每一條日誌都進行分析的話,很明顯這是無法完成的任務。一方面,耗時費力,效率低,成本高;另一方面,對日誌分析的速度和準確度,將直接影響到是否能及時準確的發現終端的問題,如果不能及時準確的發現終端存在的問題並予以解決,將會給用戶以及終端生產商都帶來損失。
針對上述問題,本申請提供一種日誌處理方法,能夠將相同原因導致的日誌進行自動歸併,便於開發人員對歸併後的一類日誌進行處理,一方面可以提高日誌處理效率,降低人力成本和時間成本,另一方面,也能夠有效提高日誌處理的速度和準確度,從而使得開發人員能夠及時準確的發現終端存在的問題,避免損失。
實施例一
根據本發明的一個實施例,提供了一種日誌處理方法,如圖3所示,包括:
步驟301,接收來自客戶端的崩潰異常堆棧;
步驟302,將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
本實施例中,能夠將相同原因導致的崩潰日誌進行歸併,歸併後大量的應用崩潰日誌將歸併成少量的不同崩潰原因導致的應用崩潰日誌,開發人員只對這些經過歸併的應用崩潰日誌進行分析即可,一次即可對同一類應用崩潰日誌進行分析,不僅省時省力,成本低,而且使開發人員能夠快速完成崩潰日誌的分析,以快速、準確的找到終端存在的問題。此外,便於終端生產商根據歸併後的應用崩潰日誌,獲取各類型終端的崩潰日誌中各種問題出現的比率等數據,能夠更加有針對性的進行處理,有利於改善終端的整體性能,並提高用戶體驗。
實際應用中,所述應用崩潰日誌可以為如下之一:1)java層崩潰日誌;2)native層崩潰日誌。
一種實現方式中,將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併,可以包括:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、原因和堆棧相同的應用崩潰日誌歸併。
另一種實現方式中,將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併,可以包括:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、問題信號、崩潰返回碼、崩潰信息以及堆棧相同的應用崩潰日誌歸併。
下面分別以不同實例來詳細說明日誌處理的過程。
實例1
本實例以android應用java層崩潰日誌為例進行詳細說明。
本實例中,android應用java層崩潰日誌的處理方法可以包括:伺服器接收客戶端上傳的應用java層崩潰日誌,根據所述應用java層崩潰日誌的java層崩潰堆棧信息(邏輯上認為對於相同的應用有相同java層崩潰堆棧信息是相同原因導致的),將相同原因導致的java層崩潰日誌進行歸併。這樣歸併後,大量的應用java層崩潰日誌將歸併成少量的不同java層崩潰原因導致的應用java層崩潰日誌,開發人員只對這些經過歸併的應用java層崩潰日誌進行分析即可,不僅省時省力,成本低,而且使開發人員能夠快速完成應用java層崩潰日誌的分析,以快速、準確的找到終端存在的問題。
實際應用中,製作應用java層崩潰日誌自動解析腳本,通過運行該腳本可以對上傳到伺服器上的應用java崩潰日誌進行解析歸併。經過解析歸併後,相同原因導致的應用java層崩潰日誌將歸併為一個相同問題,開發人員分析和解決問題會更加高效。
實際應用中,客戶端在log上報系統中配置受保護的廣播。當應用出現java層崩潰時,系統發送該廣播到log上報系統中。log上報系統收到廣播後,上傳出現java層崩潰的崩潰異常堆棧至伺服器,該崩潰異常堆棧為java層崩潰異常堆棧stack.txt,可以包括應用包名packagename、崩潰原因和java堆棧信息等內容。實際應用中,該客戶端可以是如圖1所示的終端。
伺服器接收客戶端上傳的崩潰異常堆棧,解析客戶端上傳的java層崩潰異常堆棧stack.txt。通過java層崩潰異常堆棧stack.txt,可獲取到出現java層崩潰的應用包名packagename,出現java層崩潰的原因reason,以及出現java層崩潰時的堆棧stack。如果兩份java層崩潰日誌的packagename、reason、stack都相同,則認為這兩個java層崩潰是相同java層崩潰問題導致的。也就是說,將packagename、reason、stack都相同的java層崩潰日誌歸併為一類(例如,歸併為一個隊列),便於開發人員按照歸併的類別進行日誌分析。
實際應用中,歸併java層崩潰日誌時可以將使用packagename+reason+stack作為關鍵字進行歸併。其中,packagename、reason和stack分別為字符串,packagename+reason+stack為上述三個字符串連結在一起形成的匹配字符串,可以以該匹配字符串為關鍵字對java層崩潰日誌進行匹配處理,從而將packagename、reason和stack都相同的java層崩潰日誌放入同一隊列進行處理。
如圖4所示,本實例中日誌處理的流程可以包括:
步驟401,獲取stack.txt文件,從文件開頭開始讀取文件行,進入步驟402。
步驟402,讀取下一行,讀取結束?如果是,則進入步驟406;如果夠,則進入步驟407。
步驟403,讀取下一行,該行字符串是否以at或…開頭,如果是則進入步驟405;如果不是,則進入步驟404。
步驟404,設置該行字符串為reason,返回步驟402。
步驟405,添加該行到stack中,返回步驟402。
步驟406,獲取到了當前應用java崩潰日誌的packagename、reason、trace之後,在已有應用java層崩潰問題隊列中查找是否包含當前應用java崩潰日誌的packagename+reason+trace,如果是,則進入步驟407,否則進入步驟408。
步驟407,將該應用java崩潰日誌作為已有應用java崩潰日誌處理,結束。
步驟408,將packagename+reason+trace添加到應用java層崩潰問題隊列,將該應用java層崩潰日誌作為新的應用java層崩潰原因處理,結束。
本實例中,將上傳到伺服器的應用java層崩潰日誌進行解析和歸併處理。根據解析出的java層崩潰的堆棧信息,對相同原因導致的java層崩潰日誌進行歸併。經過歸併後,大量的應用java層崩潰日誌將歸併成少量的不同java層崩潰原因導致的應用java層崩潰日誌,開發人員只對這些經過歸併的應用java層崩潰日誌進行分析,不僅省時省力,成本低,而且使開發人員能夠快速完成崩潰日誌的分析,以快速、準確的找到終端存在的問題。此外,便於終端生產商根據歸併後的應用崩潰日誌,獲取各類型終端的崩潰日誌中各種問題出現的比率等數據,能夠更加有針對性的進行處理,有利於改善終端的整體性能,並提高用戶體驗。
實例2
本實例以android應用native層崩潰日誌為例進行詳細說明。
本實例中,將上傳到伺服器的應用native層崩潰日誌進行解析和歸併處理。根據解析出的native層崩潰的堆棧信息(邏輯上認為對於相同的應用有相同native層崩潰堆棧信息是相同原因導致的),對相同原因導致的native層崩潰日誌進行歸併。經過歸併後,大量的應用native層崩潰日誌將歸併成少量的不同native層崩潰原因導致的應用native層崩潰日誌,開發人員只對這些經過歸併的應用native層崩潰日誌進行分析即可,使得開發人員能夠更加快速的完成應用native層崩潰日誌的分析。
實際應用中,可以製作應用native層崩潰日誌自動解析腳本,通過運行該腳本可以對上傳到伺服器的應用native崩潰日誌進行解析歸併。經過解析歸併後,相同原因導致的應用native層崩潰日誌將歸併為一個相同問題,開發人員分析和解決問題會更加高效。
實際應用中,客戶端在log上報系統中配置受保護的廣播。當應用出現native層崩潰時,系統發送該廣播到log上報系統中。log上報系統收到廣播後,上傳出現java層崩潰的崩潰異常堆棧至伺服器,該崩潰異常堆棧為java層崩潰異常堆棧stack.txt,可以包括應用包名packagename、崩潰時native堆棧信息等內容。實際應用中,該客戶端可以是如圖1所示的終端。
伺服器接收客戶端上傳的native層崩潰異常堆棧stack.txt並解析進行解析。通過native層崩潰異常堆棧stack.txt,可獲取到出現native層崩潰的應用包名packagename、出現native層崩潰時問題信號signal、崩潰返回碼code、崩潰信息abortmessage以及出現native層崩潰時的堆棧stack。如果兩份native層崩潰日誌的packagename、signal、code、abortmessage、stack都相同,則認為這兩個native層崩潰日誌是相同的native層崩潰問題導致的。也就是說,將packagename、signal、code、abortmessage、stack都相同的native層崩潰日誌歸併為一類(例如,歸併為一個隊列),便於開發人員按照歸併的類別進行native層崩潰日誌分析。
實際應用中,歸併native層崩潰日誌時可以將使用packagename+signal+code+abortmessage+stack作為關鍵字進行歸併。具體的,packagename、signal、code、abortmessage、stack都是字符串,packagename+signal+code+abortmessage
+stack為上述五個字符串連結在一起形成的匹配字符串,可以以該匹配字符串為關鍵字對native層崩潰日誌進行匹配處理,從而將packagename、signal、code、abortmessage、stack都相同的native層崩潰日誌放入同一隊列進行處理。
如圖5所示,本實例中應用native層崩潰日誌的處理流程可以包括:
步驟501,獲取stack.txt文件,從文件開頭開始讀取文件行,進入步驟502。
步驟502,讀取下一行,是否讀取結束,如果是則進入步驟510,如果不是則進入步驟503。
步驟503,該行字符串是否包含packagename,如果不是則進入步驟502;如果是則進入步驟504。
步驟504,獲取下一行的問題信號(signal)、問題返回碼(code),繼續進入步驟505。
步驟505,繼續獲取下一行的崩潰信息abortmessage,繼續進入步驟506。
步驟506,讀取下一行,是否讀取結束,如果否則返回步驟507,如果是則進入步驟510。
步驟507,該行字符串是否包含回溯堆棧(backtrace),如果否則返回步驟506;如果是則進入步驟508。
步驟508,繼續讀取下一行,是否讀取結束,如果否則進入步驟509;如果是則進入步驟510。
步驟509,該行是否包含/system或者/data,如果是則繼續步驟510,否則返回步驟508。
實際應用中,系統應用安裝後,是安裝在/system分區中。第三方應用或者系統應用更新包是安裝在/data分區中。所以當發生nativecrash時,出現異常的庫文件的路徑以/system或/data開頭。因此,在步驟509中要驗證該含是否包含/system或者/data,以確認是否為出現異常的庫文件。
步驟510,將該字符串存入stack。
步驟511,此時已獲取到當前應用native崩潰日誌的packagename,signal、code、abortmessage以及stack,判斷已有應用native層崩潰問題隊列中查找是否包含packagename+signal+code+abortmessage+stack,如果是則進入步驟512,否則進入步驟513。
步驟512,將該應用native崩潰日誌作為已有應用native崩潰日誌處理,結束。
步驟513,將packagename+signal+code+abortmessage+stack添加到應用native層崩潰問題隊列,將該應用native層崩潰日誌作為新的應用native層崩潰原因處理,結束。
本實例中,將上傳到伺服器的應用native層崩潰日誌進行解析和歸併處理。根據native層崩潰的堆棧信息,對相同原因導致的native層崩潰日誌進行歸併。經過歸併後,大量的應用native層崩潰日誌將歸併成少量的不同native層崩潰原因導致的應用native層崩潰日誌,開發人員只對這些經過歸併的應用native層崩潰日誌進行分析,不僅省時省力,成本低,而且使開發人員能夠快速完成崩潰日誌的分析,以快速、準確的找到終端存在的問題。此外,便於終端生產商根據歸併後的應用崩潰日誌,獲取各類型終端的崩潰日誌中各種問題出現的比率等數據,能夠更加有針對性的進行處理,有利於改善終端的整體性能,並提高用戶體驗。
實施例二
根據本發明的另一實施例,提供了一種日誌處理裝置,如圖6所示,可以包括:
接收模塊61,用於接收來自客戶端的崩潰異常堆棧;
歸併模塊62,用於將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
實際應用中,所述應用崩潰日誌為如下之一:java層崩潰日誌;native層崩潰日誌。
一種實現方式中,所述歸併模塊62,具體可以用於:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、原因和堆棧相同的應用崩潰日誌歸併。
另一種實現方式中,所述歸併模塊62,具體可以用於:解析所述崩潰異常堆棧,獲取崩潰堆棧信息;將所述崩潰堆棧信息中應用包名、問題信號、崩潰返回碼、崩潰信息以及堆棧相同的應用崩潰日誌歸併。
本實施例中的日誌處理裝置可以實現實施例一所述方法的所有細節,可參照方法的相關說明。實際應用中,本實施例中的日誌處理裝置可以通過設置於伺服器或其他類似設備上來實現上述功能,或者本實施例中的日誌處理裝置可以直接通過伺服器或其他類似設備來實現。
實際應用中,接收模塊61和歸併模塊62分別可以通過軟體、硬體或兩者結合的方式實現。對此,本文不作限制。例如,接收模塊61和歸併模塊62可以通過應用崩潰日誌自動解析腳本來實現。
如圖7所示,為上述伺服器的結構示意圖,包括:輸入輸出(io)總線、處理器70、存儲器71、內存72和通信裝置73。其中,
輸入輸出(io)總線分別與自身所屬的伺服器的其它部件(處理器70、存儲器71、內存72和通信裝置73)連接,並且為其它部件提供傳送線路。
處理器70通常控制自身所屬的伺服器的總體操作。例如,處理器70執行計算和確認等操作。其中,處理器70可以是中央處理器(cpu)。
通信裝置73,通常包括一個或多個組件,其允許自身所屬的伺服器與無線通信系統或網絡之間的無線電通信。
存儲器71存儲處理器70可讀、處理器可執行的軟體代碼,其包含用於控制處理器70執行本文描述的功能的指令(即軟體執行功能)。
其中,上述日誌處理裝置中,實現接收模塊61和歸併模塊62的功能的軟體代碼可存儲在存儲器71中,並由處理器70執行或編譯後執行。
實施例三
根據本發明的又一實施例,提供了一種設備,包括存儲器、處理器及存儲在存儲器上並可在處理器上運行的電腦程式,所述處理器執行所述程序時實現以下步驟:
接收來自客戶端的崩潰異常堆棧;
將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
本實施例中的設備可以實現實施例一所述方法的所有細節,可參照方法的相關說明。實際應用中,本實施例中的設備可以通過通過伺服器或其他類似設備來實現。例如,可以通過圖7所示的伺服器來實現。
實施例四
根據本發明的又一實施例,提供了一種計算機可讀存儲介質,其上存儲有電腦程式,該程序被處理器執行時實現以下步驟:
接收來自客戶端的崩潰異常堆棧;
將所述崩潰異常堆棧所指示原因相同的應用崩潰日誌歸併。
可選地,在本實施例中,上述存儲介質可以包括但不限於:u盤、只讀存儲器(rom,read-onlymemory)、隨機存取存儲器(ram,randomaccessmemory)、移動硬碟、磁碟或者光碟等各種可以存儲程序代碼的介質。
可選地,在本實施例中,處理器根據存儲介質中已存儲的程序代碼執行上述實施例的方法步驟。
可選地,本實施例中的具體示例可以參考上述實施例及可選實施方式中所描述的示例,本實施例在此不再贅述。
需要說明的是,在本文中,術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含,從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素,而且還包括沒有明確列出的其他要素,或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下,由語句「包括一個……」限定的要素,並不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。
上述本發明實施例序號僅僅為了描述,不代表實施例的優劣。
通過以上的實施方式的描述,本領域的技術人員可以清楚地了解到上述實施例方法可藉助軟體加必需的通用硬體平臺的方式來實現,當然也可以通過硬體,但很多情況下前者是更佳的實施方式。基於這樣的理解,本發明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來,該計算機軟體產品存儲在一個存儲介質(如rom/ram、磁碟、光碟)中,包括若干指令用以使得一臺終端設備(可以是手機,計算機,伺服器,空調器,或者網絡設備等)執行本發明各個實施例所述的方法。
以上僅為本發明的優選實施例,並非因此限制本發明的專利範圍,凡是利用本發明說明書及附圖內容所作的等效結構或等效流程變換,或直接或間接運用在其他相關的技術領域,均同理包括在本發明的專利保護範圍內。