转载《美团点评金融平台Web前端技术体系》

复制代码

做者：禹霖

原文地址： tech.meituan.com/2018/03/16/…

背景

随着美团点评金融业务的高速发展，前端研发数量从 2015 年的 1 我的，扩张到了如今横跨北上两地 8 个事业部的将近 150 人。业务新，团队新，前端领域框架技术又层出不穷，各个业务的研发团队在技术选择上没有明确的指导意见，导致业务与业务之间的技术差别愈来愈大，在技术工具研发上没法共建，在资源调度上成本也很高。

2017年下半年，金融平台发起了技术栈统一行动，行动分为后端、iOS、Android及前端等四个方向，在前端方向我做为组织者和参与者与金融平台 8 个事业部的前端技术表明进行讨论。 经过对各方意见进行概括整理，结合各团队的状况，金融平台对于技术栈的选型达成了共识。本文将介绍美团点评金融平台前端的技术选型以及背后的思考。先从一些基本原则讲起。

构建技术体系的基本原则

Principles

业务出发

1. 选型要针对业务形态特色，注重业务场景匹配度
2. 具备必定业务前瞻性（中期或中短时间以免过分设计，短时间、中期、长期与迭代速度强相关）

金融业务的移动端项目占比超过 70%，尤为是 Hybrid 项目，团队在整个移动端生态的设计上投入了大量的精力，例如 Vue 的选择、EH 的设计、组件库 Vix 的设计等。

同时因为业务的金融属性，对于可用性的要求很是高。在可用性保障上咱们还会有一些侧重，例如 TypeScript 的使用，自动化流程测试框架 Freekite 的使用等。

团队出发

1. 考虑团队规模，成员技术特色和偏好
2. 考虑现有项目和技术迁移成本

金融大多数团队都处于初创时期，所以团队历史包袱相对较少，接受新鲜事物的能力强，但快速搭建团队中也会对技术栈有上手成本的要求。在整个技术体系的搭建当中，咱们会优先考虑那些新的、上手成本低的技术。

以简驭繁

咱们主张使用简单的技术手段解决复杂的问题，而不是用复杂的技术手段解决简单的问题，例如 Hybrid 体验问题的解决，常规的有 RN、Weex 等方案，在业界有丰富的实践，但咱们也会设计实现更简单的解决方案 EH，让问题的解决变得更聚焦于问题的本质。在首屏渲染速度优化方案上的选择也是同样，业界有很好的 SSR 技术，但咱们也会实践研发构建时预渲染技术，让 TTFB（首字节时间）更快，让系统流量负载更高，同时减小关键环节，让整个系统可用性更强。

标准化

标准化指的就是尽量让上下游衔接造成标准，并在标准下构建效率和质量工具。

例如在组件库 Vix 的研发上，咱们与 UED 造成一致的、强同步的标准，从而大大减小界面搭建的时间消耗。后面会详细介绍。

自动化

用技术去链接技术，用技术去简化步骤，解决某个工具到使用者的“最后一千米”问题。

例如咱们使用的自动化流程测试工具 Freekite，不用一行代码便可以完成复杂的分支逻辑自动化测试与持续集成。咱们使用的联调平台 Portm 能够将接口设计和前端 Mock 、后端单测、接口文档有机的结合起来，将先后端的研发进度解耦，从而大大提高研发效率。

现有复用

顾名思义就是选型上尽可能使用公司已有的系统和工具，从而更好的与团队、业务结合。

例如全平台监控工具 CAT，业务埋点工具灵犀等等。下面来看看咱们技术体系的细节。

金融平台 Web 前端技术体系

咱们将从开发阶段开始介绍，从视图层、语言层、协做层，再到质量保障工具、体验优化工具、安全技术等。接下来过渡到编译部署阶段，讲一讲编译部署和上线工具。而后是线上监控和埋点工具。最后介绍一些各个团队正在探索和实践当中的技术。

视图&组件框架

