App審核被拒，求解答

一、審核拒絕原因概述

您的應(yīng)用程序因以下原因未能通過審核：

1. 程序存在重大bug：程序無法啟動或在運行過程中意外退出。

2. 繞過蘋果的付費渠道：您之前游戲的兌換碼兌換金幣方式可能存在問題。

3. 實物獎勵未明確說明：若游戲內(nèi)含有實物獎勵，必須明確獎勵由您公司承擔(dān)，與蘋果無關(guān)。

4. 使用蘋果標(biāo)志或相似Logo：應(yīng)用設(shè)計若使用與Apple Logo相似的風(fēng)格也可能導(dǎo)致審核不通過。

5. 網(wǎng)絡(luò)功能故障：應(yīng)用程序的網(wǎng)絡(luò)連接功能無法正常使用。

6. 圖標(biāo)問題：部分圖標(biāo)無法點擊，需置灰或隱藏。

7. 未設(shè)置默認(rèn)頁面或啟動畫面為黑屏：有一定概率導(dǎo)致應(yīng)用被拒絕。

8. 重復(fù)提交相似應(yīng)用：若已有一個應(yīng)用在線，再提交類似的豪華版應(yīng)用可能會被拒絕。

二、關(guān)于iOS系統(tǒng)背景知識

iOS是蘋果公司開發(fā)的移動操作系統(tǒng)，最初為iPhone設(shè)計，后應(yīng)用于iPod touch、iPad和Apple TV等產(chǎn)品。此系統(tǒng)與Mac OS X一樣，屬于類Unix的商業(yè)操作系統(tǒng)。原名iPhoneOS，因應(yīng)用于多款產(chǎn)品而更名為iOS。iOS系統(tǒng)名為美國Cisco公司的注冊商標(biāo)，蘋果公司在使用前已獲得Cisco的授權(quán)。

三、iOS手機測試時如何獲取App的崩潰日志

對于開發(fā)者而言，獲取iOS應(yīng)用程序的崩潰日志是定位問題的重要步驟。以下是獲取崩潰日志的方法：

當(dāng)應(yīng)用程序崩潰時，系統(tǒng)會生成crash日志保存在設(shè)備上。這份日志包含了應(yīng)用程序崩潰時的詳細(xì)信息，對開發(fā)者非常有幫助。

若設(shè)備在身邊，可通過Xcode查看。打開Xcode，選擇Window菜單下的Organizer，在左側(cè)面板中選擇設(shè)備，然后查看Device Logs或Library下的所有設(shè)備日志。根據(jù)時間排序可以找到應(yīng)用程序的崩潰日志。

若應(yīng)用程序已發(fā)布在App Store上，開發(fā)者可通過iTunes Connect獲取用戶的崩潰日志，但這需要用戶設(shè)備同意上傳相關(guān)信息。實際上，考慮到許多用戶可能不會選擇上傳診斷報告，開發(fā)者通常會選擇接入現(xiàn)有的crash收集工具或自行編寫程序進(jìn)行自動化收集、解析和統(tǒng)計匯總。

在實際開發(fā)過程中，獲取和分析崩潰日志是確保應(yīng)用程序質(zhì)量的關(guān)鍵環(huán)節(jié)。希望以上信息能幫助您解決問題，提升您的應(yīng)用開發(fā)體驗。二、如何解析Crash日志

當(dāng)你拿到一份Crash日志時，面對滿屏的十六進(jìn)制地址和原始信息，如何將其轉(zhuǎn)化為開發(fā)人員易于理解的格式，以便快速定位和解決問題呢？這就需要我們進(jìn)行符號化解析。

1. 符號化解析概述

符號化解析是將Crash日志中的十六進(jìn)制地址等原始信息，映射為源代碼級別的方法名稱和代碼行數(shù)，使其對開發(fā)人員可讀。這個過程需要應(yīng)用程序的二進(jìn)制文件和符號(.dSYM)文件的支持。

2. 開發(fā)調(diào)試階段的解析

在開發(fā)調(diào)試階段，Xcode通常能夠自動匹配到Crash日志對應(yīng)的二進(jìn)制文件和符號文件，因此可以幫我們自動解析。

3. 測試階段的解析

在測試階段，由于測試人員可能安裝了不同的版本（如alpha、beta版本），因此需要保存好對應(yīng)版本的二進(jìn)制文件和符號文件。解析時，只需將.crash文件、.app文件和.dSYM文件三者放在同一目錄下，然后將.crash文件拖放到Xcode的Window-Organizer中，即可進(jìn)行解析。

