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

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

軟件出錯(cuò)成本巨大。蘇格蘭皇家銀行(The Royal Bank of Scotland)就曾因?yàn)檐浖收嫌绊?00萬(wàn)客戶(hù)而做出1.75億英鎊賠償。亞馬遜也曾因去年平安夜網(wǎng)站服務(wù)器崩潰導(dǎo)致Netflix電視無(wú)法使用而公開(kāi)致歉。對(duì)特別依賴(lài)數(shù)據(jù)傳輸?shù)男袠I(yè)，比如電子商務(wù)、電信等來(lái)說(shuō)，軟件故障的成本可能是以每分鐘上萬(wàn)美元計(jì)算的。

亡羊補(bǔ)牢，猶未晚也

移動(dòng)軟件的出錯(cuò)率比普通軟件高，這是因?yàn)樗麄儾粩嘞蛱幚砥鹘粨Q數(shù)據(jù)，并且用戶(hù)請(qǐng)求的地點(diǎn)和時(shí)間不斷變化，其中傳輸故障或意外故障在所難免，因此對(duì)后臺(tái)的要求要比傳統(tǒng)網(wǎng)絡(luò)或筆記本軟件要求更為嚴(yán)格。

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

后臺(tái)彈性

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

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

§ 自如應(yīng)對(duì)符合增加;

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

§ 在無(wú)人干預(yù)的情況下，自動(dòng)調(diào)用新任務(wù)所需的所有組件。

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

靈活性

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

有個(gè)管理程序發(fā)布和更新的方案，名叫“便捷傳遞”(agile delivery)。選擇能同時(shí)處理前臺(tái)和后臺(tái)的基礎(chǔ)設(shè)施非常重要，這種基礎(chǔ)設(shè)施應(yīng)當(dāng)結(jié)構(gòu)簡(jiǎn)單，能方便地在不同版本間切換。沒(méi)有這樣的基礎(chǔ)設(shè)施，應(yīng)用開(kāi)發(fā)和運(yùn)營(yíng)量雙發(fā)都難免陷入混亂。

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

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

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

重視軟件后臺(tái)

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