手机淘宝构架演化实践及优化，天猫，淘宝服务

> 天猫App

 安全模式：天猫App启动保护实践- https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=2247488429&idx=1&sn=448b414a0424d06855359b3eb2ba8569&source=41#wechat_redirect
 天猫App的动态化配置中心实践- https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=2247488504&idx=1&sn=4786b34ecf9ff776fc2cbdd305159c3c&source=41#wechat_redirect
 天猫App A/B测试实践- https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=2247488501&idx=1&sn=6b077dc8656fec0e93414dd5743f8ffa&source=41#wechat_redirect
  在App热修复中有一个特殊情况，就是应用在启动阶段crash，根本启动不了，热修复就难以奏效，不过这种情况也能解决。前段时间微信读书分享了他们的启动保护方案，现在天猫也分享了他们的实践，叫做安全模式。
  天猫安全模式致力于解决APP启动阶段的crash等问题，同时具备自修复能力、同步热修复能力，是一整套启动保护的解决方案。

> 阿里手淘技术架构演进细节- https://toutiao.io/posts/elqtm7/preview
在Web 1.0时代（1999-2005），客户端非常“薄”，工程师的主要工作集中在浏览器兼容性处理。核心问题如扩展性、伸缩性、稳定性、性能等，都集中在后端。随着硬件设备和网络能力大幅度提升，尤其AJAX通信的出现，Web进入到2.0时代（2005至今），这是一个富交互的客户端时代。

Android 手淘工程师角度分析App使用的开源框架- http://yeungeek.com/2017/06/28/Android%E5%B7%A5%E7%A8%8B%E5%B8%88%E8%A7%92%E5%BA%A6%E5%88%86%E6%9E%90App%E4%BD%BF%E7%94%A8%E7%9A%84%E5%BC%80%E6%BA%90%E6%A1%86%E6%9E%B6-2-%E6%89%8B%E6%B7%98/
淘宝App所使用的框架- https://h5.m.taobao.com/other/android_legal.html

OneSDK与手机淘宝技术能力开放- http://www.infoq.com/cn/news/2015/08/onesdk-shoutao
手机淘宝构架演化实践- http://www.infoq.com/cn/news/2014/12/taobao-app-evolution/

-- 淘宝服务端高并发分布式架构(十四次)演进之路- https://mp.weixin.qq.com/s/oXepYTJEotQjglqh0OyaYQ
  目前开源和商用都已经有不少MPP数据库，开源中比较流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、华为的LibrA等等，不同的MPP数据库的侧重点也不一样，如TiDB更侧重于分布式OLTP场景，Greenplum更侧重于分布式OLAP场景，这些MPP数据库基本都提供了类似Postgresql、Oracle、MySQL那样的SQL标准支持能力，能把一个查询解析为分布式的执行计划分发到每台机器上并行执行，最终由数据库本身汇总数据进行返回，也提供了诸如权限管理、分库分表、事务、数据副本等能力，并且大多能够支持100个节点以上的集群，大大降低了数据库运维的成本，并且使数据库也能够实现水平扩展。
  微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。

在云平台中会涉及如下几个概念：
IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

> 淘宝 持久配置diamond
    diamond是淘宝内部使用的一个管理持久配置的系统，它的特点是简单、可靠、易用，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理。
    diamond为应用系统提供了获取配置的服务，应用不仅可以在启动时从diamond获取相关的配置，而且可以在运行中对配置数据的变化进行感知并获取变化后的配置数据。 
    持久配置是指配置数据会持久化到磁盘和数据库中。
   Diamond作为一个分布式环境下的持久配置系统，有一套完备的容灾机制，数据被存储在：数据库，服务端磁盘，客户端缓存目录，以及可以手工干预的容灾目录。 客户端通过API获取配置数据按照固定的顺序去不同的数据源获取数据：容灾目录，服务端磁盘，客户端缓存。