在移动端使用 Vue 生态，在桌面版上咱们使用 React 生态 或者 Vue 生态。

Vue 的使用主要考虑如下几点：

• 体积小，复杂度低
  • 业务上移动端项目占比 70% 以上，Vue 的体积小，网络性能角度相比 React 更适合移动端
  • 移动端通常巨型项目不多，从代码结构上来说，使用 Vue 实现更符合咱们的场景复杂度，React 更适合大型相对更复杂的 SPA
• 上手成本和迁移成本低
  • Vue 的学习和上手成本相对更低，团队成员对于 Vue 的承认度和热情也比较高
• 组件内双向绑定、数据依赖收集
  • 组件内支持双向绑定，更方便的去进行组件内的数据响应与交互
  • 独有的数据依赖收集模式使其默认的数据响应和渲染效率都要比 React 高一些

React 的使用主要考虑如下缘由：

• 有一部分现有后台项目采用 React 技术栈，迭代和维护较少，老的项目若是没有足够的迁移价值则不额外投入资源
• 保留很小的一部分 React 技术生态也能够必定程度上保持一些技术多样性

组件库

组件库是前端领域一个重要的技术单元，为效率、质量、体验服务。

效率是为了可以抽象业务研发中业务组件的共同点去避免重复劳动；质量是若是一个组件通过了测试和质量迭代，那么正确的使用不该该出现质量问题；体验方面组件库能够去统一交互的体验，让组件的表现更一致。

上述三点中，组件库贡献最大的是效率。

谈到组件库如何对效率作贡献，首先想到的是什么样的组件库才可以尽量的提高咱们的研发效率，我认为这里咱们须要注意的一点是“控制变量”，由于变化产生了额外的工做量和时间成本，若是这个产品和上个产品彻底同样，咱们直接复制一份就行了，不必开发。在咱们的前端业务研发当中，变量是什么？是交互和视觉设计，每一个产品之间有不一样，也有相同。咱们控制变量就应该去控制设计。所以咱们与金融 UED（设计部门） 沟通制定了一个视觉组件标准，共同建立了视觉组件库：Vix。

Vix 是一个移动端组件库，其特色是彻底遵照与金融 UED 制定的视觉组件标准并保持同步，在 UED 侧有完善的新组件设计提审及审核流程，在业务前端研发侧有强同步的约束。

Vix 的结构分为基础组件、复杂组件和业务组件三层，基础组件例如输入框、按钮等；复杂组件包括组合搜索、日期选择等；业务组件例如支付密码输入框、帐单、帐单详情等。

再上升一层则是一些包含后端服务的先后端组件，咱们称为“微服务”，是一种更高层次的业务服务抽象，在更高的维度优化效率和服务体验一致性，例如支付密码验证服务，找回支付密码服务等。Vix 包含的是前三层，其结构以下图：

在以往的实践过程中，C端业务使用开源组件库会和设计有很大差别，须要作大量的改造工做才能使用，然而可能还要为各类各样改造过程当中所产生的问题负责，同时开源组件库的业务不相关性限制了业务产品的设计或实现。在 Vix 中，因为标准统一，咱们的研发效率大大提高，同时质量也更加可控。

大多数移动端产品研发过程当中至少 40% 以上的精力是在作界面的绘制。有了 Vix 后咱们达到了：

• 效率大大提高：在界面绘制上相比没有组件库至少可以减小 90% 的工做量
• 直接组装无需改动：一个新产品没有新组件出现的状况下，咱们甚至可使用交互稿直接开发而不须要等待视觉稿，由于视觉稿即便画出来也是使用视觉组件库去实现的样子，极大的减小了项目研发的时间成本
• 标准更新仅需升级版本：当视觉标准更新的时候例如列表页两边的边距减少了，各个业务线的产品只须要从新发布一下就可以展现成最新的标准，极大的减小了标准更新时所需的时间成本

PC 端面向用户和商户的大多都是较为独立的产品，标准化的意义并不大，前端在 PC 端的研发精力主要投入在内部系统上，在内部系统前端研发上有四个特色：

