提到移動應用的用戶體驗，開發(fā)商們大都首先想到可視界面，比如地圖顯示用戶位置，或游戲界面制作等。這時，后臺服務器和應用運行平臺被忽略了。我曾和上千個開發(fā)者接觸過，竟然沒有人真正強調保證后臺基礎設備有效工作的重要性。通常只有在應用崩潰時，后臺才能被重視起來。一旦后臺出問題或是停止工作，即便前臺界面、美工等做的再出色，軟件也會慘遭用戶拋棄。

根據(jù)最近的調查顯示，軟件出問題后，有耐心重新嘗試兩次以上的用戶只占到16%。但與之相對應的，是2012年9月到2013年3月，出現(xiàn)各種問題(軟件崩潰，死機，提示故障)的軟件卻達到62%。

軟件出錯成本巨大。蘇格蘭皇家銀行(The Royal Bank of Scotland)就曾因為軟件故障影響200萬客戶而做出1.75億英鎊賠償。亞馬遜也曾因去年平安夜網(wǎng)站服務器崩潰導致Netflix電視無法使用而公開致歉。對特別依賴數(shù)據(jù)傳輸?shù)男袠I(yè)，比如電子商務、電信等來說，軟件故障的成本可能是以每分鐘上萬美元計算的。

亡羊補牢，猶未晚也

移動軟件的出錯率比普通軟件高，這是因為他們不斷向處理器交換數(shù)據(jù)，并且用戶請求的地點和時間不斷變化，其中傳輸故障或意外故障在所難免，因此對后臺的要求要比傳統(tǒng)網(wǎng)絡或筆記本軟件要求更為嚴格。

那么，怎樣才能保證后臺不被流量打垮呢?下面是軟件開發(fā)商需要首先注意的幾個方面：

后臺彈性

后臺具有“彈性”，是指能隨著運行需求即時、自動改變軟件負荷。即不論是單機運行還是在公共的云平臺運行的情況下，都能夠隨時應對處理負荷對占用空間做出改變。光是這一點實現(xiàn)起來就不容易。

實現(xiàn)軟件的“彈性”，具體需要滿足下面的要求：

§ 自如應對符合增加;

§ 按照符合要求運行，堆棧、代碼和可視化界面不出故障;

§ 在無人干預的情況下，自動調用新任務所需的所有組件。

為實現(xiàn)上述要求，離不開應用平臺的支持。并且這一平臺可以自如應對線上線下的轉換，以保證軟件運行的連貫性。此外，能支持軟件在多種設備、多種模式下運行的應用系統(tǒng)，才能賦予軟件真正的彈性。

靈活性

移動應用發(fā)布后更新速度快，頻率高，為有效發(fā)布軟件更新，必須接受DevOps過程。DevOps是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協(xié)作與整合。在出現(xiàn)故障時快速判斷與修復，保證高效修復軟件的同時不影響用戶使用軟件的質量。

有個管理程序發(fā)布和更新的方案，名叫“便捷傳遞”(agile delivery)。選擇能同時處理前臺和后臺的基礎設施非常重要，這種基礎設施應當結構簡單，能方便地在不同版本間切換。沒有這樣的基礎設施，應用開發(fā)和運營量雙發(fā)都難免陷入混亂。

分析&查找故障環(huán)節(jié)

現(xiàn)在許多移動軟件都建立在應用程序界面(API)為基礎的RESTful/JSON網(wǎng)絡服務構架上。API發(fā)出調用，數(shù)據(jù)反饋與后臺多重API調用相互回應的過程十分復雜，很難辨清是否有部件發(fā)生交互問題。即便出現(xiàn)了問題，也很難追蹤問題來源，查找導致出錯的某個API調用。又比如在同時接通多個服務器系統(tǒng)的過程中出現(xiàn)故障，到底是調用的哪一步出現(xiàn)了問題?是哪一個服務器回應延時導致了應用崩潰?這些都難以一一查明。

因此，找到及時辨明程序無法正常運行時發(fā)生問題環(huán)節(jié)的方法十分重要。通過分析，還能搶在用戶前發(fā)現(xiàn)問題。如今同一個軟件運行的終端越來越多，在這樣越來越復雜的關系網(wǎng)面前，分析(analytics)的作用就顯得愈加重要。

重視軟件后臺

移動軟件的用戶體驗不僅被前臺各種UI主導，后臺支持也不可或缺。對此，我的建議是首先熟悉agile delivery這種工作方式，并且應用到應用的所有部件的開發(fā)運營中，以統(tǒng)籌前臺與后臺的開發(fā)，同步提升應用體驗。