我們剛剛發佈了一個使用Crittercism框架的應用程序。過了一段時間，我們有大約125K的應用程序負載和95次崩潰 - 不到0.08％。iOS應用崩潰率 - 背景噪音水平？
其中有一次發生了19次碰撞，另有10次發生，其他41次發生3次以下。如果應用程序出現任何重大問題，我希望在特定區域發現更多失敗，所以我對我看到的數字水平感到滿意。
快速查看顯示它們中的許多是低級失敗，不是明顯造成的，而是程序員錯誤。
例子
free_list_checksum_botch但一些志願的失敗，我的問題是，在一個足夠複雜的OS（iOS版在這種情況下），具有足夠複雜的應用程序（我認爲這是），應作爲一名開發人員，我期望看到這種「背景噪音」水平？
我應該期望看到一個應用程序崩潰每1-2000加載，僅僅因爲操作系統不完美？其他人有過類似的經歷嗎？
（我不是在尋找到自己的錯誤解決方案..謝謝！）
雖然不是一個技術性的答案，在我的iPhone我個人希望有一個程序，我至少用了很多崩潰一年一次或兩次。我會說這個級別是完全可以接受的，因爲通常我發現他們在第一次啓動時就會崩潰很多，我相信這是一件值得期待的事情。
我是一名iOS開發人員，專業從事職業。當我的應用程序崩潰時，我會親自採取措施，因爲這不是我想要的用戶體驗。崩潰是一種糟糕的用戶體驗。每個用戶的一次崩潰太多了。崩潰是一個錯誤。
這就是說，我已經明確地看到似乎無法解決的崩潰日誌，因爲它們似乎指示了深入SDK中的問題。然而，我所學到的是，很可能有關於我自己的代碼的事情最終是最終的原因。
有任何數量的奇怪崩潰可能是由線程或塊之間的時間問題引起的，也可能是因爲我做錯了什麼。就在最近，我發現我正在做一些完全錯誤的事情，因爲我正在更新一個複雜的表格。這個問題的崩潰日誌幾乎沒有提供線索，除了我可能看到的代碼的一般區域。當我挖掘代碼並開始嘗試時，我意識到了自己的錯誤，最終導致了我認爲是主線程與非主線程活動的巧妙分離導致的計時問題。在這種情況下，我太聰明瞭，爲了自己的利益。 :-)
所以，總結一下：
最後，我提出這個問題需要考慮：
深思熟慮。 :-)
你是對的，當然，1次撞車真的太多了。但在這只是一個消費應用程序，所以用戶遇到的最壞情況是他們最終回到了跳板（許多人甚至沒有把它當作崩潰讀取），重新啓動應用程序會讓他們回到他們所在的位置......沒有傷害。我完全和你一起了解許多神祕錯誤的原因。我只想了解哪些級別（如果有）是由於固有的操作系統問題而導致的。 – 2012-03-27 15:32:53
你幾乎建議在這種情況下，一個操作系統，iOS是沒有錯誤的，不能成爲問題的原因，並看看這裏的數字......他說的是0.08％的用戶。這是一個非常小的數量，並且可能會有非常模糊的錯誤，這些錯誤從未被QA測試人員甚至自動化測試所採用 - 除非他們真的受到了壓力測試。我願意修復每一次我可能會發生的事故 - 我無法承受的是每天花費數天的時間試圖修復發生在50,000次事故中的晦澀事故。 – bandejapaisa 2012-03-27 15:35:38
我知道iOS並非沒有錯誤。我看到了很多莫名其妙的崩潰，我的代碼甚至沒有出現在有問題的堆棧跟蹤中。所以，不，iOS並不完美。但它很接近。 ;-)最終，你必須在解決這些崩潰問題時的努力與其他圍繞它們的數據（例如頻率）之間取得平衡，並且最終將花費時間來解決這些問題。 – 2012-03-27 15:39:34
我是一名專業的iPhone開發人員，我看到的是崩潰頻率並不是令用戶感到不安的原因，而是崩潰發生的渠道。
如果它們是間歇性的，通常可以，當一個用戶多次遇到特定的崩潰時，問題就會發生。這是無法接受的。盡力去除每一次崩潰總是一件好事，但在很多情況下，這是不現實的，你必須決定你的時間最好花在哪裏。如果您有機會修改UX流的一部分或修復間歇性崩潰，則需要確定哪一個對更多用戶有益。
要記住的重要一點是，如果您選擇不修復0.08％的時間發生的崩潰，那麼除非用戶多次遇到它，否則不會將正在經歷它的用戶註銷。
Crittercism對應用程序崩潰進行了分析。他們的報告基於Android和iOS崩潰。
他們的結論是，iOS上最受歡迎的應用程序崩潰了0.51％的應用程序啓動。所以@Ashley Mills，如果你得到0.08％......你做得很好。 （無論如何，我認爲我的數字是正確的）。
不知道這裏原來報告的，但我在這裏閱讀：
所以平均值越高越好 - 但我仍然不知道底層操作系統崩潰率是多少。雖然，老實說，我把這個項目的其他開發者歸咎於其大部分的失敗。 – 2012-05-31 08:58:38
「但是我的問題是，在一個足夠複雜的操作系統（這種情況下是iOS）和一個足夠複雜的應用程序中（我認爲它是這樣），作爲開發人員，我是否應該期望看到這種」背景噪聲「級別？ Crittercism分析涵蓋了數以萬計的應用程序，對你來說應該是一個足夠好的答案，用戶的任何其他單一響應只會基於少數應用程序，現在給我賞金，否則賞金將會在你的頭上答案是肯定的，期望有噪音 – bandejapaisa 2012-05-31 09:09:29
應用程序如何啓動與用戶會話相關？應用程序的後臺處理和後續恢復對應於相同的應用程序啓動還是單獨的應用程序啓動？ – Dalmazio 2014-10-16 16:47:28
其實在黑暗中的非技術性的答案再出手可能。當您可能花費更多時間和精力在您的工具中開發更多功能或完全使用其他工具時，它會帶給您（開發人員）什麼附加價值，以便繼續深入研究這個特定問題。
如果您的應用程序只是爲了好玩和學習，那麼我可以看到這個問題是一個有趣的冒險。從商業角度來看，您的時間值多少錢，並且正在計算出這個0.08％的問題會銷售足夠多（更多）的副本，以使您的努力值得。
類似的是，什麼要求是必不可少的，什麼要求是願望？ 只是思考的食物。我知道我曾經工作過的許多公司沒有看到強調低收益錯誤的價值。
我同意它可能太小而不必擔心，特別是因爲有問題的應用程序是爲了consumpt只有數據的離子，所以沒有任何事情可以真正在崩潰中「失去」。我的問題（恐怕沒有答案）是爲了我自己的好奇心。 – 2012-05-31 08:57:13
我懷疑（如果你看看我的評論），0.08％幾乎是不可避免的。當你看MS瀏覽器，甚至Safari時，它會經常崩潰。不幸的是，即使我們有完美的代碼，我們也可能會碰到（在iOS設備上），在硬件中發生虛假位翻轉。 iOS和硬件都支持ECC，如果你在代碼區有點翻轉，那麼你的代碼可能會獨特或者甚至不起作用，在你的數據中你可能冒險（如果它用在分支語句中）到一個意想不到的地方。當然，這些並不經常發生，但是當你把所有東西都加上去時....... – trumpetlicks 2012-05-31 13:17:47
啊......你已經準確地把握了我的問題。當您啓動一個應用程序數百萬次時，偶爾它可能會通過程序員錯誤以外的其他方式崩潰。現在，如果我們只能看到那個比率是什麼......在此期間，有50分:) – 2012-05-31 13:24:49
這是一個相當高的期望。作爲開發人員，我努力消除每一次崩潰。作爲一個用戶，偶爾的崩潰真的不會打擾我。如果它使應用程序無法使用，或者它會中斷我的使用（例如在遊戲過程中） - 那麼我會擔心。但是，如果我使用RSS閱讀器，它崩潰了......我只是重新啓動它。 – bandejapaisa 2012-03-27 15:38:27