• 数据库主库不可用，可以切换到备库，Diamond继续提供服务 
• 数据库主备库全部不可用，Diamond通过本地缓存可以继续提供读服务 
• 数据库主备库全部不可用，Diamond服务端全部不可用，Diamond客户端使用缓存目录继续运行，支持离线启动 
• 数据库主备库全部不可用，Diamond服务端全部不可用，Diamond客户端缓存数据被删，可以通过拷贝备份的缓存目录到容灾目录下继续使用。

> 高其适应移动互联网生态的产品研发能力，同时也嵌入了移动端的安全、风控能力，并结合支付宝APP的众多应用场景来进行金融业务创新。
 天弘基金移动App客户端架构优化之路- http://blog.csdn.net/yaoyu/article/details/70184539

> Atlas-手淘组件化框架的前世今生和未来的路-http://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650400348&idx=1&sn=99bc1bce932c5b9000d5b54afa2de70e
手机QQ Hybrid 的架构演进- http://mp.weixin.qq.com/s/J_7uiET3p7MfJTq5m59AUw

> 从2009年到2014年，DAU从100万增长到超过1亿，面临的问题、包括研发支撑所需要解决的事情各不相同。在用户量和业务复杂度的线性递增下，架构也进行了相应的演进。如下图所示，具体可以分为四个阶段：

• 第一阶段，手淘的前身WAP网站，业务初立、变化快，需要快速发布，采取HTML模板和单一应用，最大程度满足快速发布和修改的需要；甚至不需要改动后端的业务代码，在前面的模板上做一些修改就可以了。
• 第二阶段，DAU的快速增长，WAP/Android/iOS多个平台的业务起来了，需要在多个平台上进行快速的业务复制和业务管控，统一API网关出现。
• 第三阶段，DAU进一步增长，线上系统越来越多，业务的多样性需求更多的体现出来，基于HTML5的一整套解决方案上线，更多的HTML5和Native混合的业务形态，API网关进行进一步优化和扩展，更方便的接入方式。
• 第四阶段，当DAU达到100M的时候，全集团的业务都需要在手淘透出，API网关被部署到更多的IDC机房，如何更有体系化的进行有效的研发、接入更多业务、并进行更有效的业务监控，需要更加体系化的架构治理。

API网关

做WAP的时候没有所谓的API网关，为什么要用API网关呢？

随着应用数量的增多，每个应用分别暴露的API出口很多，修改的话逻辑很复杂，这时候应该引入一个统一的网关。

但随着DAU的增长，API网关会成为一个单点。开发团队在中间做了很多技术和架构上的努力，主要有几个关键点。一是后端接入很多应用，其实API网关只是通路，理论上不存在调用的上限，只要内存够大，包括网卡的流量够的话都可以上来。二是有必要的机制做到宽阔的调用网关。还有一点，当后端业务要经过API网关时，其实现在业界很多都是典型的RPC的模式，RPC的模式有一个绕不开的问题，就是可能要设定一些东西，这时后端服务跟API会有一定程度上的耦合。现阶段要接入服务，后端服务器随时都会变化，不可能后端服务变化的时候都对API做相应的发布，这是不现实的。所以有一套自己的RPC机制，解除了这种强类型的约束。

此外，可以在网关上附加很多功能，比如安全、审计，还有一些日志、审查等。

到了现在这个阶段，要进行异地部署，很多IDC，这样的话引入API网关很可能会带来问题。包括今年的双11或者是双12，要在多个异地机房支撑手机淘宝的业务，会有很多API网关。

比如说像APP可以在中心网关上面询问，应该去哪个真正的API网关。然后中心API网关会告诉它结果，它再连接到所在地的API网关上，然后再向后端API发起调用，所有API的服务网关都受管控中心统一管控。比如说增加一些新的功能，上线一些新的API，包括一些引流、切换，这些指令都会在管理平台上向各个API网关发送。

手机端

1.Bundle

