一、如何查看App的運(yùn)行日志

當(dāng)我們面臨難以定位的應(yīng)用程序錯(cuò)誤時(shí)，特別是在iOS設(shè)備上存在測(cè)試版與發(fā)布版的差異時(shí)，查看應(yīng)用的運(yùn)行日志就顯得尤為重要。日志中可能包含我們需要的關(guān)于應(yīng)用性能、錯(cuò)誤和警告的信息。 打開Xcode工具，通過(guò)以下路徑導(dǎo)航：

Xcode → Window → Devices and Simulators。 這將打開一個(gè)包含設(shè)備模擬器的窗口。點(diǎn)擊“Open Console”按鈕，即可打開詳細(xì)的日志信息窗口。在這里，你可以通過(guò)關(guān)鍵詞搜索找到有關(guān)應(yīng)用的有用信息。 對(duì)于Android應(yīng)用，你可以通過(guò)Android Studio來(lái)查看日志。路徑如下：

Android Studio → Tools → Android → Android Device Monitor。 在Android的日志系統(tǒng)中，你也可以通過(guò)一些搜索技巧來(lái)查找特定的問(wèn)題。

二、移動(dòng)應(yīng)用測(cè)試中的APP日志抓取攻略

在移動(dòng)應(yīng)用的滲透測(cè)試中，對(duì)應(yīng)用日志進(jìn)行分析是檢測(cè)敏感信息安全風(fēng)險(xiǎn)的關(guān)鍵環(huán)節(jié)。日志中若包含敏感信息，可能會(huì)導(dǎo)致數(shù)據(jù)泄露。 當(dāng)應(yīng)用出現(xiàn)Crash崩潰或ANR阻塞等異常時(shí)，收集和應(yīng)用日志能幫助我們快速定位錯(cuò)誤位置，輔助開發(fā)者進(jìn)行調(diào)試和修復(fù)程序。Android的日志系統(tǒng)為我們提供了查看系統(tǒng)調(diào)試信息的便利功能。 為了有效管理和使用adb工具，我們需要先安裝它并配置相應(yīng)的環(huán)境變量。adb即Android Debug Bridge，是一個(gè)命令行工具，支持安裝/卸載應(yīng)用、打開應(yīng)用及查看應(yīng)用日志等操作。 在使用adb時(shí)，我們可以運(yùn)用一些常用的ADB命令進(jìn)行操作。例如查看adb版本、連接設(shè)備、執(zhí)行l(wèi)ogcat命令等。在mac os系統(tǒng)中，我們可以通過(guò)brew進(jìn)行安裝adb，并在.bash_profile中添加環(huán)境變量以確保adb命令的可調(diào)用性。 由于Android的log輸出量較大，我們通常會(huì)通過(guò)定義不同的緩沖區(qū)來(lái)管理日志輸出，以確保關(guān)鍵信息的有效收集。這些緩沖區(qū)包括Radio、System、Event和Main等。應(yīng)用日志主要輸出到Main緩沖區(qū)，便于我們分析應(yīng)用內(nèi)部的錯(cuò)誤和情況。 在連接設(shè)備后，我們可以通過(guò)adb devices命令確認(rèn)連接狀態(tài)。使用adb logcat可以查看所有應(yīng)用的日志輸出，以便我們進(jìn)行精準(zhǔn)的分析。為了獲取特定應(yīng)用的日志，我們需要先列出設(shè)備已安裝的應(yīng)用，并查看應(yīng)用的包名。我們還需要獲取應(yīng)用的pid，這通常需要在手機(jī)上打開應(yīng)用以分配進(jìn)程。需要注意的是，同一包名下的pid可能會(huì)因?yàn)閼?yīng)用的關(guān)閉和重啟而發(fā)生變化。 獲取pid后，我們可以有針對(duì)性地輸出特定應(yīng)用的日志，以便更精準(zhǔn)地定位問(wèn)題和進(jìn)行調(diào)試。將日志導(dǎo)出到文件中也是一種好的做法，這樣我們可以更方便地查找和整理日志信息。在導(dǎo)出日志時(shí)，我們需要注意設(shè)置文本寫入權(quán)限，以確保文件可以正常寫入。

一、如何獲取Crash日志

