<p><strong>记：天猫App长大了，已经长成了流量以千万计规模的App，当下至少有10个团队在直接维护天猫App。在App长大，团队扩充的过程中解耦是一个永恒的话题，而界面解耦又是App架构的重中之重。</strong></p>    <p>统跳协议是天猫App统一跳转协议，主要负责天猫App界面之间的串联，也就是界面跳转服务。Rewrite引擎是与之配合的一套URL重写引擎，可以通过配置实现重写规则动态化。</p>    <h2>历史上的今天</h2>    <p>统跳协议的前身是一套叫做internal的协议，internal要重点解决的问题是在WebView和推送通知中如何跳转到指定的界面，进一步在任何动态场景下如何跳转到指定界面。在这样的思路下，internal中定义了多种协议格式，如：<br> <code>tmall://tmallclient/?{"action":""}</code><br> <code>internal:url=</code><br> <code>link:url=</code><br> <code>tmall://mobile.tmall.com/page/</code><br> 几乎每一种场景都有一种格式的协议与之对应。在具体操作过程中这些协议都以URL表现出来。不难看出，这套协议最大的问题在于协议格式异构化严重，且不符合W3C的URL标准。随着App规模的扩大，场景日趋复杂，界面越来越多，这套协议的弊端也日益显露。</p>    <p>而在天猫App开始从百万级冲击千万级的时候，我们认识到一套格式统一，符合标准，规则简洁的协议非常必要。这套协议的任务也绝不是解决固定场景跳转，而是完全托管整个App的跳转工作，从而实现全App界面解耦和跳转动态化。因此，我们重新设计了界面协议，形成了当下这套规范——<strong>统跳协议</strong>。配合统跳协议，为了解决更多细节问题和跨平台问题，我们还设计了<strong>Rewrite引擎</strong>与之配合。</p>    <h2>统跳协议</h2>    <p>统跳协议设计之初就保留了很强的可扩展性，为接下来更丰富的场景预留了能力。上文讲到了统跳协议在界面跳转中作用，而事实上界面跳转仅仅是这套方案的一个典型场景，一个最佳实践。界面跳转在统跳协议的框架中被认为成一个服务，而跳转到哪一个界面则是由服务内部实现决定的。</p>    <p><img alt="解耦神器 —— 统跳协议和Rewrite引擎" src="https://simg.open-open.com/show/6a1800e7a1f7b6215dfa850d027d8447.png"></p>    <h3>注册一个服务</h3>    <p>服务通过声明URL的方式注册到统跳协议中，这个声明发生在服务所属模块内部的一个配置文件中，而这个配置文件被注册到统跳协议里。也就是说，整个App中的每一个模块都要注册一个配置文件到统跳协议，统跳协议在初始化过程中会遍历配置文件列表，逐一加载这些模块配置，根据配置信息把一个一个的模块服务注册到协议中。</p>    <p><img alt="解耦神器 —— 统跳协议和Rewrite引擎" src="https://simg.open-open.com/show/b071b1e37f3aaac8c5d596f7cb59f05e.png"></p>    <p>统跳协议要求调用服务的URL必须是符合W3C URL标准的，服务注册使用的URL只能包括host和path两部分，其中host是必须的，path则可选。当统跳协议接收一个跳转请求的URL后，先根据该URL的host和path两部分作为条件查找已注册的服务，再初始化对应服务，把URL交给服务实例执行后续操作。</p>    <h3>如何实现服务</h3>    <p>统跳协议声明了一个服务接口，这个接口中只有一个方法，服务必须由该接口实现而来。每一个服务可以通过实现接口中声明的方法，使用参数中传递来的完整URL，参数列表和调用发起者指针，执行具体业务逻辑。</p>    <p>例如分享服务，以iOS为例：实现了<code>TMShareUrlHandler</code>服务。</p>    <pre>  <code>@interface TMShareUrlHandler : NSObject<AliAppURLHandler>  @end  </code></pre>    <pre>  <code>@implementation TMShareUrlHandler  #pragma mark - URL调用分享组件  - (id)handleUrl:(NSURL *)url withTarget:(id)target withParams:(id)params  {  // 省略代码详情      return nil;  }  @end  </code></pre>    <p>在分享模块的配置文件中声明该服务的URL为<code>sharekit.tm/doShare</code>。</p>    <p>这份配置文件在分享模块里：</p>    <p><img alt="解耦神器 —— 统跳协议和Rewrite引擎" src="https://simg.open-open.com/show/3685d4fde4426f977aad666ca40bbca1.png"></p>    <p>分享模块的配置文件<code>sharekit_bundle.plist</code>也注册到统跳协议中。</p>    <p>这份配置文件在统跳协议模块里：</p>    <p><img alt="解耦神器 —— 统跳协议和Rewrite引擎" src="https://simg.open-open.com/show/226c127c2b77f9b59462cfe906831526.png"></p>    <h3>统跳协议如何处理界面跳转</h3>    <p>界面跳转是统跳协议的初衷，也是统跳协议最重要的任务。因此在统跳协议服务注册机制中，为界面服务注册做了更精细的定制开发。</p>    <p>上文提到跳转服务是一个单一服务，而界面则成百上千，所以在界面注册和服务注册中出现了冲突。本着降低开发成本的原则，我们又希望把同一个模块中界面注册和服务注册放在一起。所以在统跳协议中做了如下订制：</p>    <ul>     <li> <p>默认注册跳转服务</p> <p>跳转服务是默认存在的，在统跳协议初始化过程中这个服务就已经初始化了。</p> </li>     <li> <p>给界面注册提供特殊的标记</p> <p>上文中可以看到在注册分享服务的配置中<code>object</code>字段是服务的类名，若界面注册也按照这个规则，那么界面的类就会被认为成一个服务，在调用过程中必然会出现错误。因此我们约定，界面注册需要在类名前加<code>#</code>标示。</p> <p><img alt="解耦神器 —— 统跳协议和Rewrite引擎" src="https://simg.open-open.com/show/9350fec2d33043ad15265d7c04ca5792.png"></p> </li>    </ul>    <p>如此一来，在统跳协议初始化过程中，默认加载跳转服务。当调用发生，解析URL查找到的对应对象带有<code>#</code>，则认为这是一个界面，则初始化这个对象，但不对其调用处理URL的方法，而是托管给已注册的跳转服务。跳转服务则根据URL和初始化的界面对象执行跳转服务。</p>    <h2>Rewrite</h2>    <p>Rewrite引擎的思路来源于Web容器中的Rewrite机制，主要解决天猫App中URL平台展现一致性的问题。</p>    <p>天猫App中所有界面都是通过URL来标示的，然而标示Native界面的URL全部都建立在Native规范下，无法和其他平台对应起来，而Rewrite引擎通过重写URL来实现平台一致性。</p>    <p>例如：商品详情页面在PC Web的URL是<code>https://detail.tmall.com/item.htm</code>，在Mobile Web则是<code>https://detail.m.tmall.com/item.htm</code>，在Native声明的是<code>tmall://page.tm/itemDetail</code>。三者各不相同。PC Web和Mobile Web可以通过判断浏览器的UA识别环境，从而通过跳转实现一致性，也就是说在手机浏览器访问PC Web的URL，会通过一次302转到Mobile Web的URL。而Native App的环境具有一定的特殊性，Native界面则无法通过类似302这样的跳转来实现无感知切换，而Rewrite引擎就是来解决这个问题的。首先，无论是Native还是Web，在天猫App中他们两两之间的跳转都被统跳协议托管，而统跳协议在执行跳转操作之前会把原始URL放入Rewrite引擎中做一次Rewrite操作。这样一来，Rewrite引擎就根据配置规则，把原始URL转换成适用于天猫App的目标URL，实现了URL表现平台一致性。</p>    <h3>原理</h3>    <p>Rewrite引擎的原理非常简单，模拟Web容器（Apache/Nginx等）的Rewrite配置，根据配置把传入的原始URL进行重写，返回重写后的目标URL，交给统跳协议处理。</p>    <p>配置是通过正则表达式描述的Rewrite规则列表，这份列表通过猫客的配置中心实现动态更新。</p>    <h3>Rewrite规则</h3>    <ul>     <li>每条Rewrite规则中有三个字段：模式串，转换串和标记位      <ul>       <li>模式串：即正则表达式，用于匹配原始URL</li>       <li>转换串：即需要被转换成目标URL的描述</li>       <li>标记位：以西文逗号分隔的<code>标记位</code>，包括表示匹配则终止的<code>l</code>，需要进行店铺域名查询的<code>s</code>等</li>      </ul> </li>     <li>Rewrite规则按行整理，并自上而下按顺序逐行匹配</li>    </ul>    <h3>转换模板中的保留字</h3>    <ul>     <li> <p>变量</p> <p>变量由变量标示符和变量名组合而成，如：$0，$#1，query，$#fragment等。变量被用在转换串中描述转换后的目标URL中的值。</p>      <ul>       <li>变量标示符：$，$$和$#        <ul>         <li>$：原变量的值</li>         <li>$$：对原变量做URL Encode</li>         <li>$#：自动识别编码，对原变量做URL Decode</li>         <li>$$$：自动识别编码，对原变量做URL Decode，再以UTF8做URL Encode</li>        </ul> </li>       <li>变量名：数字（从0开始），枚举（scheme，host，port，path，query，fragment，shopid）        <ul>         <li>数字：0 - 表示整个URL，1~n - 表示正则中使用圆括号取出的参数</li>         <li>枚举：scheme，host，port，path，query，fragment表示标准URL中的相应部分；shopid表示对个性店铺域名查询后得到的shopid</li>        </ul> </li>      </ul> </li>     <li> <p>标记位</p> <p>即上述规则中的标记位</p> </li>    </ul>    <h3>Rewrite引擎查询流程</h3>    <ol>     <li>取出规则列表中的首条规则</li>     <li>以模式串为模板对原始URL做匹配，并得到模式串定义的参数表</li>     <li>若匹配成功则继续进行，否则进入下一条规则，从<strong>2</strong>开始进行下一轮匹配</li>     <li>查看该条规则是否包含<code>s</code>标记位，若包含，则使用原始串做一次个性域名的查询</li>     <li>使用1的结果和重写串对原始URL进行重写操作，得到目标URL</li>     <li>查看该条规则是否包含<code>l</code>标记位：      <ul>       <li>若包含，则结束匹配，返回目标URL</li>       <li>若不包含，则把目标URL赋值给原始URL，并进入下一条规则，从<strong>2</strong>开始下一轮匹配</li>      </ul> </li>     <li>直到最后一条规则结束，返回目标URL</li>    </ol>    <h3>举例</h3>    <p>上述提到过商品详情页的例子，在Rewrite配置中就体现为：</p>    <table>     <thead>      <tr>       <th>模式串</th>       <th>转换串</th>       <th>标记位</th>      </tr>     </thead>     <tbody>      <tr>       <td>^(?:https?:)?\/\/detail(?:.m)?.tmall.com\/?item.htm\?(.*)</td>       <td>tmall://page.tm/itemDetail?$1</td>       <td>l</td>      </tr>     </tbody>    </table>    <p>在这条规则的保护下，PC Web和Mobile Web下的商品详情URL在天猫App中都会被拦截到Native商品详情页面，可以带来最好的用户体验。也就是说，在日常的运营工作中，不需要关注一个商品在某个平台内部需要以什么样的URL来投放，只需要投放一个主要的URL格式。这个URL在天猫App内部会被Rewrite引擎重写为Native界面声明的URL，进行展示。</p>    <h2>统跳和Rewrite在双11中的表现</h2>    <p>统跳协议和Rewrite引擎在刚刚过去的双11期间，在全链路界面降级方案和会场上下线中发挥了重要作用。</p>    <h3>全链路界面降级</h3>    <p>上文中提到了天猫App中全部界面都声明了自己的一个<code>tmall://</code>协议的Native URL，但在业务逻辑上使用的不是这个Native URL，而是和Web保持一直的<code>http://</code>协议的URL，在统跳协议中会调用Rewrite引擎对这个<code>http://</code> URL进行重写后再做展现。</p>    <p>为了保证整个天猫App的可用性，我们在配置列表中预先定义了一系列Rewrite规则，用于拦截这些URL。一旦发现Native逻辑出现异常，将快速上线预定义的规则，从而在Rewrite引擎把<code>http://</code> URL重写成Native URL之前拦截，直接返回<code>http://</code> URL，实现Native界面到Mobile Web界面的降级。</p>    <h3>Native会场上下线</h3>    <p>双11会场是双11活动期间曝光率最高的页面，也是对体验要求最高的界面。因此，我们在天猫App双11版本中对重要会场做了Native化，以提升用户体验。而Native会场展现依赖会场数据，且开启时间严格控制在双11当日的24小时内。</p>    <p>在这样的要求下，我们配置了<code>http://</code>协议的会场URL到Native会场URL的Rewrite规则，并在双11开始时上线，结束时下线，实现了双11当日天猫App的会场Native化。</p>    <h2>结语</h2>    <p>统跳协议在设计过程中预留了很好的扩展能力，所以在界面解耦之外还承担了更多的服务调用功能。Rewrite引擎为实现平台一致性而设计，而在实际应用过程中又挖掘出更多的场景和功能。</p>    <p>在统跳协议和Rewrite引擎接下来的发展过程中，将更注重Android和iOS双平台的高度一致性，并尝试开放更多API，让所有人一起挖掘这套方案的潜力。</p>    <p>来源：http://pingguohe.net/2015/11/24/Navigator-and-Rewrite.html</p>