• 无产品，要求高：几乎没有产品经理跟进，以完成功能需求为主，但功能流程必定要完善，最好能支持手机端使用
• 无设计：几乎没有设计跟进，面对内部用户设计收益不高
• 无测试：几乎没有测试跟进，收益不高，功能验证经过便可
• 要快：大多数是配合用户端产品的管理系统迭代，也多是新系统的搭建，对研发速度都有要求，每每这方面的估时较短

所以在内部系统的研发上有四点要求：

• 组件设计合理，组件数量大而全，最好支持移动端使用
• 组件库自己要有不错的设计，用户量虽少，但活跃度超高，界面体验须要保障
• 组件库自己的质量要高，要从工具层面保障质量减小出错
• 组件库要可以快速拼装出功能

PC 端组件库因为设计没有要求，不存在来自设计的“变量”，因此选择不少。

React Cells 也是美团点评内部的一个组件库，金融在使用 React 生态的后台系统研发中使用 React Cells 做为组件库，其具备以下几个特色能够知足咱们的需求：

• 无状态化的组件设计
• 主题可定制
• 跨平台（PC、Mobile）
• 搭积木式的使用方式
• 内部组件库专人快速支持

在 Vue 生态实现的 PC 端内部系统中，咱们使用 Element-UI 做为组件库，组件数量不少，质量也很高，在 Vue 生态中是排名靠前的开源组件库，这里很少赘述。

语言

针对ES6，本文再也不进行过多阐述。对于 TypeScript 的使用是从2015年末开始，当时咱们的移动端 Web 版收银台要作质量和可用性保障（详情参考以前的文章《前端可用性保障实践》），在 JS 层面咱们遇到的最多的运行时问题就是 something is undefined，也就是空指针问题。另外就是因为银行卡支付过程的业务逻辑很是复杂，代码层面可控性差，扩展性也不好。这时候想到的就是使用强类型语言来管理咱们的项目，强类型语言能够帮助咱们作两个事情：

• 在开发期间或编译期间进行强类型检查
• 使用类型系统让代码可控性、扩展性更强，协做更方便

当时咱们面临两个选择，一个是微软的 TypeScript ，一个是 Facebook 的 Flow。选择 TypeScript 是由于如下几点：

• RoadMap 清晰，方向以贴合 ECMAScript 为核心，在其之上构建类型系统，传言 ES8 也会增长类型系统
• TypeScript 是 JavaScript 的超集，其做用只在开发阶段发挥，其生成的代码不包含任何类型代码，但由类型系统保障
• IDE 支持极好，除了自家的 VSCode 集成度超高，用户增加飞速，TypeScript 还支持市面上几乎全部主流 IDE
• 社区庞大，周边工具丰富
• 当时已经有几个大型的开源项目在使用，例如 Angular 和 Express
• 研发团队活力和积极性都很高，不少开源生态均快速推动集成

而不选择 Flow 的缘由主要包括如下几点：

• 当时 Flow 仍是以注释为主，单文件非强制型编码，致使其类型检查系统没法发挥最大效用，也没法全面保障质量。后来 Flow 也改为了 TypeScript 相似的方式，但我的认为为时已晚
• 集成度不高，IDE 支持落后
• 当时社区很小，除了 Facebook 自家的项目在使用，大型的开源项目用户不多

TypeScript 包括 类型守护、联合类型、类型推导、严格非空检查等功能。

举个例子如图所示：

参数 s 是可能为空的，在 TypeScript 里，若是不作非空检查就会报错，作了非空检查经过 TypeScript 的类型推导就可以经过。

经过使用 TypeScript 咱们能够找出前端项目中 99% 的引用问题，因为咱们的整个前端框架所有支持 TypeScript，有效的避免了空指针这种运行时低级错误的存在。

在 TypeScript 的使用上金融支付也是公司第一个在线上使用 TypeScript 的业务线，2015年末咱们还制定了 TypeScript 代码规范。