4. 提交發(fā)布階段的解析

在提交發(fā)布前，通常會先執(zhí)行Clean，再Build，最后通過Product-Archive來打包。這樣，Xcode會將二進(jìn)制文件和符號文件歸檔在一起。在Organizer中的Archives可以進(jìn)行瀏覽和管理。

三、如何分析Crash日志

拿到一份解析后的Crash日志，如何快速定位問題并進(jìn)行解決呢？這需要我們了解常見的錯誤類型和分析方法。

1. 常見的錯誤類型

Crash日志主要來源于兩種問題：一是違反iOS策略被系統(tǒng)終止，二是自身的代碼bug。

2. iOS策略導(dǎo)致的Crash

首先我們了解一下低內(nèi)存閃退這一特殊的Crash類型。大多數(shù)Crash日志都包含執(zhí)行線程的棧調(diào)用信息，但低內(nèi)存閃退日志除外。使用Xcode 5和iOS 7的設(shè)備模擬低內(nèi)存閃退后，通過Xcode的Organizer查看產(chǎn)生的Crash日志。具體的日志內(nèi)容主要包括三部分：崩潰信息、內(nèi)存頁分配信息和進(jìn)程列表。當(dāng)iOS檢測到內(nèi)存過低時，會嘗試回收內(nèi)存并終止后臺應(yīng)用。我們的應(yīng)用應(yīng)合理響應(yīng)低內(nèi)存警告通知，釋放緩存數(shù)據(jù)并避免內(nèi)存泄露。除此之外，還有Watchdog超時和用戶強制退出等由iOS策略決定的終止應(yīng)用的情況。

對于其他類型的Crash，開發(fā)人員也需要了解常見的錯誤類型和原因，以便快速定位問題并進(jìn)行解決。例如，了解常見的內(nèi)存泄露、線程沖突等問題及其產(chǎn)生原因和解決方法，有助于我們更高效地分析和解決Crash問題。1. Watchdog超時與iOS應(yīng)用開發(fā)

1.1 引言

在Apple的iOS Developer Library網(wǎng)站上，QA1693文檔中詳細(xì)描述了Watchdog機制。這是一個關(guān)于應(yīng)用程序響應(yīng)時間的監(jiān)控機制，確保應(yīng)用程序不會因各種原因造成UI響應(yīng)遲緩。本文將深入探討這一機制，特別是其生效場景、表現(xiàn)以及相關(guān)的異常代碼。

1.2 Watchdog超時機制詳解

當(dāng)我們的應(yīng)用程序在某些特定UI（如啟動、掛起、恢復(fù)、結(jié)束）響應(yīng)不及時，Watchdog會介入并終止應(yīng)用程序運行，同時生成一份crash報告。報告中往往包含一個有趣的異常代碼：“0x8badf00d”，直譯為“ate bad food”。

這些特定的UI，如果用代碼來描述，通常對應(yīng)的是AppDelegate中的幾個關(guān)鍵方法。當(dāng)遇到Watchdog日志時，開發(fā)者應(yīng)檢查這些方法是否存在阻塞UI的情況。

一個常見的例子是在主線程進(jìn)行同步網(wǎng)絡(luò)請求。在公司的Wifi環(huán)境下可能一切正常，但當(dāng)應(yīng)用程序面對各種網(wǎng)絡(luò)環(huán)境和用戶時，Watchdog超時報告就不可避免地出現(xiàn)了。大數(shù)據(jù)量下的數(shù)據(jù)庫版本遷移（同樣在主線程上）也是可能觸發(fā)Watchdog超時的場景。

1.3 用戶強制退出場景解析

用戶強制退出應(yīng)用有多種情況。例如雙擊Home鍵關(guān)閉應(yīng)用，這種操作不會產(chǎn)生crash日志，因為應(yīng)用仍在后臺運行，iOS可能會隨時關(guān)閉后臺進(jìn)程。但另一種情況是用戶同時按住電源鍵和Home鍵使iPhone重啟，這種操作會產(chǎn)生日志，但它并不針對特定的應(yīng)用程序。

更為復(fù)雜的情況是用戶先按住電源鍵直到出現(xiàn)“滑動關(guān)機”界面，再按住Home鍵。此時當(dāng)前應(yīng)用程序會被終止并產(chǎn)生相應(yīng)的crash日志。這種情況通常發(fā)生在用戶遇到應(yīng)用程序卡教并影響iOS響應(yīng)時。由于這種操作相對復(fù)雜，因此產(chǎn)生的crash日志相對較少。