當(dāng)你的iOS應(yīng)用程序崩潰時(shí)，系統(tǒng)會(huì)生成一個(gè)crash日志并保存在設(shè)備上。這個(gè)日志對(duì)開發(fā)人員來(lái)說(shuō)極其重要，因?yàn)樗梢詭椭ㄎ粏?wèn)題。

如果設(shè)備在身邊

連接你的設(shè)備到電腦，打開Xcode，選擇Window菜單下的Organizer。在左側(cè)面板中，選擇你的設(shè)備，點(diǎn)擊Logs。你可以根據(jù)時(shí)間排序查看設(shè)備上的crash日志。這是開發(fā)和測(cè)試階段最常用的方法。

如果應(yīng)用已發(fā)布在App Store

對(duì)于已經(jīng)提交到App Store的應(yīng)用，你可以通過(guò)iTunes Connect獲取用戶的crash日志。但這并不是百分百有效的，因?yàn)樾枰脩粼O(shè)備同意上傳相關(guān)信息?？紤]到不是所有用戶都允許發(fā)送診斷報(bào)告，對(duì)于部分提交的crash日志，開發(fā)者可能需要手動(dòng)拉取，并找到對(duì)應(yīng)的符號(hào)文件進(jìn)行解析。實(shí)際項(xiàng)目中通常會(huì)接入現(xiàn)有的crash收集工具或者自行編寫程序進(jìn)行自動(dòng)化收集、解析和統(tǒng)計(jì)匯總。

二、如何解析Crash日志

獲得的crash日志通常以十六進(jìn)制地址等原始信息展示，我們需要將其映射為源代碼級(jí)別的方法名稱和代碼行數(shù)，使其對(duì)開發(fā)人員可讀。這個(gè)過(guò)程稱為符號(hào)化解析。

如果處于開發(fā)調(diào)試階段，Xcode通常能匹配到crash日志對(duì)應(yīng)的二進(jìn)制文件和符號(hào)文件，從而幫我們自動(dòng)解析。對(duì)于測(cè)試階段產(chǎn)生的crash日志，需要保存好對(duì)應(yīng)版本的二進(jìn)制文件和符號(hào)文件。將.crash文件、.app文件和.dSYM文件三者放在同一目錄下，然后將.crash文件拖放到Xcode的Window菜單下的Organizer中的Library下的Device Logs中，即可進(jìn)行解析。

三、如何分析Crash日志

在分析crash日志前，了解常見的錯(cuò)誤類型對(duì)開發(fā)人員來(lái)說(shuō)是很有幫助的。Crash日志的產(chǎn)生主要源于兩種問(wèn)題：違反iOS策略導(dǎo)致的應(yīng)用被終止，以及應(yīng)用自身的代碼bug。

常見錯(cuò)誤類型

1. 內(nèi)存問(wèn)題：如數(shù)組越界、內(nèi)存泄漏等。

2. 線程問(wèn)題：如線程間同步問(wèn)題導(dǎo)致的競(jìng)態(tài)條件。

3. 邏輯錯(cuò)誤：如空指針解引用、錯(cuò)誤的參數(shù)傳遞等。

4. 第三方庫(kù)沖突：某些第三方庫(kù)可能與你的應(yīng)用或其他庫(kù)存在沖突。

分析步驟

1. 定位崩潰線程：找到崩潰發(fā)生的線程，關(guān)注其調(diào)用棧。

2. 符號(hào)化解析：將日志中的地址映射為具體的代碼行和方法名稱。

3. 檢查相關(guān)代碼：查看崩潰發(fā)生處的代碼，分析可能的原因。

4. 用戶環(huán)境分析：了解崩潰發(fā)生的設(shè)備、系統(tǒng)版本等信息，看是否與特定環(huán)境有關(guān)。

四、預(yù)防Crash的策略

為了避免應(yīng)用崩潰，除了加強(qiáng)代碼質(zhì)量外，還可以考慮以下幾點(diǎn)：

1. 異常捕獲：在關(guān)鍵路徑上添加異常捕獲和處理機(jī)制。

2. 代碼審查：定期進(jìn)行代碼審查，確保代碼質(zhì)量。

3. 單元測(cè)試與自動(dòng)化測(cè)試：增加測(cè)試覆蓋率，確保功能正常。