协做解耦

在平常开发当中，先后端联调常常遇到一些环境问题或者接口设计的问题，致使先后端当中一方等待另一方，这种状况在效率上影响很是大。协做解耦指的就是让先后端的研发工做不互相依赖，从而优化研发效率。

上图表示的就是协做耦合所形成的效率问题，字母 A 表明项目 A，在先后端研发过程当中，前端可能由于后端问题而没法继续开发，反之亦然。

2015年的时候我还在技术工程部，那个时候组内同窗一块儿想到了一个方法去解决这个问题。最初的想法就是“咱们能不能经过接口设计一方面生成提供给前端研发使用的假数据，另外一方面生成后端的单测。”

这个想法最终落地就是 **Vane **这个工具，如今叫 Portm。

它能够在一个项目的接口设计时切入，先后端使用这个平台进行接口设计，同时写入各类逻辑 Case 的输入输出，它能够直接生成三个东西：

• 标准化的接口文档
• 提供给前端使用的标准化假数据
• 提供给后端使用的单测

在项目研发过程当中，前端面向假数据开发没必要担忧遇到后端环境问题；后端面向单测开发没必要担忧本身跑通了前端跑不通。当双方都能跑通的时候进行集成联调，这个时候先后端集成度会很是高，先完成的一方能够直接进入下一个项目，从部门角度来说，大大优化了产品迭代研发的效率。

下图表示的是优化后的效果，能够看到先后端已经无需互相等待了。

自动化测试

针对自动化测试，美团点评开发了一款工具叫 Freekite ，它的做用是从用户使用角度验证界面业务流程的正确性，解决了为实现模拟用户点击而带来的诸多问题及 Case 管理的复杂度问题。

Web自动化流程测试除了能够验证 Case 的正确性之外，最重要的功能就是要有一个异常强大的 Case 管理模块。业界目前并无理想的工具可以支撑咱们的场景。“Freekite” 在 Case 验证功能的基础上，有一个强大的可视化 Case 管理模块，支持复杂的 Case 细分。除了界面操做的细分外，能够全量 Mock 或部分 Mock 后端的数据响应，根据响应拆分出不一样的 Case 分支。除此以外，还包含智能自动化断言功能，断言基本不须要人工参与。

Case 录完之后遇到界面改版的状况很差处理，Freekite 还支持单独节点的从新录制，也就完美的解决了 Case 的维护问题，大幅度减小工做量优化效率。紧接着咱们会在项目中增长 Freekite 的持续集成，在项目的每个阶段进行流程上的自动化回归验证，业务逻辑覆盖率的问题就基本解决了。下图为 Freekite 可视化 Case 管理的一个应用示例。

Hybird 体验技术

不一样的角度对用户体验有不一样的分拆方法，从前端角度讲，我把用户体验分为如下两个方向：

前端主要在“交互体验” 中的功能体验和界面体验上寻求优化。

Titans 是美团点评解决 Hybrid 功能体验的一个集团范围的解决方案，它为 Hybrid 模式的产品封装 Native 的能力供 Web 调用，其能力包括几个大的方向：

• 基础API：版本判断、配置与环境判断、获取权限、订阅与广播等
• 用户信息：获取用户设备信息、风控信息、网络信息、登陆及推出登陆等
• 地理位置：获取经纬度、城市信息、定位城市信息等
• 基础业务功能：打开一个新的 WebView、关闭当前 WebView 打开一个新的 WebView 、关闭 WebView 等
• 分享：弹出分享、分享设置、分享渠道等
• 本地存储：存储信息到 Native ，读取信息等
• 多媒体：选择图片、预览、上传图片、扫描二维码等
• 系统提示：发送短信、获取联系人、震动、锁屏等

业务能够在 Titans 的基础上构建丰富的 Hybrid 应用，既能享受无需发版便可更新迭代的优点，又可使用 Native 的大多数功能。

在解决了功能体验后，接下来咱们再说界面体验的问题。