去年下半年，开发团队对整个手机淘宝的架构做了比较大的调整，如下图所示，左侧是运行时的架构分布，右侧是工程代码级别的分布。在运行的时候，其他的业务团队提供的都是一个个的业务Bundle，这是可部署的单元，包括UI、服务和标准中间件的调用代码，下面有一个总线程，负责管理和开发好统一的UI服务，包括消息服务的总线。再下面是运行容器，上面跑的的是所有的Bundle的东西，对应运行时的东西，右侧是真正在开发时候的结构。比如说聚划算，它要开发它的业务，就做一个单独的工程，然后去开发；它只用开发自己的，开发到差不多的时候，就将其代码打成一个Bundle提供过来，然后一起打包发出去。

2.WebApp

下图是现在手机淘宝上关于HTML5的整体框架图。手机淘宝上的方案大致分为两部分，中间那一部分是手机淘宝自己开发的HTML5的运行容器，它负责在上面跑各种各样的WebApp，在线上有一个统一发布管理系统，它可能对性能进行检测，包括CDN是否符合规格，HTML本身有没有异常等情况，经过这些必要的检测，包括审查之后，它统一发到CDN上。容器本身其实也会接受运行时的信息，容器接收到这两边的指令之后，它自己会做一些更新配置，也可能会装载运行，从线上系统下发新的WebApp。此外，还可以运行WebApp或者是做URL的导航拦截，甚至做一些交互。

3.PackageApp

这是今年新的建设，整个系统是基于前面整个体系来做的，称之为PackageApp。

这个跟前面最大的区别就是让用户感知不到前面同步下载的过程，大概的做法是：把HTML5以及WebApp在发版之前先做一些预知放到客户端里面，前面会做两件事情，首先按照原来的逻辑运行，其次就是在右侧的蓝图里面，它会去做一些UI的拦截，发现用户点击的icon进去之后，整个URL是符合用户规范的，它会启动检测机制去检查线上是不是有新的版本需要下载，如果有的话会启动异步更新模块，从CDN上拉取新的WebApp版本，否则会走到原来的地方，最后既不影响用户去使用WebApp，又能把自己最新的版本更新到所期望的版本，这由统一的管理平台去发布。

在方案设计之初，还思考了三个方面，首先它是标准的URL，在点击进去之后是导航的URL，对于前端工程师来说，他设计研发WebApp跟客户端或者是线上跟HTML5的网站是一致的。其次，手机淘宝自己的容器，制定了自己的规范，在底层的容器上面可以实现手淘定义的规范。第三，“不同网络、全量、差量更新”，这点很重要，在移动互联网场景下，到底要发起几条链接拉取资源，在WIFI下怎么拉取资源，其实都是不一样的。在不同网络下面，对策都不太一样。

下面是采用PackageApp后业务模块LoadTime对比图：

支撑体系

除了前面介绍的内容，比较大的电商App，还需要一个很完备的支撑体系。如果没有的话，在线上运行的情况是不可感知的。手淘在不同的维度也做了很多支撑的工具。

1.研发支撑

在研发支撑上面，像传统的Reivew代码，特别是做客户端的同学几乎都会做统一的UI库，大家会设计模板，比较典型的，会有所谓的日常预发、线上染色等等。它的集群数量跟能够进来的用户是很有限的，通过这个环境来确认所开发的代码发布到线上可能会有什么问题。一套代码经过预发之后再发布到线上去，最后有一个染色环境，比如说用户打电话反馈遇到的问题，比如说下单下不了或者是搜索无结果，这时会有一个染色集群，把用户定位到染色集群上面，对用户专门进行一些分析，现在还没有做到直接在用户机器上做调试，但是用户到了染色集群上面，整个调用的链路会剥离出来，比较好分析用户到底发生了什么事情。

2.测试支撑