4. 監(jiān)控與警報(bào)：接入第三方監(jiān)控工具，實(shí)時(shí)獲取crash信息并設(shè)置警報(bào)。

五、總結(jié)與展望

獲取、解析和分析iOS應(yīng)用的crash日志是應(yīng)用開發(fā)過(guò)程中的重要環(huán)節(jié)。通過(guò)有效的管理和分析，可以幫助我們更好地了解應(yīng)用的狀態(tài)，提高應(yīng)用的穩(wěn)定性和用戶體驗(yàn)。隨著技術(shù)的不斷進(jìn)步，我們期待有更智能的工具幫助我們自動(dòng)化地處理這些問(wèn)題，使應(yīng)用開發(fā)更加高效和穩(wěn)定。iOS應(yīng)用崩潰策略詳解

一、低內(nèi)存閃退

在iOS應(yīng)用中，大多數(shù)crash日志都包含了執(zhí)行線程的棧調(diào)用信息，但低內(nèi)存閃退日志卻有所不同。當(dāng)使用Xcode 5和iOS 7的設(shè)備進(jìn)行低內(nèi)存閃退模擬時(shí)，通過(guò)Organizer查看產(chǎn)生的crash日志，我們會(huì)發(fā)現(xiàn)Process和Type都為Unknown。

具體的日志內(nèi)容可以分為三部分：

1. 崩潰信息：包括識(shí)別標(biāo)識(shí)、軟硬件信息和時(shí)間信息等。

2. 內(nèi)存頁(yè)分配信息：展示當(dāng)前占用內(nèi)存最多的進(jìn)程，如上圖中的crashTypeDemo。

3. 進(jìn)程列表：描述每個(gè)進(jìn)程使用內(nèi)存的情況和當(dāng)前狀態(tài)。在較早的iOS版本中，可能會(huì)出現(xiàn)因使用過(guò)多內(nèi)存而被終止的“jettisoned”字樣，而在現(xiàn)在則更多看到的是“vm-pageshortage”。

當(dāng)iOS檢測(cè)到內(nèi)存過(guò)低時(shí)，會(huì)發(fā)出低內(nèi)存警告通知，嘗試回收內(nèi)存；若情況未改善，會(huì)終止后臺(tái)應(yīng)用回收更多內(nèi)存；若內(nèi)存仍不足，正在運(yùn)行的應(yīng)用也可能被終止。開發(fā)者應(yīng)合理響應(yīng)低內(nèi)存警告通知，釋放緩存數(shù)據(jù)和可重新創(chuàng)建的對(duì)象，并避免內(nèi)存泄露。

低內(nèi)存閃退是由iOS策略決定的，同樣基于iOS策略的還有Watchdog超時(shí)和用戶強(qiáng)制退出。

二、Watchdog超時(shí)

Watchdog超時(shí)是Apple的iOS Developer Library網(wǎng)站上QA1693文檔描述的一種機(jī)制。當(dāng)應(yīng)用程序?qū)μ囟ǖ腢I（如啟動(dòng)、掛起、恢復(fù)、結(jié)束）響應(yīng)不及時(shí)，Watchdog會(huì)終止應(yīng)用程序并生成一份crash報(bào)告。這份報(bào)告的異常代碼為“0x8badf00d”，即“ate bad food”。

具體可能導(dǎo)致Watchdog超時(shí)的場(chǎng)景包括在主線程進(jìn)行同步網(wǎng)絡(luò)請(qǐng)求或數(shù)據(jù)量大的數(shù)據(jù)庫(kù)版本遷移等。開發(fā)者在遇到Watchdog日志時(shí)，應(yīng)檢查是否存在阻塞UI的較重操作，特別是在UIApplicationDelegate的幾個(gè)方法中。

三、用戶強(qiáng)制退出

用戶強(qiáng)制退出包括雙擊Home鍵關(guān)閉應(yīng)用和同時(shí)按住電源鍵和Home鍵使iPhone重啟兩種場(chǎng)景。前者不會(huì)產(chǎn)生crash日志，因?yàn)殛P(guān)閉的是后臺(tái)進(jìn)程。而后者雖然會(huì)產(chǎn)生日志，但并不針對(duì)特定應(yīng)用程序。開發(fā)者主要需要關(guān)注應(yīng)用內(nèi)的邏輯穩(wěn)定性和響應(yīng)速度，以預(yù)防因用戶強(qiáng)制退出導(dǎo)致的用戶體驗(yàn)下降。