谈到界面体验咱们不得不从新讲起 Hybrid，我的认为在解决功能体验的前提下 Hybrid 存在如下主要的优点和劣势：

• 优点
  • 迭代速度快，随时发版
  • 资源节省，减小重复开发（Android & iOS）
  • 跨平台，可浏览器运行
• 劣势
  • 加载速度慢、白屏
  • 界面体验差，交互不一致

针对 Hybrid 的劣势，行业内现有的解决方案有不少，典型的有 Facebook 的 React Native 和阿里的 Weex，除去其它因素，只讲技术自己，它们有几个共同点：

• JS/CSS 编码或类 JS/CSS 编码
• Virtual DOM
• JavaScriptCore / jsc.so 解析
• Native 呈现

因而可知行业内解决此类问题的关键套路就是使用 Native 来呈现。

那么回到问题自己，为何 Native 不存在此类问题而网页存在，通过研究咱们发现有如下两个主要区别：

1. Apple、Google 这类大厂在界面体验上有深厚的研究，他们把界面体验所须要注意的那些点作成了开发模式的约束，放到了开发过程当中，使用 IDE 和框架等工具去限制和引导，从而帮助开发者把界面体验作好。Web 是一种开放标准，它更为灵活，对界面体验没有严苛的限制，由开发者自由发挥
2. 资源存放在本地和在远端的加载速度区别

关于第一个区别你们可能存在一些困惑，这里咱们举个例子，下图就是 Native 为何没有白屏的根本缘由：

如图所示，Native 从视图 A 跳转到视图 B，当用户点击 A 中的按钮触发跳转到 B 的动做时，B 的代码会开始执行，只有当 B 已经加载完成后，系统才会让 A 跳转到 B，在 iOS 中的生命周期是 viewWillAppear，在此以前 viewDidLoad 已经执行完毕，Android 也是类似的生命周期。再加上 Native APP 的资源是本地化的，Native APP 有更多的运算资源和系统级别优化，它能够把这个加载过程时间缩短到接近瞬间。而把界面绘制和加载代码写到 viewWillAppear 以前是这些厂商指导咱们去这样作的，而且提供了相应的系统级别支持。这时候咱们思考一个问题，若是 Native 代码将界面绘制的代码写到 viewDidAppear 中会发生什么？答案是也会出现白屏。

因而可知，并非纯 Native 必定体验好，若是你不按照厂商的指导要求作，体验同样很差。

当咱们想清楚缘由后咱们就开始作了一个界面体验技术，名字叫 Enhanced Hybrid (加强混合)，简称 EH。

EH 的核心是“解决 Hybrid 与 Native 体验差别的技术瓶颈”。它包括两个部分，第一个部分是一个 Native SDK，有目前咱们积累的全部解决体验差别技术瓶颈的功能，第二个部分是界面体验指南，也就是如何让咱们的 Web 页面变的界面体验更好。

举个例子，在刚刚的白屏例子中，咱们能够看到一个重要的信息，A 跳转到 B 的时候，当 A 中点击执行跳转动做时第二个界面就已经开始执行了，在 B 执行完渲染部分以前系统不会执行 A 到 B 的实际界面跳转动做。这个操做在 Web 中是不可行的，咱们没法在 Web 中让 B 在跳转前执行完渲染部分的代码。

那么无白屏的前提条件是什么？

无白屏的前提条件是渲染完成，或者至少渲染到一个用户跳转过来有东西，不会给人突兀的感受。

咱们思考这个里面的技术瓶颈是什么？

1. 没法在跳转到 B 以前执行 B 的加载和渲染
2. 没法获取 B 的渲染完成进度

当咱们想清楚这个技术瓶颈之后动手解决了这两个问题。首先，B 的渲染完成并非一个绝对的状态，而是由研发本身知道本身控制的，研发能够在到达这个状态的时候把状态主动通知出去。第二咱们费了一些周折，在两个平台中能够经过一些技术去控制 A 等待一个通知，再让 B 展现出来，最终结合起来的方案以下图所示：

