Qunar 大前端团队一直致力于提升 App 页面的用户体验，基于前端技术手段，提高页面的流畅度和稳定性。 国内酒店作为 Qunar 的核心业务，需要时刻关注、提升预订主流程各个页面的性能指标和用户体验。近期我们使用非关键模块延迟加载、Bundle 预加载、接口提速等方案提升核心页面的流畅度，均得到了很好的效果，但是酒店详情页还未实现页面秒开的目标，需要继续提升。 酒店详情页的功能是展示酒店的基础信息、房型报价，是为用户提供预订酒店下单服务的重要入口，而 TTI 是衡量页面秒开的重要标准。 本文从现状、优化空间、具体方案设计及优化效果等方面来讲解我们对提升酒店详情页 TTI 的思考和动作，希望能给读者一些启发。
目前开源的监控系统越来越多，不同的系统针对的侧重点和特性也不同，像 Zabbix/Nagios 这种老牌的监控系统侧重于主机系统层监控和告警，比如 Zabbix 和 Nagios 都自带有一套完善的系统层面监控插件，而且还允许运维很方便的利用 Shell 脚本或任何其他脚本语言来扩展自己想要的插件，同时 Zabbix 还提供了比较便利的 Discovery 功能，创建一套模板后，便能自动发现和检测相应主机状态，省掉了繁琐的配置过程。而 Graphite/Prometheus 这样的则更兼顾业务应用层监控，它们提供了一套机制，应用可以在代码里记录自己在运行时的状态数据，然后通过 Exporter 或者 Push 的方式将状态数据暴露或推送到 Server 端，Server 存储在时序 DB 中用于之后的分析、查看和告警等。 很多企业在用开源软件的一个路径大概都是这样的，纯开源使用 → 少量的定制化开发或外层封装 → 深度的二次开发 → 自研。
随着业务发展和微服务架构的普及，企业内微服务拆分粒度越来越细，服务间调用关系错综复杂。对于一些复杂的，比如机票和酒店售卖业务场景，可能动辄涉及上百个应用，当某个系统发生异常时会导致多个服务受到影响。此时 APM 系统就派上了用场，监控（Metrics）、调用链（Tracing）、日志（Logging）帮助业务同学快速定位问题。普通的业务监控报警能起到快速发现问题的作用，但具体case的排查还需要研发人员通过异常栈信息来分析，比如数据库连接异常、空指针等等。 去哪儿网很早就有了监控系统 Watcher，能够起到快速提醒业务响应异常的作用，然后开发同学排查是接到报警的系统本身的问题还是下游依赖的系统的问题，如果是下游系统的问题，就要这样一层层地找下去，有时候定位问题时间会比较长。当某个系统出现问题时最根本的表现就是产生异常，如果能直接提示开发同学系统产生了新的异常，或者异常量上涨了，就能够大大缩短开发同学排查问题的时间，做到快速恢复故障。
在移动互联网时代，良好的用户体验至关重要，但如何量化其对业务的贡献一直是痛点和难点。毋庸置疑，体验是必须要持续推进的事情，产品、交互以及开发同学也投入很大精力去进行体验优化，但是相关的ROI(投入产出比)无法快速量化。在大多数情况下，只能通过录屏、纯技术指标(FPS/FCP/TTI等)来表现技术优化对用户体验的数据提升，但这表征不了整体用户体验的状态，更无法量化体验优化所产生的业务价值。 通过调研发现，关于用户体验的度量标准有各种各样的规范和模型，较为典型的有下表中的 Google Pulse、Google Heart、支付宝 PTECH、阿里云 UES，其中有满意度、任务效率、体验性能、易用性、收益、留存率、参与度、接受度、与一致性等关键项，其中前三项是较为普遍的共识。
近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”，统一交给下游网关团队，组成统一的应用层。这种由多个网关合并成大前台(酒店业务网关)的融合，带来的好处是核心系统边界清晰了，但是对酒店业务网关来说，也带来了不小的困扰，系统面临的压力主要来自两方面：首先，一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异，有些甚至是跨语言的代码迁移。其次，后续的复杂多变的应用层业务需求，之前分散在各个子网关中，现在在源源不断地汇总叠加到酒店业务网关。这就导致了一系列的问题
当前的软件系统越来越复杂，越来越多的开发者使用各种 IDE 、中间件来简化自己的软件开发过程。在这样的背景下，传统 IDE 产品的局限性日渐显现，开发者不得不学习更多的技术，引入更多的工具，花费更多的时间在开发环境的管理和维护上。 去哪儿网拥有大量的前后端工程和应用，每个工程所需要的代码编辑器，运行时，SDK，中间件，应用服务器，配置以及底层操作系统可能都不一样，而传统 IDE 工具在可开发性上做的很好，但都无法解决如上所述的开发环境依赖问题。 那么对于前后端工程师来说，如何在当前人力紧张、远程办公、项目不熟悉的情况下，随时随地快速着手开发和发布项目？对于团队来说如何保证团队开发环境的标准配置化的统一，让开发者按照规范工作？带着这些问题，参考云原生实践，基础架构团队实现了去哪儿网 WebIDE 云开发平台，面向多种业务场景提供了标准的容器化的开发环境，对开发者来说大大提升了效率和便捷性。 云开发平台在公司上线后，已接入前后端大多数业务场景，机酒火车票等业务线都在实际开发中使用，云开发工作区月活 400+ 。
去哪儿旅行APP作为我们用户流量的主要入口，其运行性能和用户体验的好坏，直接影响着用户操作的费力度，最终可能影响收益。 因此我们一直很关注 App 上的用户体验，提高 App 性能，使得用户在访问页面时，更流畅，更稳定，更便捷，从而提高业务转化率。 用户体验优化，首先要解决定义测量的问题。使用科学的衡量手段，评价 App 性能现状，以数据为导向，分析提升空间、并使用合理的技术方案进行改善。 起初，这种测量体系由多个团队各自维护，形式多样，也没有统一的评价标准，且不具有可持续性。因此，需要建立一个统一、客观、可靠、并且可持续的可视化测量平台来解决前面的问题，于是 QDD（Qunar Develop Digital）数字化平台应运而生，QDD 平台中的用户体验模型由：流畅度、稳定性、能耗等多个指标来组成，并针对去哪儿旅行 APP 内各个页面按照这些指标进行测量。（《用户体验数字化平台落地》可了解QDD的详情介绍） 基于 QDD 测量结果，我们发现与用户预订相关的核心页面在流畅度、稳定性、能耗等方面均有提升空间，于是开启了 App 的优化之路。 本文主要从核心的流畅度指标来展开，把我们的优化