四、應(yīng)對(duì)策略

對(duì)于上述三種可能導(dǎo)致應(yīng)用崩潰的策略，開發(fā)者應(yīng)采取以下措施進(jìn)行預(yù)防和應(yīng)對(duì)：

1. 對(duì)于低內(nèi)存閃退，應(yīng)合理管理內(nèi)存，及時(shí)釋放不再使用的資源，避免內(nèi)存泄露。響應(yīng)系統(tǒng)低內(nèi)存警告通知，及時(shí)采取措施回收內(nèi)存。

2. 對(duì)于Watchdog超時(shí)，應(yīng)優(yōu)化UI響應(yīng)速度，避免在主線程進(jìn)行阻塞操作。特別是在進(jìn)行網(wǎng)絡(luò)請(qǐng)求或數(shù)據(jù)庫(kù)操作時(shí)，要確保響應(yīng)的及時(shí)性。

3. 對(duì)于用戶強(qiáng)制退出，應(yīng)提高應(yīng)用的穩(wěn)定性和響應(yīng)速度，減少因應(yīng)用崩潰或卡頓導(dǎo)致的用戶強(qiáng)制退出。關(guān)注用戶反饋，及時(shí)處理因應(yīng)用問(wèn)題導(dǎo)致的用戶體驗(yàn)下降。

五、總結(jié)

iOS應(yīng)用的穩(wěn)定性對(duì)于用戶體驗(yàn)至關(guān)重要。了解并應(yīng)對(duì)低內(nèi)存閃退、Watchdog超時(shí)和用戶強(qiáng)制退出等策略是開發(fā)者的重要任務(wù)。通過(guò)合理管理內(nèi)存、優(yōu)化UI響應(yīng)速度和提高應(yīng)用穩(wěn)定性等措施，可以有效提升應(yīng)用的用戶體驗(yàn)。深入解析iOS中的異常崩潰場(chǎng)景

一、用戶強(qiáng)制退出場(chǎng)景解析

在iOS系統(tǒng)中，用戶強(qiáng)制退出應(yīng)用程序是一種相對(duì)復(fù)雜的操作。當(dāng)遇到應(yīng)用程序卡教或響應(yīng)遲緩時(shí)，用戶會(huì)先按住電源鍵，直到出現(xiàn)“滑動(dòng)關(guān)機(jī)”的界面，然后再按住Home鍵，此時(shí)應(yīng)用程序會(huì)被強(qiáng)制終止，系統(tǒng)會(huì)產(chǎn)生一份包含相關(guān)信息的crash日志。這種操作相對(duì)高級(jí)，因此產(chǎn)生的crash日志較為少見。

二、常見錯(cuò)誤標(biāo)識(shí)詳解

(一) Exception codes

在iOS的crash日志中，我們經(jīng)常會(huì)遇到一些特定的異常代碼，如“0xdeadfa11”、“0x8badf00d”等。這些代碼是蘋果官方定義的特定異常代碼，每一種代碼都代表一種特定的錯(cuò)誤場(chǎng)景。

1. 0x8badf00d錯(cuò)誤碼：代表Watchdog超時(shí)，意為系統(tǒng)監(jiān)控程序超時(shí)未響應(yīng)，類似于“ate bad food”。

2. 0xdeadfa11錯(cuò)誤碼：代表用戶強(qiáng)制退出，意為操作過(guò)程中的意外終止，可簡(jiǎn)稱為“dead fall”。

3. 其他錯(cuò)誤代碼如0xbaaaaaad、0xbad22222、0xc00010ff和0xdead10cc等，各自代表不同的錯(cuò)誤情況。

(二) Exception types

查看crash分析報(bào)告郵件，最常遇到的錯(cuò)誤類型是SEGV（Segmentation Violation，段違例）。這通常表示內(nèi)存操作不當(dāng)，如訪問(wèn)無(wú)效內(nèi)存地址、嘗試寫入只讀區(qū)域、解引用空指針等。當(dāng)收到SEGV信號(hào)時(shí)，我們可以從以下幾個(gè)方面進(jìn)行排查：

1. 訪問(wèn)無(wú)效內(nèi)存地址，例如訪問(wèn)已經(jīng)釋放的內(nèi)存（Zombie對(duì)象）。