单独使用此技术会遇到在 A 等待时间长的问题，再辅以“离线化技术”即可以完美解决。（离线化技术会在后面详细讲）

EH 目前全部的功能包含：

• Open：打开无白屏 WebView
• TransPage：SPA 使用 Native 导航，让 SPA 的视图切换在不作任何特殊开发的状况下，具备和 Native 同样的交互表现，例如 iOS 中的左滑后退
• TabsEntry：让 App 底部 Tab 能够动态配置，Hybrid Tab 表现效果能够和 Native 同样
• Modal WebView：让 Hybrid 应用能够在当前页打开一个弹出式的 WebView ，从而在短暂操做后能够回到原来的流程当中
• Config：让 Hybrid 界面高度可定制化，例如分开的上下 Bounce 设置，ScrollView 的设置，导航的设置等
• ActionSheet：弹出一个 Native 的 ActionSheet 从而使其蒙层能够盖住导航

目前还有更多黑科技功能在逐渐增长中，上述技术当中前三个已经成功申请专利。

不少人会存有疑问，为何咱们不使用 React Native 或者 Weex，而是本身作一个体验技术？

使用此类技术存在这么几个问题：

• 平台化而非插件化：使用此类技术后，你的总体前端业务代码就要所有构建在这个平台之上，若是平台出现问题或者架构更新，转型成本是彻底重写一套业务代码。而采用插件化方案，加了体验会更好，没有也能够降级，这样转型的成本会少不少

• 技术栈捆绑：每个技术都有捆绑的一个生态，在用 RN 的时候你必须使用 React ，在用 Weex 的时候必修使用 Vue，转型成本一样高，且限制了业务选型

• 解决问题被动：当系统更新或技术自己出现质量问题的时候，业务的研发团队几乎没有能力去解决，只能等待技术官方研发团队或开源社区去解决，这会使咱们的业务很被动

EH 自己不捆绑任何技术，即便你不使用任何的框架也能够完整使用 EH 的功能。

体验 EH 功能能够在应用商店中下载 “美团钱包”，在首页中点击手机充值、生活缴费或“优惠” Tab 中的内容。

SSR / 构建时预渲染技术

Server Side Rendering 这里就很少赘述了，你们都了解。构建时预渲染技术是咱们特殊研发的一个技术。它的特色是从首帧速度优化角度来说，理论上比 SSR 更快更稳定。

构建时预渲染技术主要实现方式是：在编译完成后，启动一个 Web Server 来运行整个网站，再开启多个无头浏览器（Headless Chrome，PhantomJS 等无头浏览器技术）去请求全部项目的路由，当被请求的网页渲染到第一个有意义的渲染时（FMP 参考 Google 的衡量体系）主动抛出一个事件，该事件由无头浏览器截获，无头浏览器截获后将此时的页面 HTML 内容保存下来生成一个 HTML。最终发布这个 HTML。此 HTML 中包含 FMP 所须要的全部 CSS 及 DOM 结构。

事实上 SSR 和构建时预渲染技术都是为首帧速度优化服务的，首帧速度优化的核心有两点：

1. TTFB（time to first byte) 首字节时间
2. 在首个请求的响应当中返回首帧绘制所须要的 CSS 及 DOM 结构。

为何说构建时预渲染会比 SSR 快呢？

SSR 目前前端领域主流实现方式是使用 Node 做为中间层，负责数据的获取和界面的拼装，其 Node 层可能后面对接着一个或多个数据来源（业务系统），它的响应速度受限于最慢的那个数据来源。而构建时预渲染劣势是不包含数据，但优点是其首帧事件彻底不依赖任何数据来源，从 Nginx 层直接返回，响应速度更快，同时流量负载更高。

为何说构建时预渲染会比 SSR 更稳定？

SSR 在 Nginx 层后面还须要一层 Node（典型架构）作支撑 ，而构建时预渲染从 Nginx 层直接返回，其关键链路上少了一环须要保障稳定性的服务，因此稳定性更强。

