1.通常我們自己會在程式中加入友盟或者bugly來監聽後期線上的執行，bugly記得上傳符號表檔案定位.
2.另外一種是處理測試提交給我們的一些堆疊bug資訊。
先說定位bugly的卡頓崩潰資訊。
1.獲取符號表檔案
使用命令獲取dsym檔案的uuid，對照crash日誌裡的uuid，如果一致則進行下一步
對照執行環境 找出uuid執行一致的執行環境 是arm64 armv7
3.找到錯誤部分
一般錯誤位置都是在專案名後面的堆疊位址，corefoundation、uikit等後面的堆疊位址無法定位
4.定位
在終端中進入.dsym檔案的所在目錄下
cd /users/01/desktop/***.xcarchive/dsyms
查詢定位
錯誤**位址及程式基位址的獲取見上文
即可定位到**位置. -[yyview init_tableview] (in ***) (yyview.m:828) 括號裡的是**所在類別和行數
第二種就是直接通過堆疊位址定位到崩潰位置的資訊
其實用堆檔案分析有3種情況
1. 直接標出了錯誤位置的
3 fir 0x000000010bfddd8c -[firviewcontroller viewdidload] + 8588
3 fir 0x000e3e92 0xd3000 + 69266
結果: [firviewcontroller viewdidload] (firviewcontroller.m:156)
可以看到崩潰的類為 firviewcontroller，函式為 viewdidload，檔名是 firviewcontroller.m，行數是 156 行。
3 fir 0x000f0e97 fir + 69271
計算基位址 方法位址-偏移位址
－load address ＝ 0x000f0e97 － 69271 ＝0xe0000. 說一下這種計算方式 把方法位址轉換成10進製資料減去偏移的位址量 就是基位址的10進製表示式，再轉換成16進製表示就可以了 16進製表示前面要加0x
使用下面的命令符號化：
atos -arch armv7 -o fir -l 0xe0000 0x000f0e97
-[firviewcontroller viewdidload] (firviewcontroller.m:156)
專案上線後的專案總結
某公司oa 專案上線後的自我總結 專案中的不足 1 沒有再進一步明確合同簽訂時的合同範圍，例如合同中說明了有 30個審批流程，結果做到了 36個。2 沒有嚴格的簽訂專案章程和專案範圍說明書 需要進一步強調明確章程和範圍 導致真正需求產生變更時，沒有特別嚴格的依據支撐增加費用。3 工作安排分配不合理，...
線上的專案如何快速定位問題
記得面試的時候就被問到過這個問題 專案出了問題，是如何快速定位並解決的，當時支支吾吾解釋了半天，最後說專案上線後就不是自己負責了 現在想想真的是沒有經驗啊。現在馬上就要過節了，因為是網際網路公司，所以假期也不能完全放鬆，有了問題也要第一時間定位問題，找到解決辦法。所以我們公司還給大家配了隨身wifi...
app做好後如何上線 上線後如何進行app運營？
一 線上推廣 3 新聞推廣。這是一種效果不錯的推廣手段，能在極短時間內使產品獲得大量 得花一點預算，撰寫新聞稿，注意文章標題一定要夠吸引眼球，同時發布到多個主流新聞門戶 上，造勢，給人一種這款產品很火的感覺。二 線下推廣 1 地推，地推最大的優勢就是讓我們的潛在客戶遇到，而不是僅僅看到。當地推人員將...