我們分析了100個移動應用程式,發現了App崩潰的6個常見原因!
人們討厭應用程式崩潰,尤其是是程式減速或卡死幾秒鐘這樣的現象。根據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說:“最好和最無錯誤的程式碼是不是你自己編寫的程式碼。”
你能否真正的建立一個無錯誤的應用程式,特別是在第一輪?可能不是。但是,您可以關注這些故障源,並盡最大努力建立強大的異常處理機制。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2642181/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 移動App測試崩潰常見的測試場景APP
- app 崩潰的原因APP
- 我們測試了上萬款應用程式,總結了APP測試流程和常見問題APP
- .NET程式崩潰了怎麼抓 Dump ? 我總結了三種方案
- MySQL 資料庫崩潰(crash)的常見原因和解決辦法MySql資料庫
- 100ms的SQL把伺服器搞崩潰了SQL伺服器
- “Linux”小程式釋出一個月後,我們發現了什麼Linux
- iOS 避免常見崩潰(二)iOS
- iOS 避免常見崩潰(一)iOS
- Qt程式繼承QApplication發生崩潰的原因QT繼承APP
- 我們分析了28萬條熱搜,發現了真正的頂流
- 應用崩潰了?Android vitals 幫您精確診斷應用崩潰Android
- 扒了修仙遊戲的前世今生後,我們發現了這個機會點所在遊戲
- 我用 Flutter Gemini 寫了一個水貼 APPFlutterAPP
- 我好像發現了一個Go的Bug?Go
- iOS應用崩潰了,如何透過崩潰手機連線電腦查詢日誌方法iOS應用崩潰
- 因為我的一個低階錯誤,生產資料庫崩潰了將近半個小時資料庫
- 我們分析了10萬條洩露密碼,發現了這樣的套路密碼
- 受夠了移動端的數字輸入,我用vue寫了個模擬鍵盤Vue
- 我們向GPT-3問了15908個問題,終於發現了它的真面目GPT
- 史上最坑爹的程式碼!個個讓人崩潰!
- Android進階;App的異常崩潰處理AndroidAPP
- 我們分析了2.6萬件胸罩,發現了中國女性內衣的祕密
- ios12升級, App應用崩潰閃退iOSAPP應用崩潰
- APP防崩潰APP
- 為了收集和整理程式設計的常用單詞,我寫了個背單詞應用程式設計
- Go程式崩潰現場應該如何保留?Go
- AutoEx應用崩潰自動匹配Stack Overflow的解答應用崩潰
- 好久不見,我造了一個輪子:微開發
- 為了學好Java,我嘗試了這 6 個方法Java
- 使用 Promise 時的5個常見錯誤,你佔了幾個!Promise
- NASA TESS發現了近100個四重星系統
- Linux中程式崩潰及重啟的原因詳解!Linux
- 我打造了一個線上簡歷生成應用
- 我們被一個 kong 的效能 bug 折騰了一個通宵
- 能否讓APP永不崩潰—小光與我的對決APP
- 我給 ”Go 語言“ 開發了 6 個線上工具Go
- 移動App崩潰測試用例設計分享,快速找出bug解決麻煩!APP