App的测试很重要，除了比较常规的单元功能测试，还有很重要的像稳定性跟性能，以及自动化这些都是很重要的。像手机淘宝差不多是一个月左右的时间可能会迭代一个版本。比如说新的功能开发会不会影响到老的功能，智能化测试很重要，可能分成两部分，一部分是线上所有的API，包括业务逻辑是不是正常。另一部分是新写的代码会不会有问题，因为前面架设了统一的API网关，所以会在网关这个层面做很多自动化的调用回归，构造很多正常用户的数据去测试线上API系统的返回值，包括一些异常是不是正常，来保证线上业务逻辑的正常。在客户端这一侧，则会做很多自动脚本的回归，保障整个客户端新做的代码跟原来相比没有什么问题。另外还引入了比较多的静态代码扫描，保证不会出现低级问题。

3.运维支撑

移动App的运维支撑跟线上不太一样。除了常见的性能跟稳定性分析，还有针对App的业务监控跟舆情监控。舆情监控这个应该是移动App所特有的环节，大家通过市场去分发，很多用户会发评论，iOS特别明显，有人说好，有人说不好，安卓更复杂，特别是国内有大大小小非常多的应用市场，不一而足。所以怎么对舆情做一个有效的监控，既能通过舆情监控，快速收集问题，也能做一些梳理分析，找到产品或者是性能方面的提升点。

4.发布支撑

发布支撑，其实也是在大的App上面才会出现的，针对一个人群的发布。传统的直接是发到市场上，大家都收到了。而手淘现在有很多内部灰度和外部灰度正式发布，可能有一些内测版本只发给阿里巴巴集团内部员工，这可以通过自己做的发布系统来支撑，有比较灵活的发布策略调整：可以圈定一批用户，也可以选定一个区域，甚至可以用后台数据做合理的设置给特定的版本推送特定升级的版本。

如果App发到用户手上，结果发生了致命的问题，怎么办呢？其实有两种方法修复线上的问题，第一个是直接替换Bundle，另外就是更小维度的补丁——热补丁，现在在安卓上做的比较多。

李敏还分享了一个案例，在上半年有一次大促的时候发生了一个问题，零点就要促销了，版本可能是前天刚发布给用户的，那怎么办呢？替换Bundle也可以做到，但是数据下载量非常大，而且刚发布不久，这样对用户影响比较大，所以选择了用热补丁修复，主要是类似于ClassLoader替换，用JAVA开发的应该知道，主要是用类替换的方式做的。在iOS上也有一些方案，不过还在尝试当中。

客户端监控

可以在分钟级别确定用户调用某个操作的成功次数、失败次数和失败率，实现对业务可用性的监控。

舆情平台

舆情平台是移动App所独有的。要获取信息，会从用户手机淘宝自己填的反馈，利用市场和微博，实时抓取，然后把内容聚合起来，进行热门词归类，筛选出一些热门的标签话题做一些智能分类，分类之后大致知道到底是支付、详情、退款出现了什么问题，确定问题的重点之后，可以直接联系用户，甚至去跟踪用户，根据这些问题去修复线上的紧急问题或者是改善产品，这就是在线上实际使用的舆情平台。通过热门词的分类排名，就可以知道某一个版本在某一个阶段最重要的问题是什么，还扩展了用户集中反馈。

比如举办一个抢红包的活动，这个活动出现了什么问题，大量的用户重复反馈这个问题，就可以把热门的话题聚集起来。另外还可以通过舆情平台确定某个技术的改造是否成功。

舆情平台早期主要用于收集一些信息，后来发现把舆情收集起来做一些大数据分析，可以得出很多自动化的结论，甚至可以验证研发的结果是好是坏。

----------------------------

 

手机淘宝性能优化

前言

 

为了满足不同用户的多样性购物需求，过去两年里手淘的业务不断膨胀，已经从单一的购物工具成为了购物内容平台。在手淘业务快速增长的同时，也带来一些副作用，很多操作环节和页面因为承载功能太多，展示的速度变慢，用户等待时间变长。性能优化势在必行。 

