人們討厭應用程序崩潰，尤其是是程序減速或卡死幾秒鐘這樣的現(xiàn)象。 根據(jù)Dimensional Research的一項調查，61%的用戶希望程序在4秒內啟動，而49%的用戶希望在2秒內響應輸入。 如果應用發(fā)生崩潰，凍結或報錯等現(xiàn)象，53%的用戶會將APP卸載。

無論您的對象是消費者還是企業(yè)，崩潰問題會令他們徹底失望。與一些移動開發(fā)人員進行了交談，詢問了他們遇到的最常見的崩潰問題有哪些， 他們給出了常見的六種原因：

1.內存管理

我所問道的每個人都會談到內存管理，大多數(shù)APP都會開啟許多線程占用系統(tǒng)的內存。OpsClarity營銷副總裁Sachin Agarwal表示，程序員在編寫代碼時好像在app中只有他們編寫的應用一樣，同時，他建議在編寫程序時，要考慮使其稱為為"應用生態(tài)系統(tǒng)中的好公民"。

內存問題并非對所有開發(fā)人員是一樣的。Solstice Mobile業(yè)務開發(fā)副總裁Andrew Whiting說"在iOS中，您就可以利用Objective-C來處理大量內存問題，"。但是需要權衡利弊。"在Android上，你需要更深入的控制[內存]，你可以讓它完全按你想要的那樣做，但這會增加復雜性。"

"在Java中遇到[運行]內存不足，我們發(fā)現(xiàn)通常它與加載大圖像或處理位圖等相關，"New Relic的高級軟件工程經(jīng)理Jonathan Karon表示。在移動SDK技術性能報告中并編制了常見的問題原因。"實際上有一些令人驚訝的數(shù)字看起來像Android上的鏈接器問題，無法找到類，或者有一個稱為非分類鏈接的異常。" 另一方面，iOS應用程序經(jīng)常受到NSInternalInconsistency異常的影響，這是因為當開發(fā)人員在一個地方更改數(shù)組或數(shù)據(jù)集合時，而其他東西正在讀取那里的事物列表。

2.軟件生命周期

迭代的應用程序開發(fā)過程及其版本頻繁的發(fā)布，為最小化可行產(chǎn)品進入市場打開了大門，然后隨著時間的推移改進它，現(xiàn)在這種做法非常流行。但由于對操作系統(tǒng)和第三方API的依賴性，使傳統(tǒng)軟件生命周期變的更為復雜。

"如果你看看***Android更新的系統(tǒng)，應用程序崩潰的會很多，"Agarwal說。"操作系統(tǒng)本身不穩(wěn)定或操作系統(tǒng)更新了，應用程序沒有更新" 或者用戶不下載新的版本，這些"你都無法控制，它說明了一個核心的開發(fā)過程。"

移動和云計算的發(fā)展增加了第三方服務及其相關API的使用，從而節(jié)省了時間并有助于將應用程序更快地推向市場，但他們有自己的一系列問題。

"許多庫是都有共同的問題，"Whiting說。 "他們試圖解決每個人的問題，而不是為任何人提供***解決方案。" 例如，給定的API可能對特定應用程序具有性能限制。

API也可能使用棘手的技術，比如iOS方法調整。當原始代碼(如Apple的API)不可用時，開發(fā)人員在原始代碼(如Apple的API)基礎之上進行修改。"你可以稱之為iOS應用程序開發(fā)的'黑暗藝術'之一，"在線旅行社Fareportal的移動主管Raman Bhatia說。"[但]如果您的應用程序代碼以某種方式編寫，則可能導致崩潰。"

API也可能引起其他問題。"API延遲，錯誤率，數(shù)據(jù)帶寬， API的版本以及API請求的數(shù)量都可能由小問題印發(fā)大問題，"Agarwal說。然后是API本身，這就需要專門的工具來跟蹤所有內容。

API也可能導致其他問題，如內存錯誤。 "如果你創(chuàng)造了其他的對象前已經(jīng)從內存中移除的一個對象，會認為通常這是沒有問題的，但需要注意的是你不知道后續(xù)創(chuàng)建的對象到底需不需要引用已經(jīng)刪除的對象"聯(lián)合創(chuàng)始人和開發(fā)者Long Le說道"尤其是當你引入第三方框架時，就會出現(xiàn)問題。你永遠無法確定他們正在清理什么以及他們正在創(chuàng)造什么。"

3.測試不充分

測試的需求是很明顯的，但是需要獲得足夠的覆蓋率，特別是對于大量的Android版本和設備，可能具有挑戰(zhàn)性。雖然有模擬器，但在服務器上運行的軟件性能限制可能會與真機不同。

例如，應用程序的一個線程讀取數(shù)據(jù)庫，同時第二個線程嘗試修改這一個數(shù)據(jù)庫，"這是一個時間問題，" Couchbase移動***架構師Wayne Carter說。"如果他們沒有在同一時刻發(fā)生碰撞，那么這個問題就不會出現(xiàn)，可以用日志描述來掩蓋。" 模擬器通常就不會和真機一樣。

在不同的設備上運行不同的系統(tǒng)是個可行的方案，但是這種方法比模擬器消費高。這就需要在預算和需求之間權衡

測試應結合行業(yè)標準和用戶期望的基準測試，以確保開發(fā)人員和用戶可接受的內容。測試也應該持續(xù)進行。監(jiān)控性能并查找用戶反饋，然后盡快解決問題。

4.網(wǎng)絡管理

隨著應用程序越來越依賴網(wǎng)絡，無論是數(shù)據(jù)還是第三方服務，網(wǎng)絡管理已成為一個麻煩的源頭。

發(fā)生崩潰的最主要原因是當你正要獲取數(shù)據(jù)、提交了一些東西等待恢復而APP發(fā)生響應或者掛起。運營副總裁Pravin Vazirani說道，可能開發(fā)人員使Wi-Fi連接功能非常完善，但用戶在不好的網(wǎng)絡區(qū)域時就會發(fā)生問題

處理網(wǎng)絡問題的一個好方法是告知用戶連接中斷，并在可能的情況下提供執(zhí)行可能感興趣的其他操作的機會。如果人們了解超出應用程序控制范圍的臨時狀況的原因，他們更有可能保持冷靜，不會對軟件感到惱火。

5.錯誤狀況和異常處理

由于移動開發(fā)的復雜性，一些錯誤是不可避免的，無論是意外的API更改，避免先前檢測的內存問題，還是網(wǎng)絡連接狀況，甚至只是在傳輸大型文件(如圖像或視頻)時降低數(shù)據(jù)傳輸?shù)乃俣?/p>

在這種情況下，***的方法是給與良好的錯誤和異常處理方式。比如用戶輸入錯誤的數(shù)據(jù)、本應提供數(shù)值的內容而提供文字到文本框內等，這樣，應用程序就不會被意外嘗試而報錯。

在任何這些情況下，正確編碼的應用程序都會注意到意外情況，并且在通知用戶錯誤的同時，可以優(yōu)雅地終止進程或活動。如果你能保持溝通渠道暢通，就會有更好的機會留住用戶。

6.代碼太多了

***的建議是保持應用程序簡單。找到特定用途的插件，使用插件并編寫必要的代碼。企業(yè)移動開發(fā)公司Lextech Global Services的高級系統(tǒng)工程師Felipe Laso-Marsetti說："***和最無錯誤的代碼是不是你自己編寫的代碼。"

你能否真正的創(chuàng)建一個無錯誤的應用程序，特別是在***輪?可能不是。但是，您可以關注這些故障源，并盡***努力創(chuàng)建強大的異常處理機制。