滴滴：WebApp实践经验总结

深藏阁楼爱情的钟 2022-04-14 04:15 341阅读 0赞

本文为滴滴公共FE团队在WebApp方向的一些实践经验总结，主要内容包括：WebApp首页技术架构、前端工程化在WebApp的实践、通用地图JS库的设计和实践、 统一登录SDK的设计、通用客户端JSBridge的封装、在公共部门做通用服务的一些感悟、个人成长总结。

## 1. WebApp首页技术架构 ##

### 需求分析 ###

（1）滴滴多条业务线在一个 WebApp 页面里运行，业务线之间互不影响。

（2）业务线发单流程基本一致，部分业务线支持自定义化。

（3）业务线可以独立自主迭代上线，不需要公共团队的参与。

（4）新业务线可以快速接入首页。

### 解决方案 ###

（1）每个业务线提供自已的 biz.js，首页加载的时候会异步请求这些 JS 文件。

（2）公共提供全局的 dd.registerBiz(option) 方法，供业务线 biz.js 调用，同时在 option 里提供 init、onEnter、onExit、orderRecover 等钩子函数，业务线的代码通过调用 dd.registerBiz 方法完成接入。

（3）把页面拆分成多个区块，有一些公共区块如一级导航菜单和地址选择区块；也有一些业务线区块如 ETA 区块、发单区块、自定义区块等。公共会在业务线区块下根据 registerBiz 注册的业务线动态创建业务线独立的子区块，业务线可以填充这些子区块的 DOM，公共这边提供通用的样式。创建业务线区块的时候完毕会调用 init 钩子函数，业务线可以在这个函数里做一些初始化操作。

（4）公共负责管理业务线的切换，来控制每个业务线子区块的 show 和 hide，这些细节业务线不用关心。在切入的时候会调用 onEnter 钩子函数，切出的时候会调用 onExit 钩子函数。

（5）公共会提供业务线一些公共方法调用，比如统一的 sendOrder 发单方法。还会通过事件机制和业务线通讯，比如当公共定位完成会调用 events.emit('location.suceess',posInfo) 派发事件，业务线可以监听该事件拿到定位信息。

（6）公共会提供一些封装好的通用组件，供业务线调用。

（7）业务线的 biz.js 地址是通过服务端渲染前端模板的时候通过变量传到模板里的，这个 JS 地址业务线可以自主配置，达到业务线自主上线的目的。

（8）新业务线的接入只需要提供业务线 biz.js，实现 dd.registerBiz 接口。公共不用关心具体接入的业务线，与业务线这边完全解耦。公共这边还提供了一套完整的 Wiki，方便业务线接入。

### 技术栈 ###

（1）scrat 完成模块化 + 构建。

（2）zepto + gmu 实现组件化。

（3）前端模板 handlebar。

（4）combo 服务。

### 部分代码示例 ###

业务线接入的 biz.js 示例如下：

dd.registerBiz({
            id: 123, 
            _tpl: {
                // ...
            },
            init: function (ids) {
                // ...
            },
            onEnter: function () {
                // ...
            },
            onExit: function() {
                // ...
            }
        });

## 2. 前端工程化在WebApp的实践 ##

### 需求分析 ###

（1）支持模块化开发，包括 JS 和 CSS。

（2）组件化开发。一个组件的 JS、CSS、模板放在一个目录，方便维护。

（3）多个项目按项目名称 + 版本部署，采用非覆盖式发布。

（4）允许第三方引用项目公共模块。

（5）要支持 CSS 预处理器，前端模板。

（6）与公司的 jenkis 发布平台配合，上线方便。

（7）前后端分离，前端可以独立自主上线。

### 解决方案 ###

（1）使用 [scrat][] 做前端工程化工具，完美支持上述需求分析中的前五条需求。

（2）每个项目用一个 git 的 repo 维护，然后有专门上线的2个 repo，一个存储静态资源，另一个存储页面模板。每个项目有一个shell脚本，脚本通过 scrat 编译当前项目，把编译后的结果分别 push 到上线的 repo。然后上线的 2 个 repo 关联公司的 jenkis 平台发布上线。