2. 嘗試向只讀區(qū)域?qū)懭霐?shù)據(jù)。

3. 解引用空指針。

4. 使用未初始化的指針。

5. 棧溢出。

還有其他常見的信號(hào)，如SIGABRT（收到Abort信號(hào)）和SIGBUS（總線錯(cuò)誤）等。

===============================

一、程序崩潰的信號(hào)概述

在軟件開發(fā)過(guò)程中，程序崩潰是一個(gè)常見的問(wèn)題。當(dāng)程序遇到某些特定的錯(cuò)誤情況時(shí)，操作系統(tǒng)會(huì)發(fā)送信號(hào)來(lái)通知程序出現(xiàn)嚴(yán)重錯(cuò)誤，這些信號(hào)包括SIGSEGV、SIGBUS、SIGILL和SIGFPE等。了解這些信號(hào)的含義對(duì)于快速定位和解決問(wèn)題至關(guān)重要。

二、信號(hào)詳解

1. SIGSEGV：此信號(hào)表示程序訪問(wèn)了無(wú)效的內(nèi)存地址。例如，當(dāng)程序試圖讀取或?qū)懭胍粋€(gè)未被映射到物理內(nèi)存的虛擬內(nèi)存地址時(shí)，就會(huì)觸發(fā)此信號(hào)。

2. SIGBUS：與SIGSEGV不同，SIGBUS表示程序訪問(wèn)了有效地址，但由于總線訪問(wèn)異常而導(dǎo)致錯(cuò)誤。這通常是由于地址對(duì)齊問(wèn)題引起的。

3. SIGILL：當(dāng)程序嘗試執(zhí)行非法的指令時(shí)，會(huì)收到此信號(hào)。這些指令可能不被識(shí)別或者執(zhí)行時(shí)沒(méi)有足夠的權(quán)限。

4. SIGFPE：此信號(hào)表示在程序執(zhí)行過(guò)程中發(fā)生了浮點(diǎn)錯(cuò)誤。這可能是由于數(shù)學(xué)計(jì)算中的各種問(wèn)題，如除零操作等。

5. SIGPIPE：當(dāng)程序嘗試向一個(gè)沒(méi)有接收進(jìn)程的管道寫入數(shù)據(jù)時(shí)，會(huì)觸發(fā)此信號(hào)。

三、代碼bug導(dǎo)致的崩潰

除了上述由于操作系統(tǒng)發(fā)送的信號(hào)導(dǎo)致的崩潰外，比較常見的崩潰大多源于代碼中的bug。這些bug包括但不限于數(shù)組越界、內(nèi)存泄漏、多線程安全性問(wèn)題、訪問(wèn)野指針以及未實(shí)現(xiàn)的selector等。其中，多線程問(wèn)題尤為復(fù)雜，當(dāng)遇到難以解決的bug時(shí)，可以考慮是否涉及多線程的問(wèn)題。

四、錯(cuò)誤原因與解決思路

當(dāng)程序崩潰時(shí)，通常會(huì)伴隨著清晰的錯(cuò)誤原因說(shuō)明，如“index 0 beyond bounds for empty array”等。對(duì)于這些錯(cuò)誤，我們需要仔細(xì)審查代碼邏輯，找到導(dǎo)致問(wèn)題的根本原因。對(duì)于多線程問(wèn)題，由于其復(fù)雜性，可能需要更深入的排查和考慮。

五、引入Core Data的常見問(wèn)題

如果程序中引入了Core Data等數(shù)據(jù)處理框架，那么可能會(huì)面臨另外一些常見問(wèn)題。這些問(wèn)題通常與數(shù)據(jù)模型、關(guān)系映射以及并發(fā)操作等有關(guān)。為了有效解決這個(gè)問(wèn)題，我們需要深入了解Core Data的使用方式和最佳實(shí)踐，同時(shí)保持對(duì)錯(cuò)誤日志的持續(xù)關(guān)注。

理解并掌握這些程序崩潰的信號(hào)和代碼bug，對(duì)于軟件開發(fā)者來(lái)說(shuō)是非常重要的。在遇到問(wèn)題時(shí)，能夠快速定位并解決，有效提高開發(fā)效率和軟件質(zhì)量。