阿里高级技术专家：成长路上如何破局？(9)

航旅北京前端团队 outing 合影（2015）
随着 PC 业务工作量逐步减轻，15年我的主要精力逐渐转移到无线 H5 上来，负责了一些体量偏小的新业务，比如签证、用车，练手性质偏多。坦白说那个时期的 H5 开发是比较枯燥的，一方面业务复杂度不高，逻辑尽可能往服务端下沉，端侧少了很多抽象封装、继承拓展、设计模式的需要，带来的代码爽感大大降低；另一方面屏幕变小了，精细化要求也变高了，视觉交互上的细节问题被极速放大；加之真机调试相较 Chrome devtools 的原始感，往往一个 px 偏移或动画卡顿的调整就能耗进去几个小时。
到了一个新的环境，最先要做的还是破局，从大环境上看，那段时期业界都在攻坚性能体验的课题，围绕 Hybrid 架构各类技术方案如雨后春笋。而旅行行业的特殊性在于，用户有大量在旅行途中使用 App 的场景，国内景区要么人满为患，通信基站负荷过重导致网络降级；要么各类自然风景区、高速路/铁路沿线直接没有信号覆盖，没办法查询电子票根，更不能享受各类行中服务；同时动画滥用、Webkit BUG 也导致 CPU 彪高、耗电量增加，在类似神农架这种缺少充电手段的场景非常致命。因此相比其他行业，性能体验对于旅行业务的影响面更大也更深远。
明确性能作为突破方向后，开始找突破口。当时架构组性能优化手段集中在容器架构层面，如iDNS/SPDY 改造解决网络传输问题、离线化体系解决资源加载问题、脚手架模板优化解决 JS 阻塞渲染问题，鲜有目光聚焦在前端业务优化层面。这一方面导致跑分与体感指标存在差异，另一方面业务上基础库未预加载、combo 失效、图片未压缩、错误的构建配置等问题都可能将底层优化积累的优势损失殆尽；加之性能数据上报链路和配套度量体系不够完善，指标对业务开发同学日常工作的指导意义不足。
抓住问题之后，我从手上小业务开始逐步落地全链路的性能体验优化方案：
重新定义性能质量标准，从最初的页面秒开率，转为 三端（飞猪、手淘、支付宝）、四网（2G、3G、4G、wifi）、五维度的度量模型，在白屏、DOM Ready、Onload 等通用评估标准之外定义了「页面可见时间」与「可交互时间」等体感指标。
重构数据采集上报链路，维护基础库 Base 及 tracker 模组，制定业务埋点规范并推进埋点上报率、准确性治理。