提到移動應用的用戶體驗，開發商們大都首先想到可視界面，比如地圖顯示用戶位置，或游戲界面制作等。這時，后臺服務器和應用運行平臺被忽略了。我曾和上千個開發者接觸過，竟然沒有人真正強調保證后臺基礎設備有效工作的重要性。通常只有在應用崩潰時，后臺才能被重視起來。一旦后臺出問題或是停止工作，即便前臺界面、美工等做的再出色，軟件也會慘遭用戶拋棄。
根據最近的調查顯示，軟件出問題后，有耐心重新嘗試兩次以上的用戶只占到16%。但與之相對應的，是2012年9月到2013年3月，出現各種問題(軟件崩潰，死機，提示故障)的軟件卻達到62%。
軟件出錯成本巨大。蘇格蘭皇家銀行(The Royal Bank of Scotland)就曾因為軟件故障影響200萬客戶而做出1.75億英鎊賠償。亞馬遜也曾因去年平安夜網站服務器崩潰導致Netflix電視無法使用而公開致歉。對特別依賴數據傳輸的行業，比如電子商務、電信等來說，軟件故障的成本可能是以每分鐘上萬美元計算的。
亡羊補牢，猶未晚也
移動軟件的出錯率比普通軟件高，這是因為他們不斷向處理器交換數據，并且用戶請求的地點和時間不斷變化，其中傳輸故障或意外故障在所難免，因此對后臺的要求要比傳統網絡或筆記本軟件要求更為嚴格。
那么，怎樣才能保證后臺不被流量打垮呢?下面是軟件開發商需要首先注意的幾個方面：
后臺彈性
后臺具有“彈性”，是指能隨著運行需求即時、自動改變軟件負荷。即不論是單機運行還是在公共的云平臺運行的情況下，都能夠隨時應對處理負荷對占用空間做出改變。光是這一點實現起來就不容易。
實現軟件的“彈性”，具體需要滿足下面的要求：
§ 自如應對符合增加;
§ 按照符合要求運行，堆棧、代碼和可視化界面不出故障;
§ 在無人干預的情況下，自動調用新任務所需的所有組件。
為實現上述要求，離不開應用平臺的支持。并且這一平臺可以自如應對線上線下的轉換，以保證軟件運行的連貫性。此外，能支持軟件在多種設備、多種模式下運行的應用系統，才能賦予軟件真正的彈性。
靈活性
移動應用發布后更新速度快，頻率高，為有效發布軟件更新，必須接受DevOps過程。DevOps是一組過程、方法與系統的統稱，用于促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。在出現故障時快速判斷與修復，保證高效修復軟件的同時不影響用戶使用軟件的質量。
有個管理程序發布和更新的方案，名叫“便捷傳遞”(agile delivery)。選擇能同時處理前臺和后臺的基礎設施非常重要，這種基礎設施應當結構簡單，能方便地在不同版本間切換。沒有這樣的基礎設施，應用開發和運營量雙發都難免陷入混亂。
分析&查找故障環節
現在許多移動軟件都建立在應用程序界面(API)為基礎的RESTful/JSON網絡服務構架上。API發出調用，數據反饋與后臺多重API調用相互回應的過程十分復雜，很難辨清是否有部件發生交互問題。即便出現了問題，也很難追蹤問題來源，查找導致出錯的某個API調用。又比如在同時接通多個服務器系統的過程中出現故障，到底是調用的哪一步出現了問題?是哪一個服務器回應延時導致了應用崩潰?這些都難以一一查明。
因此，找到及時辨明程序無法正常運行時發生問題環節的方法十分重要。通過分析，還能搶在用戶前發現問題。如今同一個軟件運行的終端越來越多，在這樣越來越復雜的關系網面前，分析(analytics)的作用就顯得愈加重要。
重視軟件后臺
移動軟件的用戶體驗不僅被前臺各種UI主導，后臺支持也不可或缺。對此，我的建議是首先熟悉agile delivery這種工作方式，并且應用到應用的所有部件的開發運營中，以統籌前臺與后臺的開發，同步提升應用體驗。