金融服务平台在 SSR 和构建时预渲染上都有不少项目在运行，在 SSR 的优化上也有丰富的经验去保障速度和稳定性，在选型上的考量主要是首帧对数据的依赖程度。

离线化技术

离线化技术能够将网页的网络加载时间变为 0，在离线化的选型上美团点评内部有不少选择，咱们也在不一样的方向进行尝试。其中咱们的选择包括：

• 标准技术：
  • Application Cache：实现上各个平台各个浏览器有一些差别，即便把“没法更新的坑”踩过仍是会有不少“没法离线”的坑，PASS
  • Service Workers：Service Workers 是团队一直跟进的技术，目前在测试已经接近正式发布，只是在 iOS 上还没法大范围使用，长期看好，暂时 PASS
• 借助 Native 能力的自有技术：
  • 美团平台技术团队的类 Service Workers 的被动离线化技术
  • 美团旅行技术团队的离线包技术

留下来的只剩下两个自有技术，这两个技术的最大区别是，是否解决了首次加载问题？离线化方案的首次加载问题是一个很难的技术领域，我认为其最核心的问题是什么时候加载，提早加载会不会用户在很长一段时间内都不会用到致使浪费流量？使用包含首次加载优化的离线化技术的项目多了会不会形成加载拥塞？是否是须要分析用户行为数据去更精准的进行离线包的提早加载？这当中存在太多不肯定性，不过我相信咱们的技术团队必定可以想出优美的解决方案去解决这个问题。

另外基于 Native 能力的离线化技术还存在一些来自平台的限制，如 iOS 的 WKWebView 不支持请求拦截，而请求拦截是离线化的关键技术，这个缘由致使在 WKWebView 上没法实现离线化。

WKWebView 的优点是：运行和渲染速度更快，与 Safari 内核一致 Apple 重点迭代跟进问题；劣势是：启动速度慢，没法拦截请求进而使用自有的离线化技术。

权衡离线化所带来的巨大优点和 WKWebView 的速度优点，咱们选择继续使用 UIWebView。（曾经在 iOS 11 发布前业界一度认为 Apple 会在 iOS 11 中支持 WKWebView 的请求拦截）

字符级增量更新方案

字符级增量更新方案是一个前端领域研究了好久的课题，智能支付团队近期在这一领域有了突破性进展，这个技术方案能够经过字符级增量更新减小文件传输大小，节省流量、提升页面成功率和加载速度。其中增量计算能力由美团平台的静态资源托管方案 Build Service 支持。主要应用在扫码付项目上。

扫码付项目是美团金融智能支付团队面向 C 端消费者推出的一款 H5 融合支付类的产品，消费者在商家消费以后，可以使用多种 App 进行扫码支付，同时可对商家进行评价，支持美团、大众点评、微信、支付宝、美团钱包等多种 App，目前业务日均 PV 千万级。

字符级增量更新方案的详细介绍，请参考以前的文章美团金融扫码付静态资源加载优化实践。

监控系统

美团点评内部前端监控系统包括：

• Sentry：异常监控
• Performance：性能监控
• CAT：网络监控

在技术栈统一前，咱们团队这三个监控工具在同时使用，然而监控系统上前端和后端不一样的是前端对代码尺寸有要求，接入的监控系统多会对项目的加载速度有影响。综合多方面因素，咱们在本次技术栈统一中选择了CAT来做为咱们主要的监控系统。主要是它包含前二者的功能。

CAT（详情能够参考《深度剖析开源分布式监控CAT》 一文）是一个美团点评的全端基础监控组件，在后端为各业务线提供全面的监控服务和决策支持，提供系统的性能指标、健康情况、基础告警等功能。在前端覆盖美团点评全部APP，提供近实时的多维数据分析、立体式监控、告警等功能。提供了近实时的多维数据分析，立体式监控功能。