2. 常見錯誤標(biāo)識解析

2.1 Exception codes介紹

在各種crash日志中，會存在特定的異常代碼，如上文提到的“0x8badf00d”和“0xdeadfa11”。這些異常代碼是iOS系統(tǒng)為不同類型的錯誤定義的特定標(biāo)識。

2.2 錯誤代碼詳解

“0x8badf00d”錯誤碼代表Watchdog超時，直譯為“ate bad food”。

“0xdeadfa11”錯誤碼代表用戶強制退出，意為“dead fall”。

“0xbaaaaaad”錯誤碼通常與用戶操作有關(guān)，如按住Home鍵和音量鍵來獲取當(dāng)前內(nèi)存狀態(tài)，并不代表崩潰。

“0xbad22222”錯誤碼涉及VoIP應(yīng)用因過于頻繁被iOS終止。

“0xc00010ff”錯誤碼可能與設(shè)備過熱有關(guān)，意為“cool off”。

這些異常代碼幫助開發(fā)者快速識別問題的根源，從而更有效地進(jìn)行調(diào)試和優(yōu)化。在開發(fā)過程中，理解和識別這些錯誤代碼是非常重要的，它們能夠幫助開發(fā)者避免一些常見的陷阱，提高應(yīng)用的穩(wěn)定性和用戶體驗。關(guān)于錯誤碼與異常類型的解析

一、引言

在軟件開發(fā)過程中，錯誤碼和異常類型是我們經(jīng)常面對的問題。了解這些錯誤碼和異常類型可以幫助我們迅速定位并解決問題，從而提高軟件的穩(wěn)定性和性能。本文將針對常見的錯誤碼和異常類型進(jìn)行深入解析。

二、錯誤碼解析

0xdead10cc錯誤碼意味著程序在后臺運行時出現(xiàn)了資源沖突問題，導(dǎo)致系統(tǒng)資源（如通訊錄）被終止。這種問題通常被稱為“教鎖”。解決教鎖問題需要對程序進(jìn)行詳細(xì)的線程分析和資源調(diào)度。

三、異常類型概覽

查看crash分析報告郵件，我們最常遇到的異常類型是SEGV，即Segmentation Violation。這種異常表明程序在內(nèi)存操作上存在不當(dāng)行為，如訪問沒有權(quán)限的內(nèi)存地址。當(dāng)收到SIGSEGV信號時，可以從以下幾個方面考慮：

1. 訪問無效內(nèi)存地址，如Zombie對象。

2. 嘗試往只讀區(qū)域?qū)憯?shù)據(jù)。

3. 解引用空指針。

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

5. 棧溢出。

對于這些常見的SIGSEGV問題，我們需要對代碼進(jìn)行詳細(xì)的內(nèi)存分析，找出不當(dāng)?shù)膬?nèi)存操作并進(jìn)行修復(fù)。

四、其他常見信號

除了SIGSEGV外，還有其他常見的信號需要我們關(guān)注：

1. SIGABRT：收到Abort信號，可能由自身調(diào)用abort()或者收到外部發(fā)送的信號。

2. SIGBUS：總線錯誤。與SIGSEGV不同，SIGBUS訪問的是有效地址，但總線訪問異常，如地址對齊問題。

3. SIGILL：嘗試執(zhí)行非法指令，可能不被識別或沒有權(quán)限。

4. SIGFPE：Floating Point Error，與數(shù)學(xué)計算相關(guān)的錯誤，如除零操作。

5. SIGPIPE：管道另一端沒有進(jìn)程接手?jǐn)?shù)據(jù)。

了解這些信號的含義有助于我們更全面地了解程序的運行狀態(tài)，并及時處理潛在的問題。

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

除了上述信號導(dǎo)致的崩潰外，代碼bug也是導(dǎo)致崩潰的常見原因。如數(shù)組越界、插空、多線程安全性問題、訪問野指針、發(fā)送未實現(xiàn)的selector等。遇到這些bug時，需要根據(jù)錯誤提示信息進(jìn)行分析和定位，找出問題的根源并進(jìn)行修復(fù)。特別是在處理多線程問題時，需要特別注意線程安全問題。

了解錯誤碼和異常類型對于軟件開發(fā)至關(guān)重要。通過深入解析這些錯誤碼和異常類型，我們可以更快地定位問題并采取相應(yīng)的解決措施，提高軟件的穩(wěn)定性和性能。