人們討厭應用程序崩潰，尤其是是程序減速或卡死幾秒鐘這樣的現象。 根據Dimensional Research的一項調查，61%的用戶希望程序在4秒內啟動，而49%的用戶希望在2秒內響應輸入。 如果應用發生崩潰，凍結或報錯等現象，53%的用戶會將App卸載。
無論您的對象是消費者還是企業，崩潰問題會令他們徹底失望。與一些移動開發人員進行了交談，詢問了他們遇到的最常見的崩潰問題有哪些， 他們給出了常見的六種原因：
1.內存管理
我所問道的每個人都會談到內存管理，大多數APP都會開啟許多線程占用系統的內存。OpsClarity營銷副總裁Sachin Agarwal表示，程序員在編寫代碼時好像在app中只有他們編寫的應用一樣，同時，他建議在編寫程序時，要考慮使其稱為為"應用生態系統中的好公民"。
內存問題并非對所有開發人員是一樣的。Solstice Mobile業務開發副總裁Andrew Whiting說"在IOS中，您就可以利用Objective-C來處理大量內存問題，"。但是需要權衡利弊。"在Android上，你需要更深入的控制[內存]，你可以讓它完全按你想要的那樣做，但這會增加復雜性。"
"在JAVA中遇到[運行]內存不足，我們發現通常它與加載大圖像或處理位圖等相關，"New Relic的高級軟件工程經理Jonathan Karon表示。在移動SDK技術性能報告中并編制了常見的問題原因。"實際上有一些令人驚訝的數字看起來像Android上的鏈接器問題，無法找到類，或者有一個稱為非分類鏈接的異常。" 另一方面，iOS應用程序經常受到NSInternalInconsistency異常的影響，這是因為當開發人員在一個地方更改數組或數據集合時，而其他東西正在讀取那里的事物列表。
2.軟件生命周期
迭代的應用程序開發過程及其版本頻繁的發布，為最小化可行產品進入市場打開了大門，然后隨著時間的推移改進它，現在這種做法非常流行。但由于對操作系統和第三方API的依賴性，使傳統軟件生命周期變的更為復雜。
"如果你看看最新Android更新的系統，應用程序崩潰的會很多，"Agarwal說。"操作系統本身不穩定或操作系統更新了，應用程序沒有更新" 或者用戶不下載新的版本，這些"你都無法控制，它說明了一個核心的開發過程。"
移動和云計算的發展增加了第三方服務及其相關API的使用，從而節省了時間并有助于將應用程序更快地推向市場，但他們有自己的一系列問題。
"許多庫是都有共同的問題，"Whiting說。 "他們試圖解決每個人的問題，而不是為任何人提供最佳解決方案。" 例如，給定的API可能對特定應用程序具有性能限制。
API也可能使用棘手的技術，比如iOS方法調整。當原始代碼(如Apple的API)不可用時，開發人員在原始代碼(如Apple的API)基礎之上進行修改。"你可以稱之為iOS應用程序開發的'黑暗藝術'之一，"在線旅行社Fareportal的移動主管Raman Bhatia說。"[但]如果您的應用程序代碼以某種方式編寫，則可能導致崩潰。"
API也可能引起其他問題。"API延遲，錯誤率，數據帶寬， API的版本以及API請求的數量都可能由小問題印發大問題，"Agarwal說。然后是API本身，這就需要專門的工具來跟蹤所有內容。
API也可能導致其他問題，如內存錯誤。 "如果你創造了其他的對象前已經從內存中移除的一個對象，會認為通常這是沒有問題的，但需要注意的是你不知道后續創建的對象到底需不需要引用已經刪除的對象"聯合創始人和開發者Long Le說道"尤其是當你引入第三方框架時，就會出現問題。你永遠無法確定他們正在清理什么以及他們正在創造什么。"
3.測試不充分
測試的需求是很明顯的，但是需要獲得足夠的覆蓋率，特別是對于大量的Android版本和設備，可能具有挑戰性。雖然有模擬器，但在服務器上運行的軟件性能限制可能會與真機不同。
例如，應用程序的一個線程讀取數據庫，同時第二個線程嘗試修改這一個數據庫，"這是一個時間問題，" Couchbase移動首席架構師Wayne Carter說。"如果他們沒有在同一時刻發生碰撞，那么這個問題就不會出現，可以用日志描述來掩蓋。" 模擬器通常就不會和真機一樣。
在不同的設備上運行不同的系統是個可行的方案，但是這種方法比模擬器消費高。這就需要在預算和需求之間權衡
測試應結合行業標準和用戶期望的基準測試，以確保開發人員和用戶可接受的內容。測試也應該持續進行。監控性能并查找用戶反饋，然后盡快解決問題。
4.網絡管理
隨著應用程序越來越依賴網絡，無論是數據還是第三方服務，網絡管理已成為一個麻煩的源頭。
發生崩潰的最主要原因是當你正要獲取數據、提交了一些東西等待恢復而APP發生響應或者掛起。運營副總裁Pravin Vazirani說道，可能開發人員使Wi-Fi連接功能非常完善，但用戶在不好的網絡區域時就會發生問題
處理網絡問題的一個好方法是告知用戶連接中斷，并在可能的情況下提供執行可能感興趣的其他操作的機會。如果人們了解超出應用程序控制范圍的臨時狀況的原因，他們更有可能保持冷靜，不會對軟件感到惱火。
5.錯誤狀況和異常處理
由于移動開發的復雜性，一些錯誤是不可避免的，無論是意外的API更改，避免先前檢測的內存問題，還是網絡連接狀況，甚至只是在傳輸大型文件(如圖像或視頻)時降低數據傳輸的速度
在這種情況下，最好的方法是給與良好的錯誤和異常處理方式。比如用戶輸入錯誤的數據、本應提供數值的內容而提供文字到文本框內等，這樣，應用程序就不會被意外嘗試而報錯。
在任何這些情況下，正確編碼的應用程序都會注意到意外情況，并且在通知用戶錯誤的同時，可以優雅地終止進程或活動。如果你能保持溝通渠道暢通，就會有更好的機會留住用戶。
6.代碼太多了
最好的建議是保持應用程序簡單。找到特定用途的插件，使用插件并編寫必要的代碼。企業移動開發公司Lextech Global Services的高級系統工程師Felipe Laso-Marsetti說："最好和最無錯誤的代碼是不是你自己編寫的代碼。"
你能否真正的創建一個無錯誤的應用程序，特別是在第一輪?可能不是。但是，您可以關注這些故障源，并盡最大努力創建強大的異常處理機制。