我们根据手机淘宝用户的购物操作流程，对主链路进行了划分，分为启动，首页加载，搜索，购物车，下单，支付环节，订单查看等七个环节，每个步骤和模块都做到监控，以量化数据为指导来进行优化。

下面着重就启动，首页，购物车三个业务环节和网络调优，图片下载两个基础能力优化，优化使用的工具来介绍方案。 

一.启动优化

我们通过线下分析工具,线上灰度数据和代码review，发现启动慢主要有3个原因：1)引入了许多提前的初始化;2)在启动阶段主线程，存在耗时的非必要阻塞操作;3)部分主线程的锁操作，导致主线程wait时间较多。

由此制定出优化的方案：

1)启动无网+缓存

执行严格的无网策略，从用户点击图标到首页第一次展示整个过程没有网络交互，所有数据都是缓存或预置数据的方式来获取。这是因为网络IO耗时都比较长，通过将启动阶段的配置信息拉取和首页运营数据的拉取等网络IO后移，减少了时间开销。

 2)Task分级与异步化

我们将启动中的所有task进行梳理和分级，根据级别来调整执行对应task的时机： 

一级:block启动的task，比如基础sdk的初始化，首页页面的创建等。 

二级:可延迟到首页加载成功后再执行的task，比如自动登录，微淘状态拉取，消息数拉取，配置信息拉取，运营数据拉取等操作 。

只有一级task在启动时执行，二级task延迟到启动完成后串行执行，一级task必须没有锁操作，保证主线程不会被阻塞。

 3)懒加载

优化之前在启动过程中有很多业务的初始化操作，现在我们都采用懒加载策略，真正使用时再进行初始化加载，同时懒加载机制可以结合缓存或预置数据的方式来达到更好的效果。

 比如在手淘的五个tab中，在没有优化前，会在启动时将五个tab对应的页面全部创建出来，而这五个页面中，只有首页是可见的，这些页面的创建都会有一定的耗时，而且除了创建以外，可能还会有一些业务逻辑在里面，比如发送一些请求等，那就会对整个启动造成一定的性能损耗。所以在这次优化过程中，我们就使用lazy创建的方式进行优化，启动只创建可见的页面即首页，而其它几个页面，只有在用户点击对应tab时，才进行创建显示，这一个优化减少了近0.5s的耗时。 

 在上述三个主要策略的优化指导下，手淘的启动流程图变为如图1所示的结构(Android情况也类似)，从图中可以看出，在主线程中，启动阶段我们只保留了一些必要的初始化，其他一些非必要的操作都被懒加载或者异步化。通过这些策略的调整，我们达到了最开始设定的优化目标。

 

二.首页优化

作为曝光量最高的页面，快速打开，稳定可用，及时更新是三大目标。

在首页，展示的内容大致分为四类：

• 二级页面的入口，图标，标题和位置相对固定；
• 顶部的轮播图，一般为六幅图片，作为不同运营模块或活动的入口；
• 根据用户身份运算出来的推荐商品，店铺
• 顶部的消息盒子入口，带未读消息数字图标。

 

对于这四类，采用不同的处理方式：

对于1和2，进行了大量的本地cache化工作，将这些入口文字图标缓存在本地，首先展示上次cache内容，即使遇到无网的情况，首页的整体框架页面，cache过的图片和文字都能绘制出来。

本地cache内容会有一个有效时间戳，在绘制完毕后判断如果cache实际过期了，就会异步网络拉取，下载完毕后做页面刷新。

 

对于3）采用优化页面结构和层次的方法：推荐商品放在页面最下部，当用户主动滚动上滑时做拉取绘制，避免页面一次拉取数据内容过度。

 对于4）采用lazy化，即延迟处理，在首屏其他内容完成基础绘制后，才调用接口拉取未读消息数量。

 同启动步骤，首页这里也使用了任务异步化，目前主流手机都是多核处理器，部分 task 可以充分利用多核优势，放在异步线程里完成。比如首页的数据量是相对比较大的，这些数据的加载，解析，拼装都是非常耗时的操作，通过将这些耗时操作进行异步化，保证主线程的正常调度，只有等数据都准备好了，才在主线程中进行UI的渲染更新，从而保障了主线程的流畅性。

 

