原文出自【聽雲技術部落格】：
「崩潰，嚴重傷害使用者的情感，嚴重損害使用者體驗，罪惡行徑簡直令人髮指，特請xx獅、xx猿火速緝拿案犯歸案，刻不容緩，欽此。」
上圖所示，已經定位到某原始檔的某行，再加上崩潰message，崩潰的原因就顯而易見了。
但有些崩潰的原因就不是那麼顯而易見了，往往需要尋找更多蛛絲馬跡來定位問題，要不然也談不上什麼「分析」了。
本文用兩個例子說明「崩潰軌跡」在分析崩潰過程中的重要作用。
「崩潰軌跡」介紹
遇到難分析的崩潰時，最想得到的資訊是：使用者當時是怎麼操作的？如何能復現崩潰？
「崩潰軌跡」也即「互動軌跡」，它記錄的是崩潰前若干連續的使用者操作。利用這些操作，或者能復現崩潰（這是最理想的），或者幫助縮小嫌疑範圍。
下圖是乙個崩潰軌跡，先來認識一下：
好了，我們通過兩個例子進一步了解「崩潰軌跡」的作用。
案例1
我們幫客戶分析時發現，這個堆疊沒有反映出崩潰的原因，對於分析沒有什麼幫助。
這時我們把眼光投向「崩潰軌跡」，如圖：
能復現就好辦了，直接聯機除錯，問題立即解決。
案例2:
這個例子是幾天剛發生的，棧資訊如圖：
同樣的，也是崩潰堆疊只有main函式，也是一頭霧水，但崩潰軌跡提供了重要資訊，請看軌跡：
最後乙個操作發生在崩潰前0秒，這意味著崩潰就發生在那個函式裡，這一下子範圍小多了！雖然這個崩潰不是必現，沒有按照軌跡復現出來，但因為「嫌疑」範圍就在那幾行，客戶的開發人員很快就想到了問題所在。
通過以上兩個例子介紹崩潰軌跡的重要作用，希望對大家有幫助。
利用「崩潰軌跡」分析崩潰
更多技術乾貨請戳 聽雲部落格 崩潰，嚴重傷害使用者的情感，嚴重損害使用者體驗，罪惡行徑簡直令人髮指，特請xx獅 xx猿火速緝拿案犯歸案，刻不容緩，欽此。上圖所示，已經定位到某原始檔的某行，再加上崩潰message，崩潰的原因就顯而易見了。但有些崩潰的原因就不是那麼顯而易見了，往往需要尋找更多蛛絲馬跡...
利用 bugly 分析應用崩潰
bugly crash監控能讓我們及時的掌控應用的crash，並快速修復。這種情況就在於我們把應用發布出去了，但是使用者那邊有著各種各樣我們想象不到的系統崩潰，我們無法通過簡單的控制台捕獲錯誤資訊和崩潰的堆疊內容，那麼我們可以利用bugly這樣乙個平台，實時查獲我們的crash資訊。3 開啟sdk的...
liunx 利用supervisor 崩潰重啟程序
以ubuntu為例子 第一步 安裝apt get install supervisor centos 用 yum install 第二步 配置程式路徑 etc init.d supervisor 配置路徑 etc supervisor supervisord.conf 擴充套件路徑 etc supe...