提到移动应用的用户体验，开发商们大都首先想到可视界面，比如地图显示用户位置，或游戏界面制作等。这时，后台服务器和应用运行平台被忽略了。我曾和上千个开发者接触过，竟然没有人真正强调保证后台基础设备有效工作的重要性。通常只有在应用崩溃时，后台才能被重视起来。一旦后台出问题或是停止工作，即便前台界面、美工等做的再出色，软件也会惨遭用户抛弃。
根据最近的调查显示，软件出问题后，有耐心重新尝试两次以上的用户只占到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这种工作方式，并且应用到应用的所有部件的开发运营中，以统筹前台与后台的开发，同步提升应用体验。