三.购物车优化

购物车已经成为用户的“第二收藏夹”，大量用户通过多终端（PC，手机）不断更新购物车的内容。在本地建立缓存保存数据，及时展示给用户是提升打开购物车页面的必然手段。

但购物车中的商品会根据活动，店家，单一商品数量等产生不同的优惠组合，在端A上添加或删除某一个商品，都会产生总价的复杂变化。而这个价格计算规则客户端是无法实时获取到的，由服务端计算完毕后下发。

所以这就导致购物车的价格展示不仅仅是一个简单的“单品价格*商品数量＝总价”的公式。客户端在更新时，不断要拉取到商品数量的变化，也要拉取到总价的变化。

以往是采用用户主动刷新时全量更新的方法，现在优化为差量更新，不但流量减少，更有效地提升了拉取和刷新展示的速度。 

上面从业务环节讲述了优化的方法，这里从基础服务角度来描述优化手段：

四.网络优化

我们都知道主干互联网传输消耗的时间。主要包括三部分时间：DNS查找、TCP/TLS握手、数据传输。如何降低这三部分的耗时是网优的重要手段：

 1)IP直连:

实现方式是HTTP DNS。在启动完成后时发送一次HTTP请求获取一组手机淘宝中使用的域名IP映射表，并缓存在本地。每次发起连接时，直接在网络层使用IP代替域名直连。这种方式除了节省DNS时间，也可以规避掉公网DNS Server被攻击导致的手淘服务瘫痪，这种情况2013年曾经发生过一次，手淘未受任何影响。

 2)建立长连接：通过spdy实现, 减少TCP/TLS握手，降低建立连接成本。对于从CDN下载图片速度帮助很大。

 3) 域名收敛：收敛域名至公司的主力CDN域名。

尽量将请求集中在少数几个域名下，以提高长连接的复用率.

 4)TCP调优：

无线网络特点是丢包率高、RT长，针对此特点可以针对性的TCP调优。

实施的方案：

调大初始拥塞控制窗口、关闭空闲slow-start、动态MSS、关闭TCP DF、去掉TCP时间戳

 5)报文缩减：逐步由json协议格式向类PB协议转换。

 

五．图片方面优化

图片是电商app使用场景中最多的元素，如何快速节省流量的下载和渲染图片是电商app都非常关注的。除了上面网络优化提的长连接，域名收敛等几点之外，手淘还建立图片的分级机制。

按分辨率，质量，锐化，格式四个纬度，对同一张图片生成了不同组合的衍生文件。

设置了一系列匹配规则，针对不同屏幕，不同机型处理能力，不同网络环境，配置出合适当前情况的图片大小质量，保证图片大小既节省又保证用户视觉体验。

其中一个经验是当锐化程度高时，即使图片质量较低，图片色彩清晰度也都能让用户满意。

 

六．工欲善其事必先利其器

在整个手淘的启动优化过程中，系统的工具帮了我们很大的忙，Android的主要是自带的 TraceView工具，IOS 主要是Instruments自带的Time Profiler，System Trace等工具，它们都是数据采集和分析工具，主要用于分析应用程序中的hotspot，都非常强大。工具的具体使用方法不在本文论述范围内，但是这些工具都提供了程序中的所有线程使用状况，而且线程中的每一次的调用都可以看到具体的堆栈信息、耗时等详细信息。通过对这些调用的分析，就可以找到启动过程中相对耗时的调用。分析出具体的瓶颈点以后，就可以有针对性地进行具体优化了。

