速记：SFDC 2016 - 滴滴出行 郑涛 《滴滴客户端的构建挑战》.docxVIP

主题：2016杭州开发者大会—移动端分会场 时间：2016年12月10日下午1：40 会场主持人：奇点微博 图拉鼎 议题：《滴滴客户端的构建挑战》 讲师：滴滴出行 郑涛 郑涛：大家好，我叫郑涛，来自滴滴，昨天从北京刚刚赶过来的，今天分享主要滴滴客户端的构建，可能大家看了很多构建方面的分享比较少的，我今天指的构建就是我们辕马到APK整个过程，指的安卓SDL（音）过程。现在移动端假如做的比较长时间以后发现，我们实现一个功能或者做一个什么样比较黑的科技，难度并不是特别大，安卓发展大概有七八年的时间，现在开源的项目也特别多，所以我们做任何东西的时候发现门槛比以前低了很多，但是移动端开发的挑战更多来自于产品流程和开发流程的转变，比如说现在比较多插进化开发方式这是开发流程的转变，还有产品流程的转变，假如有很多公司不停开发十个功能，到了某一个版本发布只其中两个，到了下一个版本再抽出两个再继续发布，这除了产品层面流程的改变，这些挑战都是离不开构建的，今天主要讲一下滴滴构建遇到的一些挑战。 今天的内容主要包含四块：第一个先给大家介绍一下开发的规范以及构建整体的流程，第二部分我拿两个事例和大家分享一下我们遇到的挑战以及对应的解决方案，第三个插件化的支持，第四部分是未来的一些规划。 第一部分现在我先介绍一下，现在整个滴滴大家打开APP以后，看到的这些不同的出行服务，其实背后都是不同的业务部门，然后对应的不同的团队，就是不同的客户端不同服务器在做，最终我们构建的目的就是要把不同团队写的代码最后打到整个滴滴的乘客端里面，团队主要由业务团队和SDK团队组成，平台SDK，专用车，出租车，快车等等很多。滴滴大概发展的四年因为这个平时大家也会打车能感觉到滴滴业务的膨胀，包括市值的膨胀，包括我们感觉到团队的膨胀，现在大概应该有十几条业务线，安卓和IOS开发加起来有200多人，开发团队的分布北京是总部，上海和杭州都有，随着团队的膨胀和产品的膨胀，我们主要经历了三个阶段：第一个阶段大概在2015年前半年的时候，我们还是用那个EKEPS（音）做ID来开发，那个时候整个滴滴客户端只有一个，当时业务先快车、专车、出租车，顺风车那时候也开始做，那个时候大家在一个里面开发，导致我们发展的时候经常会去熬夜，假如专车可以发布，但是顺风车有一些功能没有开发完成大家都要等待，所以经常要熬夜，另外假如改一次Bug，所有的业务线都要回归测试，这个业务先很不好，牵一发而动全身，2015年后半年进行一次比较大面积的重构，当时开发的环境切换到EDSDUD（音），那时候开发不久，不是特别的稳定，大家的技术站没有转移过来，我们有几个高地，自己配合一下，基于辕马构建自己的EKPEK（音）每个单独变成AAR以后最后再来整体的集成，编辑条款里面利用Eclipse（音），另外对于每个线的项目结构要求比较严格，维护起来不太好维护，去年年末到今年就转移到现在的模式，多项目基于AAR集成，每个业务线丢吗开发完成以后先自测，自测以后以AAR模式发到公司的业务库，有一个单独的环境，先把AAR拿到最后打到APK，现在这种方式不管从应用的角度和结果的角度现在是比较满意的。 下面说一下开发规范，最基础的部分平台SDK，主要做一些基础服务，日志、网络，公共的功能，滴滴客户端的支付模块，还有地图模块，这是专门有团队人员在做，每一个业务线类似出租车快车，他们负责自己业务的迭代，直接依赖于平台SDK开发就可以，平台SDK和业务线的联系把它称之为业务的组建路口，打开滴滴客户端以后点击对应的快车，出来把快车的界面给加载进来，后续整个操作是快车Jave，业务的主线入口是Jave级别，把jave（英文）经过一些改造移植到安卓里来，大概原理在网上可以查到，因为业务线自己开发代码以后，把自己的入口以配件的行为放到AR里面，根据平台根据业务线加载滴滴里面，现在再增加一个业务线非常容易，不需要改代码，自己业务线代码开发好以后，进入到配置就可以乘客端，同样今天把一个业务线给去掉也非常容易，AAR有一个问题，AAR打包的时候如果同名的文件有一些冲突和覆盖，这个解决的方案通过流程上一些规定，把每个业务线的资源加业务前缀，比如出租车，所有的图片、动画前面加一个Taix，通过这种渠道避免资源的冲突，协作。主要一块是业务线需要依赖平台SDK去开发，在一定周期SDK平台提前输出给业务线，让他们基于最新的SDK开发，SDK规定每个API的变化不能太频繁，每次有了API的变化必须得发邮件出来，原来怎么使用，现在怎么使用，有哪些改变，业务线基于最新的SDK开发比较清楚，直接很清楚，所以照搬过去就行，提前的时间大概三四天，预留足够的时间让业务线修改就可以。 下面说一下整体的构建流程，第一步平台SDK需要先发布，这个发布后续会讲，平台S