（3）每个项目迭代上线前修改版本号，所有静态资源都会增量发布。上线过程先全量上线静态资源，线上模板仍然指向旧的资源，不会有任何问题。然后再上线模板，先上到预发布环境让 qa 回归，回归完后再全量上线模板，完成整个上线流程。

### 部分代码示例 ###

一个WebApp项目的目录结构如下：

一个组件的目录结构如下：

按项目名称 + 版本发布的 fis-conf.js 配置规则如下：

编译后部署的目录结构如下：

## 3. 通用地图JS库的设计和实践 ##

### 需求分析 ###

（1）支持多种地图、多种地图场景的开发。

（2）屏蔽底层地图库（高德、腾讯）的接口差异。

（3）实现小车平滑移动。

### 解决方案 ###

（1）底层对腾讯地图和高德地图分别封装（不会在源码中出现 if(qq)\{\} 风格的代码)，依据 webpack 动态打包成 2 个 JS文件，上游根据需求异步加载 JS ，对外提供同一套编程接口。

（2）抽象地图场景的概念，可以通过接口注册一个场景类，在场景中可以操作各种封装好的地图组件和方法，编写业务逻辑，实现需求。

（3）小车的平滑移动通过封装地图 SDK 提供的底层 marker，轮询小车坐标点，实现小车平滑移动（CSS3），并把“移动 + 转向 + 移动...”一系列操作抽象出动画队列的概念。

### 技术栈 ###

（1）原生 JS。

（2）webpack 打包。

### 行程分享实践 ###

![20160815080056_836.png][]

行程分享这个场景中，有等待接驾、行程中、行程结束等状态，有轨迹，小车平滑移动等功能。我们要做的就是利用通用地图 JS 库暴露的接口去编写行程分享的逻辑。

贴一下部分代码，看一下如何去使用封装好的地图 JS 库。

我们可以先去写一个行程分享的场景：tripShare.js

var Map = window.map;
    var _ = Map.utils._;
    var inherit = Map.utils.inherit;
    var api = Map.utils.api;
    var config = Map.utils.config;
    var EventEmitter = Map.utils.EventEmitter;
    var Car = Map.component.Car;
    var StartPoint = Map.component.StartPoint;
    var EndPoint = Map.component.EndPoint;
    var TrackControl = Map.control.TrackControl;
    var TrafficControl = Map.control.TrafficControl;
    var TrafficLayer = Map.layer.TrafficLayer;
    var Polyline = Map.Polyline;
    function TripShare(map, options) {
        TripShare._super.call(this);
        // ...
    }
    inherit(TripShare, EventEmitter);
    TripShare.prototype.begin = function () {
        // ...
    };
    // ...

然后我们这样去注册场景。

我们可以调用场景的方法，又由于场景继承了 EventEmitter 事件中心，它会通过 trigger 派发事件，我们可以监听这些事件，去做一些事情。

## 4. 统一登录SDK的设计 ##

### 需求分析 ###

（1）滴滴有众多业务线，每个业务线都有独立的域名，需要打通各个WebApp域名的登录态。

（2）方便新老业务线、运营活动等页面接入登录。

（3）提供简单、友好的接口。

### 解决方案 ###

（1）与账号部门合作，通过跨域方式访问 passport 域名下的接口。跨域方案是通过 iframe passport 域名下的页面，利用 postmessage 进行通信。登录成功后会在 passport 域名下利用种下 ticket。后端提供判断是否登录的接口，前端请求这个接口的时候会从 passport 域名下读取 ticket 并把它作为请求的参数传给后端，这样一旦用户在 a 域名下登录成功，那么在 b 域名下调用是否登录接口，返回的就是登录成功的结果，这样就打通了多个域名的登录态。

（2）封装复杂的登录交互细节，对外提供简单的交互接口。

（3）提供完善 Wiki 文档，建立专门的钉钉服务交流群。

### 技术方案 ###

![20160815080057_701.png][]

### 技术栈 ###

（1）原生 JS。

（2）webpack 打包。

## 5. 通用客户端JSBridge的封装 ##

### 需求分析 ###

（1）内嵌在滴滴 App 端里的页面，需要通过 JSBrigde 的方式获取端的一些能力。

（2）屏蔽 iOS 端和 Android 端的一些底层通讯差异。

（3）提供简单、友好的接口。