CAT很大的优点是它是一个实时系统，从数据生成到服务端处理结束是秒级别，秒级定义是 48 分钟 40 秒时基本上能看到 48 分钟 38 秒的数据，总体报表的统计粒度是分钟级；第二个优点，数据是接近全量统计，目前大约5%的高QPS 项目是采样统计。

协议

目前咱们使用的协议均为 HTTP/2，支付是金融最先使用 HTTP/2 的部门，因为支付业务的特殊性，在一开始咱们就是使用的 HTTPS ，进而很早就使用上了 SPDY。

在15年 HTTP/2 标准化的时候咱们直接更新集群使用上了 HTTP/2，在 SPDY 和 HTTP/2 这种具备多路复用功能的协议上咱们的前端架构所有作的都是按需加载的方式，大大减少了由“减小请求数” 所带来的流量冗余。最大化利用了 HTTP 自己的缓存机制，经过减少客户端大小的方式大大提高了网络加载性能。

安全方面

安全方面在前端咱们使用：

• HSTS： 防 SSLStrip 攻击的标准解决方案
• CSP： 防跨站脚本攻击的标准解决方案

同时在核心接口上咱们有一个自研的网页请求签名方案，来在必定程度上保障请求是从咱们的客户端中正常发出的。

总结

以上是对金融平台前端技术体系的介绍和我的的一些思考，最后说一下采用此技术体系所达到的一些效果。

效率

• 因为 Vix 和设计部门统一标准，在界面构建过程当中能够减小至少 80% 的时间，而这部分恰巧占总体研发时间的 60% 以上
• 联调部分咱们有 Portm 进行协做解耦，能够减小联调时间一半以上，通常一个项目联调部分占总体研发时间的 20% 左右
• 另外咱们还有很是强大的脚手架 fe-bone ，它能够帮咱们快速建立项目，节省建立项目时间 95% 以上。因为这个部分业务属性较强，未在统一技术体系中说起

使用这几项技术的一个直接感觉是人效大幅提高，一个前端同窗能够并行 2～4 个项目，同时对接 4～10 个后端研发。

体验

在使用 Titans 解决功能体验，使用 EH 解决界面体验的状况下，加上构建时预渲染和离线化技术的加持，咱们能够作出专业前端都看不出来是 Hybrid 的高体验 Hybrid 应用。

质量

在质量方面咱们有：

• Lint 工具保障代码风格和质量
• TypeScript 作类型检查及类型推导
• Mocha 保障基础工具可用性
• Freekite 保障业务流程可用性
• CAT 作异常监控

在整个质量体系架构的演进过程当中，其实不仅是这些工具来保障质量和可用性，还会有不少流程规范去保障，在可用性保障上感兴趣能够参考这篇文章：《前端可用性保障实践》。

在这些实践中咱们很好的保障了产品的稳定运行。同时也欢迎你们在前端可用性保障上多探讨。

做者简介

• 陈禹霖，美团点评技术专家，目前负责金融平台钱包、支付、闪付前端团队。

招聘信息

最后，金融平台的技术体系仍是在不断快速演进中，而前端领域也是一个快速演进的领域，咱们须要更多的优秀人才加入，感兴趣的小伙伴能够将简历发送到我所在的钱包团队，邮箱：chenyulin02[at]meituan.com，或将简历投送到金融平台（详见：美团点评招聘官网）。同时团队提供大量 Web 前端、Android、iOS、Java 实习机会，寻找实习机会的同窗也能够将简历发到个人邮箱中。

前端, 金融平台, Web前端, 技术体系, 移动

#看看其余

前一篇: 大众点评App的短视频耗电量优化实战 后一篇: 美团旅行销售绩效系统研发实践

#一块儿聊聊

如发现文章有错误、对内容有疑问，均可以关注美团技术团队微信公众号（meituantech），在后台给咱们留言。

咱们每周会挑选出一位热心小伙伴，送上一份精美的小礼品。快来扫码关注咱们吧！

一行代码，亿万生活。

• 网站首页
• 文章存档
• 关于咱们