比如 手淘Android启动阶段以前有一个加密存储的模块，它会调用系统的SecretKeyFactory.getInstance()方法来生成加密的 key，我们是通过 TraceView 才发现这个函数调用会耗时300ms 以上，通过 TraceView看里面的调用堆栈发现它里面存在锁操作，所以比较耗时，找到这个瓶颈点之后，手淘Android调研了多种加密存储方式，最后换了一种比较轻量的加密存储模块，优化了该瓶颈点。

 

最后总结七大原则：

1.善用性能分析工具，建立监控体系

2.做好网络基础建设和网络调优

3.离线化，本地缓存

4.懒加载

5.任务分级，合理并行

6.在主线程移除多余操作

7.简化合并复杂视图

引用：https://yq.aliyun.com/articles/53?commentId=15

Android淘宝客户端用户体验优化实践：http://www.infoq.com/cn/presentations/android-taobao-clients-user-experience-practice

--------------------------------

携程移动端架构演进与优化之路-http://geek.csdn.net/news/detail/108167
  多样性架构探索: 实现了无线服务端基于API Gateway的架构框架、客户端的模块化开发、测试与部署，支持运行期间的模块实时加载、按需Lazyloding、Remote加载，从而实现模块级动态升级以及代码级热修复，并 
且逐步推动数百人的客户端研发团队由不堪重负、效率低下的大版本大火车开发模式向模块间独立迭代、发布轻量级的开发方向演进。
  同时在架构探索期间，携程做了App相关的很多性能优化，比如底层网络通道治理的优化、应用层插件容器加载启动速度以及存的优化、业务中间件Hybrid的优化等等，逐步保证随着业务的不断的迭代，能保证用户的比较好的优化体验。
  早期App服务端架构使用了传统的PC无线开发架构，即在PC Web应用基础上增加一些无线端的REST接口直接供给App访问，没有考虑架构的扩展性、 灵活性、安全型等因素。
  急需解决的有三个问题：耦合、重复造轮子、系统稳定性.
  提供统一的无线网关，所有App调用指向此网关，网关包括通用层、接口路由层、适配层。通用层包括通讯协议适配、数据封装、安全、监控、日志、隔离、熔断、限流、反爬这些系统级功能，每个接口调用都需要同样逻辑，这些功能统一由网关前置处理，避免重复开发。具体实现时，每个通用处理逻辑封装成拦截器，遵循统一的过滤接口，并且做到可配置，网关依次调用这些拦截器，这样可以支持通用逻辑的灵活扩展。
  无线API Gateway应该目前很多公司都有自己的实现，目前市场上也提供了很多开源项目Zuul、Archaius、Hystrix、Eureka等帮助我们去实现自己的Gatway。
  其API Gateway具有的几个核心职能：路由、隔离、限流、熔断、反爬、监控报警.携程App服务端架构通过一系列的拆分和整合，既优化了公司整体应用架构，又为App做大做强奠定良好基础，其带来的好处是全方面的，增加了架构的可扩展性、健壮性、稳定性、灵活性，并且提高了团队的开发效率和团队长远的收益.
  基于此背景下，携程的插件化应运而生，其实现原理是通过系统的ClassLoader动态加载类，通过系统的AssetManager去动态加载插件的资源，同时通过修改aapt的源码去替换系统的Appt解决各BU资源之间冲突的问题。关键是各BU原有的代码和现有的开发模式都不需要额外的去改动从而增加额外的开发成本，插件化的思想即一切皆Bundle组件的思想，每个Bundle有自己的版本号，通过BundleManager 去管理Bundle的升级。
  目前携程正在推进和已经进行的技术架构：
1.推出了基于ReactNative的Moles框架；
2.基于FreelLine和LayoutCast的热部署方案；
3.Bundle的更加轻量级组件化、服务化；
4.基于MVP和AOP的框架设计。

滴滴国际化项目 Android 端演进-http://geek.csdn.net/news/detail/129998
放弃原来造成耦合严重的 EventBus，改用原生的通信方式，包括原生 (startActivityForResult) 


、内部广播、回调等。