滴滴:WebApp实践经验总结

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

index3

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项目的目录结构如下:

project
  |- component_modules(生态模块)
  |- components       (工程模块)
  |- views            (非模块资源)
  |- component.json   (模块化资源描述文件)
  |- fis-conf.js      (构建工具配置文件)
  |- package.json     (项目描述文件)
  |- index.html
  |- …

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

components
  |- header
    |- header.js
    |- header.styl
    |- header.tpl
    |- logo.png

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

var meta = require('./package.json');
fis.config.set('name', meta.name);
fis.config.set('version', meta.version);
// 自定义发布规则
var userRoadMap = [
    {
        reg: /^\/components\/(.*\.tpl)$/i,
		isHtmlLike: true,
		release: '/pages/c/${name}/${version}/$1'
    },
    {
        reg: /^\/pages\/(.*\.tpl)$/,
		useCache: false,
		isViews: true,
		isHtmlLike: true,
		release: '/pages/${name}/${version}/$1'
    },
    {
        reg: /^\/pages\/boot\.js$/,
		useOptimizer: false,
	},
	{
		reg: /^\/pages\/(.*\.(?:js))$/,
		useCache: false,
		isViews: true,
		url: '/${name}/${version}/$1',
		release: '/public/${name}/${version}/$1'
	},
	{
		reg: /^\/pages\/(.*\.(?:html))$/,
		useCache: false,
		useOptimizer: false,
		isViews: true,
		release: '$1'
	},
	{
		reg: /^\/pages\/(.*)$/,
		useSprite: true,
		isViews: true,
		url: '/${name}/${version}/$1',
		release: '/public/${name}/${version}/$1'
    }
];
var defaultRoadmap = fis.config.get('roadmap.path');
fis.config.set('roadmap.path', userRoadMap.concat(defaultRoadmap));

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

|-public (生成的静态资源目录)
    |- c
      |- project
        |-1.0.0
          |- header
           |- header.css
           |- header.css.js
           |- header.js
        |- home
        ...
    |- project
      |- 1.0.0
      |- lib
 |- index.html
 |-views    (模板目录)
 |- …

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

需求分析

(1)支持多种地图、多种地图场景的开发。

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

(3)实现小车平滑移动。

解决方案

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

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

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

技术栈

(1)原生 JS。

(2)webpack 打包。

行程分享实践

10

行程分享这个场景中,有等待接驾、行程中、行程结束等状态,有轨迹,小车平滑移动等功能。我们要做的就是利用通用地图 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 () {
    // ...
};
// ...

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

var Map = window.map;
var fromlat = 31.17626;
var fromlng = 121.425;
var tolat = 31.20425;
var tolng = 121.40398;
Map.ready(function (mapInstance) {
    var map = mapInstance.createMap('container', {});
    var TripShare = require('./tripShare');
    var scene = map.scene.register(TripShare, {
        orderStatus: 1,
        url: 'xxxx',
        oid: 'aaaa',
        pathUrl: 'xxxx'
        fromlat: fromlat,
        fromlng: fromlng,
        tolat: tolat,
        tolng: tolng,
        usePath: true
    });
    scene.begin();
    scene.on('path.badCase', function(badCase) {
        // do anything
    });
});

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

4. 统一登录SDK的设计

需求分析

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

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

(3)提供简单、友好的接口。

解决方案

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

(2)封装复杂的登录交互细节,对外提供简单的交互接口。

(3)提供完善 Wiki 文档,建立专门的钉钉服务交流群。

技术方案

11

技术栈

(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插件、写过框架、写过组件、写过服务,由于一直在做不同的东西,每一年我都有所收获。

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

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

-END-

分享到:
赞(0)