### 解决方案 ###

（1）对 iOS 和 Anroid 的交互接口进一层封装，所有需要与端通讯的接口封装成 DDBridge.funcName(options,callback) 的方式。

（2）对端的一些具象接口，比如分享微信、分享微博等做更高级封装，提供share接口，通过参数指定分享到不同的渠道。

（3）提供完善 Wiki 文档，建立专门的钉钉服务交流群。

### 技术栈 ###

（1）ES6 + eslint。

（2）webpack 打包。

### 部分代码示例： ###

export function initGlobalAPI(DDBridge) {
        each(config.api, (conf, name) => {
            DDBridge[name] = makeBridgeFn(conf);
            DDBridge[name].support = conf.support;
        });
        initSupport(DDBridge);
        initVersion(DDBridge);
        initShare(DDBridge);
        initPay(DDBridge);
    };
    export function makeBridgeFn(conf) {
        return function (param = '', callback = noop) {
            if (arguments.length === 1 && isFn(param)) {
                callback = param;
                param = '';
            }
            let fn = conf.fn;
            if (supportPrompt) {
                promptSend(fn, param, callback);
            } else {
                bridgeReady((bridge) => {
                    bridge.callHandler(fn, param, (data) => {
                        if (isStr(data)) {
                            data = JSON.parse(data);
                        }
                        callback(data);
                    });
                });
            }
        };
    };

## 6.在公共部门做通用服务的一些感悟 ##

入职滴滴一年，造了不少公司级别的“轮子”，不少轮子已经在业务线跑起来了，运行状况还算可以。我也总结了做通用服务要注意的几点。

（1）一定要好用，用起来要简单。

这是我一直贯彻的理念，如果通用服务不好用，那一定会受到质疑和吐槽。同样我们用开源的框架，也一定会选简单好用的，当年 jQuery，prototype，tangram 等 JS 库百家争鸣的时候，jQuery笑到了最后，为什么呢？很简单：jQuery好用啊，一个 $(xxx) 搞定一切。相比 tangram 那种 Baidu.T.createDom() 的方式，高下立判。

我们在设计通用 JS 库的时候，一定要站在更高的角度去对需求做抽象。比如在设计统一登录 SDK，首先要想的不是复杂的交互逻辑、如何去实现、有哪些技术难点，而是去想，别人怎么用这个库，怎么用起来爽。登录的需求就是用户触发一个登录动作，登录完成能拿到用户一些信息，所以我就设计一个login(callback)接口，那么使用方只需要简单调用这个方法，就可以完成登录需求，而不用去关心登录各种复杂的细节。

（2）该做封装的地方要封装，对外暴露的接口越少越好。

封装很重要，举个通俗的例子，有一天我去洗手，发现水龙头的开关把手没了，把原始的开关暴露给我了，虽然也能用，但是体验就会很不好。水龙头的开关把手就是对原始开关的封装。我在做 JSBridge 库 的时候，也是一样的道理，如果让用户直接调用 iOS 和 Andrid 提供的原生 bridge 接口的，也能 work，但是非常难用，需要判断 iOS 和 Android 接口的差异，还需要考虑 bridge ready 事件后才能执行方法等，这些都是我原本不需要关心的细节。所以我们的库就是帮助用户封装掉这些“脏活”，对外提供简单的 DDBridge.funcName(options,callback) 接口，优化使用体验。

为什么说对外暴露的接口越少越好，因为接口越多，则说明用户的学习成本越高，比如如火如荼的 Vue.js，其1.x 版本很多接口的功能大同小异，所以在 2.0 版本的 Vue 就干掉了很多接口，减少了用户的学习成本。同样的，我们在做 JSBridge 分享接口相关的时候，也通过一个share接口封装了端提供的微信分享、支付宝分享、微博分享等接口。

（3）先思考再动手，设计合理的代码组织方式。

在写代码之前，一定要先思考清楚，切忌上来就写代码，那样很容易写成一波流代码。合理的代码组织方式，有利于代码的扩展和维护，最基本的就是模块化。这里没有银弹，需要大量的实践和总结，学会抽象的看问题，看一些设计模式相关多书籍，多看优秀的开源的代码，可以先从模仿开始。

由于我们写的是通用服务，用户也可能会提出各种需求，当遇到这个问题的时候，不能上来就写代码去实现甚至hack，而是先思考这个需求是不是可以抽象成通用的需求，如果不能抽象，我们如何更优雅的实现，之前的设计是不是有问题。总之，要多想多思考，也可以和小伙伴讨论，争取做到是在设计代码而不是堆代码。

（4）追求体验极致。

现在很多前端都在玩 Node，玩构建工具，玩 MVVM 框架，玩 ES6，好像感觉学会了这些就可以提高身价。其实，这些大部分都是工具，是服务我们平时工作的，不要忘了我们的本行还是前端，还是需要写页面的。其实前端有些组件和效果如果想要追求体验极致的话，也不容易。如果能做到极致，身价也不会低。举个例子，我在写 mofang 移动端组件的时候，有个筛选器组件 picker，类似 iOS 原生 UIPickerView 的东东，我当时拿到需求的时候，也从 GitHub 上搜索过，没有满意的，体验都很一般，于是我就对比 iOS 原生的 UIPickerView的体验，思考它的实现、一点点细节的调试，最终也撸出来体验几乎一致的移动端 H5 picker 组件。举这个例子其实想说明，我们在做通用服务的时候，要多花心思，如果能做出一些极致体验的东东，不仅对用户来说他们很乐意使用，对自己也是一种锻炼。

（5）一定要写 Wiki。

要写 Wiki！要写 Wiki!要写 Wiki！重要的事情说 3 遍。由于我们做通用服务，免不了和用户打交道，Wiki 就尤为重要了。我们需要把通用服务的接口，使用方式，常见问题等都写清楚。好的文档可以很好的指导用户如何使用我们的服务，这样可以大大的减少沟通成本，节约我们自身和用户的时间。

（6）要学会销售。

有些人可能会觉得写通用服务似乎比做业务的同学更高大上，其实不然，本质上我们都是在为公司打工，都是在输出自己的价值，只是做事的重心不同。那么做公共的同学的价值在哪里？就是让自己写的通用服务被更多的人用，去提升他们的工作效率。所以，我们要学会销售自己的服务，而不是写完一个的服务摆出一副你爱用不用的态度。如果你写出来的东西没人用，就算它再牛逼，对公司的价值也是 0。另外，我们还要学会从业务中去沉淀服务，要去发现业务中的痛点，可以提升效率的地方，然后用技术的手段和工具去解决它。

（7）一颗服务的心。

做公共的同学一定要有颗服务的心。我们售卖的是自己的服务，那么也一定要做好售后服务，除了 Wiki，各种沟通钉钉微信沟通群也要积极响应，耐心的去帮助用户解决问题，其实很多时候，都是靠着用户去帮我们去发现 Bug ，完善功能和优化体验的。

## 7.谈下我的个人成长 ##

我入前端这行已经4年了，在学校的时候我是玩 .net 的，喜欢折腾。毕业后当然和大部分应届生一样，渴望进 BAT 这样的大公司，不过 BAT 几乎不招 .net 的岗位。由于我读研的时候做过一些网站方向的开发，所以就投了百度的一个相近的职位——Web前端开发。这里我要特别感谢我百度的mentor张袁炜，他是一个对技术要求很高的人，受他的影响，我也成为一个对技术有追求的人。四年来，我写过页面，写过网页游戏、写过Chrome插件、写过框架、写过组件、写过服务，由于一直在做不同的东西，每一年我都有所收获。

兴趣导向，有的时候我感觉写代码和玩游戏是一样爽的事情，我也很喜欢看优秀的开源作品，看看他们的代码设计、技术细节，会吸收一些不错的东西到自己平时的工作中。

前端这几年发展很快，新技术层出不穷，有的时候，我们要跳出自己的舒适圈，接纳一些新事物，新技术，去让自己不断学习，而不是满足于自己已掌握的那些技术。这里我不是去倡导滥用新技术，而是要保持一颗学习的心态，一颗包容的心态。

[scrat]: http://scrat.io/#!/index
[20160815080056_836.png]: /images/20220414/dca75015c5cf43f19abc4059a174bfb8.png
[20160815080057_701.png]: /images/20220414/7735914e4f7046cc9e779112a7d6af00.png