前端 | 边际效应 - 杨文博的个人博客

AI Coding 生成“谁是卧底”发牌器

最近我 5 岁的女儿痴迷“谁是卧底”游戏，但是家里人本来就不多，分出来专门的法官角色影响游戏体验。我在微信里尝试了好几个小程序，总有这样那样的问题，要么必须多手机联网发牌，要么让你注册，要么广告太多。

后来总算选了一个凑合能用的，用了几次发现也有问题。一是很多词汇 5 岁的小朋友不认识，要选很多次；二是词汇量太小，经常会刷到重复题；三是经常莫名原因卡死。

我想了想，这么简单的程序，不如找 AI 写一个。我就写了一个 prompt：

请为我写一个玩“谁是卧底”游戏发牌的程序，要求如下：

1. 首先为游戏生成一千个适合谁是卧底的游戏词语对，例如最好是小学生也可以理解的名词，直接写入到 js 代码中，游戏时随机调用一个词语对进行游戏；

2. 游戏开始前可自定义本轮游戏玩家人数和卧底人数，默认的玩家人数为4，默认的卧底人数为1；以玩家1，玩家2，玩家3称呼玩家；

3. 点击游戏开始以后，出现玩家1的界面，但这时词语是隐藏的，只有点击查看词语，才显示词语；玩家1点击下一个后，出现玩家2的界面，但这时词语是隐藏的，只有点击查看词语，才显示词语，以此类推；即显示每个玩家的词语界面时，要先隐藏，只有点击查看才显示；

4. 大家都查看完自己词语以后，出现一个列表页面，列表页面支持每个人查看自己忘记的词语，或者查验身份；

5. 查验身份时，如果玩家身份是平民，那提示游戏继续；如果所有玩家的卧底都被找出，则游戏结束；

6. 在点击查看词语后，在下一位按钮下增加重新开始游戏按钮，以便用户在发现不认识词语时，快速重新开始。

Grok

生成代码显然没遵循 1000 个候选词对的要求，只生成了 10 个，也不支持预览。放弃。

ChatGPT

使用画布，生成代码显然没遵循 1000 个候选词对的要求，只生成了 10 个，支持预览，但预览失败。放弃。

豆包

使用 AI 编程，候选词对生成了大几百，可以看到代码生成过程，可以预览，但是最后的玩家列表“忘词”功能，两次都没调出来。放弃。

秒哒

生成过程中完全看不到代码变化，只能死等。第一版生成从视觉效果上打败了豆包，第一眼印象完成度较高。支持预览，发现功能的最大漏洞在词语的隐藏上，第一个玩家隐藏，第二个玩家直接会显示。这个 bug 用了 3 次会话纠正了过来。后面又用了几轮会话优化一些效果，总共不到 10 轮会话，达到了一个较为满意的程度。

预览如下，也可以访问：https://app-4zsgkyvnt7uq.appmiaoda.com/ 直接体验。

因为这个小程序完全是前端实现的，即使生成过程中看不到源代码，发布以后也可以通过浏览器调试看源码。仔细检查了一下生成的词对，也没有到 1000 个，也有一些不符合我要求的，比如截图里的“番石榴”，5 岁孩子大概率不知道怎么描述。但是凑合能用吧。

从这轮 PK 来看，秒哒赢了。假如让我自己来写的话，写成豆包那样可能需要 1 天，写成秒哒这样可能需要 3 天。因为做过个人建站的就知道，功能目标是确定的，但 UI 的调整是没有尽头的，这次秒哒在这块做得算不错了。

从这次体验来看，针对特定场景进行的 AI Coding 优化，可能还真有一些空间。

1 背景

APP 开发过程中，为了追求开发效率、更新成本、性能和交互体验的平衡，经常会采取 Hybrid 的 APP 端架构。用基于 HTML5 的 WEB APP 实现易变的业务部分，用原生代码实现对效率、权限、数据交换等有要求的功能部分，然后通过 JS Bridge 打通两者，实现 JS 与原生代码的相互调用，完成整个产品功能。

但谈到 APP 开发，大家都知道至少存在两个平台，那就是 Android 和 iOS。这两个系统采取不同的原生开发语言，也有不同的 Webview 浏览器环境。但 WEB APP 是跨平台的，所以跨浏览器的调用总归需要在一个层面上得到统一，这样才不需要专门针对两个平台开发不同的 WEB APP。

下面先对在目前的技术框架下有哪些 JS - NA 相互调用方式做一下综合介绍，然后基于上述技术提出几种跨平台 JS Bridge API 统一设计思路，最后扩展讨论下 JS Bridge 设计中的一些值得注意的点。

2 在原生代码中调用 JS 代码

2.1 Android Platform

loadUrl 方法

Android Webview 的 loadUrl 接口，可以直接在 Java 代码中执行 Javascript 脚本。在 API 23（Android 6.0）及之前，这里的 Javascript 脚本能够获取当前加载页面的变量，甚至执行当前加载页面里定义好的函数。也就是说，传入的 JS 脚本是在当前加载页面的上下文中执行的。

    // Javascript: 在网页内定义一个函数，显示一个消息，返回一个内容
    function propose(msg) {
      alert(msg);
      return "Yes!";
    }

    // Java: 执行当前加载页面中定义好的一个函数 propose()
    webView.loadUrl("javascript:propose('Will you merry me?');");

可惜的是，这种方法：

只能执行 JS，无法获取返回结果，需要用其它的方式（下文介绍）获取返回结果；
而且会触发一次页面的刷新，可能会导致焦点丢失，软键盘消失之类的问题；
在 Android 7.0 以后，存在兼容性问题；

evaluateJavascript 方法

不过，如果 APP 适配的版本在 API 19（Android 4.4）以后，也可以使用 Webview 的 evaluateJavascript 接口。这也是更为推荐的做法，因为避免了上面 loadUrl 的问题。

    // Java: 执行当前加载页面中定义好的一个函数 propose()
    webView.evaluateJavascript（"propose('Will you merry me?')", new ValueCallback() {
      @Override
      public void onReceiveValue(String answer) {
        // 拿到 answer 是 "Yes!"
      }
    });

间接方法：Web Event 分发

这种方法很少有人提到，因为它是一种间接的调用方法。Web Event 接口提供了一种在 DOM 里进行广播的机制，那也就意味着原生代码可以不知晓 JS 的函数名，而只是广播一个事件，由页面内的 JS 决定是否处理这个 Event。这能够避免 JS 代码执行的异常，更常用于原生代码主动通知页面某些信息更新的场景。

    // Javascript: 在网页内定义一个函数，显示一个消息，返回一个内容
    function propose(e) {
      alert(e.msg);
      return "Yes!";
    }
    // 注册 WebDomEvent handler
    window.addEventListener("propose_event", propose);

    // Java: 
    webView.evaluateJavascript（"var e=new Event('propose_event'); e.msg='Will you merry me?'; window.dispatchEvent(e);", new ValueCallback() {
      @Override
      public void onReceiveValue(String answer) {
        // nothing
      }
    });

这种方法也存在无法获取返回结果的问题，也需要用其它的方式（下文介绍）获取返回结果。不过在使用到 Event 通知的场景下，我们一般也不需要返回。

2.2 iOS Platform

讲到 iOS，必须提到两个不同的 WebView，一个是过时但广泛使用的 UIWebView，另一个是建议且逐渐流行的 WKWebView。

UIWebView: stringByEvaluatingJavaScriptFromString 方法

UIWebView 提供了 stringByEvaluatingJavaScriptFromString 接口，并且能够获得返回结果。

    // OC: 执行当前加载页面中定义好的一个函数 propose()
    [_webView stringByEvaluatingJavaScriptFromString:@"propose('Will you merry me?')"];

这个方法的主要问题在于，它是一个同步的方法。它可能会阻塞 UI 线程，不太适合执行复杂的调用。

UIWebView: JavaScriptCore

在 iOS 7 之后，苹果提供了一个获取 UIWebView 中 JSContext 的方法，直接将 JS 执行环境暴露给原生代码。这样就可以在原生代码中任意执行 JS 代码了。同时，这个接口也可以用于 JS 调用原生代码的能力，下文中会介绍。

    // OC: 获取 JSContext 
    JSContext *context = [_webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]
    [context evaluateScript:@"propose('Will you merry me?')"];

WKWebView: evaluateJavaScript 方法

可以看到，JavaScriptCore 使用起来极其方便，但在 WKWebView 中我们享受不到这种方便了。因为 WKWebView 的页面渲染是在独立的进程中，在当前进程无法直接拿到 JSContext。

不过 WKWebView 提供了一个更好的 evaluateJavaScript 接口，可以传入一个回调函数，实现了 JS 的异步调用。

    // OC: 执行当前加载页面中定义好的一个函数 propose() 
    [_webView evaluateJavaScript:@"propose('Will you merry me?')" completionHandler:^(id _Nullable result, NSError * _Nullable error) {
      // 拿到 result 是 "Yes!"， error 是 nil
    }];

可以看到，evaluateJavaScript 接口与上文 Android evaluateJavaScript 接口极为类似。

间接方法：Web Event 分发

当然，由于 Event 接口是 WEB 标准，iOS 上也可以同样进行 Event 分发。场景和作用请看上文，不再赘述，简单代码如下：

    // Javascript: 在网页内定义一个函数，显示一个消息，返回一个内容
    function propose(e) {
      alert(e.msg);
      return "Yes!";
    }
    // 注册 WebDomEvent handler
    window.addEventListener("propose_event", propose);

    // OC: 执行当前加载页面中定义好的一个函数 propose() 
    [_webView evaluateJavaScript:@"var e=new Event('propose_event'); e.msg='Will you merry me?'; window.dispatchEvent(e);" completionHandler:^(id _Nullable result, NSError * _Nullable error) {
      // nothing
    }];

3 在 JS 代码中调用原生代码

3.1 Android Platform

addJavascriptInterface 方法

Android 从 API 1 就开始提供了 addJavascriptInterface 接口，用这个接口可以很方便地把原生的方法注入到 JS 上下文中，可以说比 iOS 做得好很多。

    // Java: 定义一个类，提供一个接口，返回一个内容
    class NativeApis {
      @JavascriptInterface
      public String propose(String msg) {
        return "Yes!";
      }
    }
    webView.addJavascriptInterface(new NativeApis(), "Bridge");

    // Javascript: 执行一个 native 的方法
    alert(window.Bridge.propose("Will you merry me?"));

但问题在于在 API 17 (Android 4.2) 之前这个方法存在安全漏洞，攻击者可以执行任意代码。在 API 17 及以后，通过显式地给出 @JavascriptInterface 限定暴露的接口，避免了安全漏洞。但在 API 17 以前，不建议使用此方法，可以考虑下面的 work around。

URL 拦截：shouldOverrideUrlLoading

这是一种曲线救国的方式，那就是通过加载非标准 Scheme（非 http/s, 非 ftp）的 URL，用一个非法（或者叫自定义）的 URL 传递参数。当页面中的 Javascript 动态插入一个 iframe 元素时，iframe 的 url 会被 WebView 通过 shouldOverrideUrlLoading 方法传给 WebViewClient 判断是否需要加载该 URL。在这里可以拦截自定义的 URL Scheme，通过 encode 到 URL 中的信息传递参数。

    // Java: 解析要加载的 URL，如果是自定义 scheme，调用相关的函数
    class MyWebViewClient extends WebViewClient {
      @Override
      public boolean shouldOverrideUrlLoading(WebView view, String url) {
        if (url.startsWith("bridge://")) {
          // 解析 // 后面的 action 和参数，调用相关的函数
        }
        return true;
      }
    }
    webView.setWebViewClient(new MyWebViewClient());

    // Javascript: 用不可见 iframe 打开一个自定义 URL，参数需要 urlencode
    bridgeFrame = document.createElement('iframe');
    bridgeFrame.style.display = 'none';
    bridgeFrame.src = 'bridge://propose?msg=Will%20you%20merry%20me%3F';
    document.documentElement.appendChild(bridgeFrame);

URL 拦截的问题也是无法直接拿到原生代码的返回结果，需要用 URL 字符串参数传入一个回调函数，然后用上文讲到的原生代码调用 JS 的方式回调传回结果。

弹出框拦截

Android Webview 可以定义一些接口，重载 onJsAlert()、onJsConfirm()、onJsPrompt() 这些回调方法。当 JS 控制弹出框时，这些回调会被调用，进而可以通过约定的特殊内容格式判断是真正的弹出框，还是 JS 到 NA 的调用。由于 onJsPrompt 可以返回结果，所以更合适一些。

    // Java: 重载 onJsPrompt 方法，提取 prompt 内容判断是否需要拦截
    class MyWebViewClient extends WebChromeClient {
      @Override
      public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {
        if (message.startsWith("bridge://")) {
          // 解析 // 后面的 action 和参数，调用相关的函数
          result.confirm("Yes!");
        }
        return true;
      }
    }
    webView.setWebViewClient(new MyWebViewClient());

    // Javascript: 调用 prompt 弹框，使用特定内容格式以利于拦截
    alert(window.prompt('bridge://propose?msg=Will%20you%20merry%20me%3F'));

Local Server

APP 可以在手机的本地地址 127.0.0.1 上启动一个 HTTP/WebSocket 服务，浏览器内的 JS 可以通过本地回环网络连接到这个服务，把 APP 视为一个服务端，进行正常的 B/S 通信，也可以实现在 JS 中调用原生代码。

使用这种方式时，额外注意一点是要进行有效地鉴权。因为除了 APP 内的 WebView，手机内其它的 APP 也可以访问这个服务，很可能会造成一些安全问题。所以可能需要 NA 在加载 Webview 的时候，通过 Cookie/URL参数/JS 上下文环境传入合法的 Token，才能保证其安全性。

还有一点是，如果不幸出现了端口冲突，需要有办法去解决。

3.2 iOS Platform

URL 拦截：shouldStartLoadWithRequest

UIWebView 原生并没有提供任何可以在 JS 代码中调用 NA 方法的 API，但 UIWebView 也可以通过与 Android 相同的方式进行 URL 拦截，进而间接实现 JS 到 NA 的传参。

    // UIWebView
    - (BOOL)webView:(UIWebView *)webView 
    shouldStartLoadWithRequest:(NSURLRequest *)request 
     navigationType:(UIWebViewNavigationType)navigationType;

这个方式在 WKWebView 上，依然有效，只是叫做 decidePolicyForNavigationAction

    - (void)webView:(WKWebView *)webView 
    decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction 
    decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;

UIWebview: JavaScriptCore

大概苹果官方也觉得这种方式太 ugly，所以后来在 iOS 7 以后，提供了一个好一些的接口，就是 JavaScriptCore。在页面加载完后，可以获取当前加载页面的 JavaScript 上下文执行环境 JSContext。然后可以把一些原生方法注入到 JSConext 中，这样页面内的 JS 就可以直接调用到这些注入的方法了。

    // OC: 获取 JSContext，将原生方法注入进去
    JSContext *context = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
    context[@"propose"] = ^(msg) {
      return @"Yes!";
    };

    // Javascript: 调用 prompt 弹框，使用特定内容格式以利于拦截
    alert(window.propose('Will you merry me?'));

WKWebView: WKScriptMessageHandler 方法

然后到了 WKWebView，JSContext 不好使了。不过 WKWebView 提供了另外一个方法，那就是 WKScriptMessageHandler。在创建一个 WKWebView 的时候，可以通过配置将一个 WKScriptMessageHandler 对象指针和 NAME 传进去。这样在加载页面中，通过 window.webkit.messageHandlers.NAME.postMessage 就可以将消息传给原生的 WKScriptMessageHandler 对象。

    // OC: 编写 Message 回调，并注册 Message Handler
    @interface Brige : NSObject 
    - (void)userContentController:(WKUserContentController *)userContentController
          didReceiveScriptMessage:(WKScriptMessage *)message {
      if ([message.name isEqualToString:@"Bridge"]) {
        // 处理 message
      }
    }
    ...
    _bridge = [[Brige alloc] init];
    [[_webView configuration].userContentController addScriptMessageHandler:_bridge name:@"Bridge"];

    // Javascript: 发消息给注入的 Message Handler
    window.webkit.messageHandlers.Bridge.postMessage("Will you merry me?");

WKScriptMessageHandler 同样也是无法直接返回结果。

WKWebView: 弹出框拦截

与 Android 类似，WKWebView 也提供了弹出框的回调函数，可以通过此类函数实现参数的传递。

    // WKUIDelegate
    - (void)webView:(WKWebView *)webView 
    runJavaScriptAlertPanelWithMessage:(NSString *)message 
    initiatedByFrame:(WKFrameInfo *)frame 
    completionHandler:(void (^)(void))completionHandler;
    
    - (void)webView:(WKWebView *)webView 
    runJavaScriptConfirmPanelWithMessage:(NSString *)message 
    initiatedByFrame:(WKFrameInfo *)frame 
    completionHandler:(void (^)(BOOL result))completionHandler;
    
    - (void)webView:(WKWebView *)webView 
    runJavaScriptTextInputPanelWithPrompt:(NSString *)prompt 
        defaultText:(NSString *)defaultText 
    initiatedByFrame:(WKFrameInfo *)frame 
    completionHandler:(void (^)(NSString *result))completionHandler;

Local Server

见上文中对 Android Local Server 调用方式的讨论。

4 notify-fetch-run 间接机制

上文中讲到的很多还是较为直接的 JS-NA 相互调用方法，其实还有一些更开脑洞的方法。比如 notify-fetch-run 机制，不需要直接传递参数或者代码，只需要传递一个信号，然后通过可以共同访问的第三方传递真正的参数，进行执行。

4.1 notify

如果仅仅把相互调用简化成一个 0/1 信号，那除了上面讲到的内容，还有太多东西可以做为信号。比如 event，比如通过远程服务器通知之类，下面讲一个比较奇葩的方法：

notify 中的奇葩：online/offline event

HTML5 中有一对标准的 event，叫做 online/offline，可以反应当前浏览器的联网状况。而 WebView 呢，可以通过 webView.setNetworkAvailable() 来控制联网状态。那也就意味着，原生代码只要控制 webView 的联网状态变化，就可以发送 0/1 信号给 JS。JS 收到 0/1 信号后，可以通过下文 JS 调用原生的方式获取原生代码要传入的内容，然后执行这些内容。

这种方式最大的问题在于，需要非常精巧地设计整个状态流转。因为传入的信号信息量非常少，而且正常情况下网络状况的变化也会触发这两个 event。

4.2 fetch

fetch 也可以有很多种，只要是 JS 和 NA 都能访问到的目标，都可以做第三方信息交换。比如本地 socket，远端网站，或者本地文件 file://，或者 cookie，localstorage。

5 安卓 & iOS 统一 API

我们讨论 Android & iOS API 的统一，主要是在 JS 里的统一，因为只有 JS 是跨平台的。统一 API 有两种实现方法：

一种是通过封装的统一，就是说 JS 与原生代码的底层通信方式是不同的，但通过一个嵌入 WebView 的 JS 库实现 API 的统一。
另一种是无需封装的统一，也就是在底层通信的接口就保持了统一，在两端的 JS 代码上是完全一致的。

5.1 JS 调用原生代码

URL 拦截（Android & iOS）

从上文介绍的方法就可以直接看出，通过 URL 拦截实现 JS 调用原生代码是统一适用于所有平台的方法，而且没有版本限制。所以很多 JSBridge 都使用了这种方法以做到最大的兼容性。

    // Android Java: 解析要加载的 URL，如果是自定义 scheme，调用相关的函数
    class MyWebViewClient extends WebViewClient {
      @Override
      public boolean shouldOverrideUrlLoading(WebView view, String url) {
        Uri uri = Uri.parse(url);
        // FIXME 异常处理
        if (uri.getScheme().contentEquals("bridge")) {
          if (uri.getAuthority().contentEquals("propose")) {
            view.evaluateJavascript(uri.getQueryParameter("callback") + "('Yes!')", null);
          }
        } else {
          view.loadUrl(url);
        }
        return true;
      }
    }
    webView.setWebViewClient(new MyWebViewClient());

    // iOS OC: 解析要加载的 URL，如果是自定义 scheme，调用相关的函数
    - (BOOL)webView:(UIWebView*)webView shouldStartLoadWithRequest:(NSURLRequest*)request navigationType:(UIWebViewNavigationType)navigationType {
      NSURL * url = [request URL];
      if ([[url scheme] isEqualToString:@"bridge"] && [[url host] isEqualToString:@"propose"]) {
        NSArray *params =[url.query componentsSeparatedByString:@"&"];
        for (NSString *paramStr in params) {
          if ([paramStr hasPrefix:@"callback"]) {
            NSArray *kv = [paramStr componentsSeparatedByString:@"="];
            [webView stringByEvaluatingJavaScriptFromString:[kv[1] stringByAppendingString: @"('Yes!')"]];
          }
        }
        return NO;
      }
      return YES;
    }

    // 统一的 Javascript: 用不可见 iframe 打开一个自定义 URL，参数需要 urlencode
    bridgeFrame = document.createElement('iframe');
    bridgeFrame.style.display = 'none';
    bridgeFrame.src = 'bridge://propose?msg=Will%20you%20merry%20me%3F&callback=showResult';
    document.documentElement.appendChild(bridgeFrame);

这种方法的问题：

对 URL 格式有 UrlEncode 的要求，对于要传递复杂参数的情况不友好。比如我们需要在参数中传递一个正常的 URL，就需要对这个参数进行两次 UrlEncode，才能保证解码不出问题。
通过 iframe 打开 URL 的方式不太直观，也缺少调用成功的返回确认，需要在 JS 端再封装一下。

对象植入（Android & iOS UIWebView）

放宽兼容性限制，Android 不再兼容 4.1 及以前版本，iOS 不再兼容 iOS 6 及以前版本。那就可以直接通过 Android 的 addJavascriptInterface 和 iOS 的 JSContext 实现将要调用的方法以对象的方式注入到 JS 上下文中，同时也可以直接获得返回结果。

    // Android Java: 定义一个类，提供一个接口，返回一个内容
    class NativeApis {
      @JavascriptInterface
      public String propose(String msg) {
        return "Yes!";
      }
    };
    webView.addJavascriptInterface(new NativeApis(), "Bridge");

    // iOS OC: 定义一个类，提供一个接口，返回一个内容
    // *.h 
    #import 
    @protocol BrigeProtocol 
    - (NSString *)propose:(NSString *)msg;
    @end
    
    @interface Bridge : NSObject
    @end
    // *.m
    // 永远返回 Yes
    @implementation Bridge
    - (NSString *)propose:(NSString *)msg {
      return @"Yes!";
    }
    @end
    ...
      // 注意生命周期
      bridge = [[Bridge alloc] init];
    ...
      JSContext *context = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
      context[@"Bridge"] = bridge;

    // 统一的Javascript: 执行一个 native 的方法
    showResult(window.Bridge.propose("Will you merry me?"));

对象植入（Android & iOS WKWebView）

如果使用 WKWebView，那就意味着进一步放宽了兼容性限制，因为 WKWebView 不支持 iOS 7 及以前版本。上文说到，WKWebView 不支持 JavaScriptCore，但提供了一个 WKScriptMessageHandler 方法。这也意味着我们只能将调用方式尽量往 WKWebView 的方式上统一。

WKWebView 注入的对象，只能使用 postMessage 接口，而且是注入到 window.webkit.messageHandlers 。虽然 Android 的 addJavascriptInterface 不能实现属性的注入，也就是说我们无法在原生代码中在 JS 上下文中添加一个 window.webkit.messageHandlers.NAME 这样一个对象。但我们可以在 WKWebView 中通过 addUserScript 注册一个加载页面时就执行的脚本，将 window.webkit.messageHandlers.NAME 赋给 window.NAME，就实现在注入对象层面的统一。即 Android 和 iOS 里的 Brige 对象都注入到了 window 下。

然后 Android addJavascriptInterface 注入的对象也实现一个与 WKWebView 类似的 postMessage 接口，那么两端就实现了底层接口上的统一。

    // Android Java: 定义一个类似于 WKScriptMessageHandler 的类
    class NativeApis {
      private WebView mWebView;
      public NativeApis(WebView webview) {
        mWebView = webview;
      }
      @JavascriptInterface
      public void postMessage(String msg) {
        try {
          JSONObject json_obj = new JSONObject(msg);
          final String callback = json_obj.getString("callback");
          // JS 是异步线程，转到 UI 线程执行 JS
          mWebView.post(new Runnable() {
            @Override
            public void run() {
              mWebView.evaluateJavascript( callback + "('Yes!')", null);
            }
          });
        } catch (JSONException e) {
          Log.i("Bridge", "postMessage: " + e.getMessage());
        }
      }
    };
    // 初始化 NativeApis 时多一个 webView 句柄
    webView.addJavascriptInterface(new NativeApis(webView), "Bridge");

    // iOS OC: 定义 WKScriptMessageHandler 处理接口
    - (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {
      // 解析 JSON，调用 callback 返回数据
      NSData *jsonData = [message.body dataUsingEncoding:NSUTF8StringEncoding];
      NSDictionary * msgBody = [NSJSONSerialization JSONObjectWithData:jsonData options:kNilOptions error:nil];
      NSString *callback = [msgBody objectForKey:@"callback"];
      [message.webView evaluateJavaScript: [NSString stringWithFormat:@"%@('Yes!')",
                                              callback] completionHandler:^(id _Nullable result, NSError * _Nullable error) {
        // FIXME 出错处理
      }];
    }
    ...
    [[_webView configuration].userContentController addScriptMessageHandler:self name:@"Bridge"];
    // 将 window.webkit.messageHandlers.Bridge 改名成 window.Bridge 与 Android 统一
    WKUserScript* userScript = [[WKUserScript alloc]initWithSource:@"if (typeof window.webkit != 'undefined' && typeof window.webkit.messageHandlers.Bridge != 'undefined') { window.Bridge = window.webkit.messageHandlers.Bridge;}" injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:YES];
    
    [[_webView configuration].userContentController addUserScript:userScript];

    // 统一的Javascript: 给 Native 发送一个消息，通过回调返回结果
    message = {
      func: "propose",
      options : {
        msg: "Will you merry me?"
      },
      callback: showResult.name
    };
    window.Bridge.postMessage(JSON.stringify(message));

5.2 原生代码调用 JS

JS 调用原生代码，主要目的是为了增强 JS 的能力。而原生代码调用 JS 大部分情况下主要是为了便捷 JS 的调用，这可以分为三种情况：

主动设置上下文。每次加载页面必须执行一些 setup，将一些 JS 环境设置好，不需要每次都从服务器端获取。比如上文中讲到的 addUserScript 添加一个加载页面时的上下文环境。
主动发起与 JS 交互。在某些比较少见的场合下，原生代码可能想要主动将一些信息通知给 JS，尤其是一些不在官方 HTML5 支持能力的事件，比如语音的输入、扫码的结果、调用失败等等。
最常见的，是被动的回调 JS。也就是 JS 发起了一个调用，由于调用方式的限制无法返回，或者需要较长时间才能拿到结果，这就需要原生代码在执行完调用后通过回调回传给 JS。

主动设置上下文不需要 API 的统一。

主动发起与 JS 的交互场景比较少，可以有两种方法实现：一种是页面加载过程中将回调注册给 NA；另一种是通过 Web Event 的方式由 NA 广播给 JS 上下文。我们更建议通过 Web Event 的方式广播，这样不受页面加载状态之类的限制，交互上更简单。当然，也可以两种方法结合，增加一个 Event 到 NA 的注册，保证有效广播。

被动的回调 JS，实现上比较直观，只要在 JS 调用 NA 的接口中增加一个 callback 参数，NA 在完成之后回调记录下来的接口即可。

6 JS Bridge 设计上的更多考虑

6.1 是否使用第三方 JS Bridge 库

使用第三方 JS Bridge 库，理论上能避免很多烦恼，按照它的 step by step 指引，很容易就能配出来一个可以工作的 JS Bridge 环境。

但第三方库也有一些缺点。前面讲到，第三方库为了易用，往往在 NA 层和 JS 层都会做一套新的 Adapter API 封装，但不好意思的是，它提供的仍然是一套通用 API 封装，往往应用方还得在上面再封装一层业务 API。这也就意味着，每次 JS-NA 的调用，需要走下面的一套流程：

中间的三层是由第三方库实现的。如果不熟悉第三方库的代码，或者说第三方库在这三层做了过重的封装，那调试问题就会非常困难。

我上文讲到无需二次封装的统一 API，就是希望通过选取合适的 Bridge 方法，把 JS Adapter 这一层去掉或者让它尽量地薄。这样整个调用过程能得到充分地简化，更便于问题的追查和整体的设计。

第三方库还有一个问题就是，它往往追求大而全。比如有些第三方库就是想非常完整地支持 Hybrid App 的设计，但很多时候我们往往仅需要有限个接口调用而已。为了实现有限地一些功能，还得去了解第三方库的整体设计，有时候代价也高了些。

6.2 参数约束

由于 Javascript 是弱类型的语言，而 Java 和 OC 都是强类型的，在参数的互相传递时，需要进行严格的检查。虽说 addJavascriptInterface 等方法可以动态地注入无数个对象或者方法，但仍然不建议这样做，因为维护成本太高。就像 URL 拦截一样，搭桥的路有一条就足够了。

JS Bridge 的接口，就像是一个 RPC 协议。这个 RPC 协议需要有一个版本，这样我们知道哪些版本有哪些 API，更利于有效地调用。这个 RPC 协议需要约定哪些固定的字段，这样我们可以用在入口统一校验字段是否完整，字段类型是否可用。

6.3 出错信息

跨平台的接口，很多时候 DEBUG 比较困难，尤其是上文讲到一些方式无法直接返回结果，自然也无法直接返回错误。所以在接口上，要尽量考虑出错时错误信息的回传通道，例如接口需要提供出错的 callback。

那么问题来了，如果 callback 参数也写错了怎么办？总不能让 FE 看 APP 的 log 吧？

所以建议在接口设计上，增加一个全局错误的 Web Event，就像 Linux 系统下的 errno。任何 JS 调用 NA 失败或者回调失败，都通过这个 Event 分发出去，这样前端就很容易知道错在哪里了。

6.4 API 安全性

虽然网页是在 APP 自己的 WebView 中打开的，但因为网页天然具有的超链接性质，也很难保证所有可以点开的页面都是可信的，比如有些时候活动的落地页可能会到第三方页面等。所以对一些影响 APP 运行逻辑的关键 API 接口，需要做站点的白名单控制，避免第三方站点调用此类 API。

7 总结

这篇文章列举了可用于 JS Bridge 的各平台技术实现，建议了几种无需二次封装的 Android & iOS 平台 JS Bridge 统一 API 的可选方案，讨论了设计一个简洁、规范、安全的 JS Bridge API 需要考虑的问题和解决思路。希望对读者能有所助益。

react-native-navigation 简单分析和跨页跳转

虽然 react-native-navigation 是 Facebook React Native 官方文档推荐的导航库之一，但我也不得不说使用它做 APP 导航主框架的体验简直糟糕透了。当然，这本身可能就是 React Native 自身的问题。

1 react-native-navigation 简单分析

使用 react-native-navigation 首先得理解下它的实现。它独立于 RN Component 的 componentWillMount/componentWillUnmount 接口实现了一套自己的事件机制，最重要的可能是 willAppear/willDisappear。它提供了一套页面堆栈操作和切换动画， push 可以将目标页面切换到最上方，pop 可以返回上一页。

可能是为了性能或者设计使然，push 的时候不会销毁当前页。也就是说，在 A 页面里 push 跳转到B 页面，不会 Unmount A 页面的Component。不过在 B 页面 pop 回 A 页面时，的确会 Unmount B 页面的Component。这也意味着，整个导航路径是一个页面堆栈，只要在堆栈里页面的 Component，都不会被 Unmount。

2 页面堆栈的问题

这有时候会导致一些很严重的问题。有些情况下，特定的 Component 可能会占用唯一的系统资源，比如：麦克风、照相机等。这些 Component 在实现的时候往往只考虑了 React Native 的接口，在 componentWillUnmount 的时候释放占用的资源。它们不会预料到与 react-native-navigation 的结合，专门提供一个 willDisappear 时释放资源的接口，而且有些情况下也未必能这样做。

如果 A 页面在使用这些 Component 已经占用了麦克风或者相机，B 页面也要使用这些 Component，那么从 A push 跳转到 B 时，A 页面的资源不会被释放，B 页面就可能会遇到麦克风不可用，或者相机无法初始化等问题。

解决这个问题，最简单的办法是调整页面交互顺序，保证使用这些独占系统资源的页面永远在堆栈的最顶端，或者使用 Modal Stack，把独占资源的 Component 放到 Modal 里去 present 然后 dismiss。

3 跨页跳转实现

react-native-navigation 只能支持页面堆栈，而且看起来只能支持 push/pop 一个页面，也就是说整个切换过程是串行的，push 顺序是 A->B->A->D ，那么 pop 顺序也只能是 D->A->B->A。

但很可惜地是，在产品经理眼中，是不存在串行页面切换这种限制的。TA 们有时候要求跳转的过程中没 A，但返回的时候要有 A；或者要求跳转的过程中有 A，但返回的时候可以跳过 A，或者甚至直接返回到堆栈最底端。

直接返回栈底很容易，react-native-navigation 提供了 popToRoot 接口，但它没有提供一下子 push 多个页面，或者一下子 pop 多个页面的功能。它也没有类似于 HTML5 的 history API，我们直接对堆栈进行操作，是不太可能的。只能通过它现有的接口想办法。

3.1 跨页 push

跳转的过程没有 A，但返回的时候要有 A，这只是一个产品需求。在实现上，是可以变成跳转过程中有 A，但是 A 被快速跳过，返回的时候才会被真正渲染。这样从用户体验上来看，并没有看到 A。代码实现上，可以考虑两种方法：

willAppear 结合 didDisappear 做状态控制

在 A 的 state 里放一个 isFirstEntry 状态，默认是 true。willAppear 里判断 isFirstEntry 则直接跳转到下个页面，render 里判断 isFirstEntry 则只渲染一个背景 View ，否则才渲染正常页面。这样就实现了在页面切换过程中跳过 A。在的 didDisappear 里将 isFirstEntry 置为 false 。这样在返回的时候 willAppear 和 render 表现就和正常返回一样了。

  willAppear = () => {
    if (this.state.isFirstEntry) {
      this.props.navigator.push(...);
      return;
    }
    ...
  };
  render() {
    if (this.state.isFirstEntry) {
      // 返回背景 View
    } else {
      // 返回正常 View
    }
  }
  didDisappear = () => {
    this.setState({isFirstEntry: false});
  };

willAppear 页面计数

在需要更复杂逻辑的地方，可以在 state 里放一个 appearTimes 计数器。在 willAppear 里给计数器加一，这样每次进入页面都会增加计数。通过判断计数器的值，来决定如何 render 或者跳转。

  willAppear = () => {
    this.setState({appearTimes: this.state.appearTimes + 1});
    if (this.state.appearTimes === 1) {
      this.props.navigator.push(...);
      return;
    }
    ...
  };
  render() {
    if (this.state.appearTimes === 1) {
      // 返回背景 View
    } else {
      // 返回正常 View
    }
  }

3.2 跨页 pop

跳转的过程中有 A，但返回的时候要跳过 A，相当于可以自己操作 pop 的步长。很遗憾，react-native-navigation 没有提供这样的接口。不过我们可以采用一个 trick 的手段，来实现这个逻辑。

假设从 Root->A->B，在 A 的 state 里放一个 relayPop ，默认是 false。在 A 跳转到 B 时，通过 props 传入一个回调：setParentRelayPop，B 可以通过这个回调修改 A 的 state relayPop 为 true；在 A 的 willAppear 中，首先判断 relayPop 是否为真，如果是真的话，代表是从 B 返回且 B 要求接力返回，那么 A 就直接 pop 返回到 A 的上级。 B 在返回时，首先通过回调设置 relayPop 为 true，然后再调用 pop 接口，就实现了跨页返回。

// Screen A
  willAppear = () => {
    if (this.state.relayPop) {
      this.props.navigator.pop();  // 接力返回
      return;
    }
    ...
  };
  ...
    // 跳转逻辑某处
    this.props.navigator.push({..., passProps: {
                                  setParentRelayPop: () => this.setState({relayPop: true}) 
                                }});
// Screen B
    // 返回逻辑某处
    this.props.setParentRelayPop();
    this.props.navigator.pop();

手机 APP 应该选用哪个加密算法 - 兼吐槽 TEA

很多 APP 产品都有通信加密的需求，一部分出于市场的要求，比如苹果对于“ATS”的强制性规定，一部分出于自身安全的考虑，比如对账号和密码的保护。这些需求大部分都可以用简单的 HTTP -> HTTPS 升级来搞定，而且几乎不用付出什么成本（除加解密的计算开支外），例如使用我之前文章介绍到的 Let's Encrypt 免费证书。

但还有一类特殊的需求，HTTPS 解决不了，也就是防协议分析的需求。很多 APP 开发者应该知道，只要在手机里安装一个代理 CA 证书，就可以实现中间人攻击，通过代理软件抓到 HTTPS 包的明文内容。虽然这样的攻击很难在公开网络上进行，但对自己的手机进行抓包分析，作为 APP 和服务端通信的调试手段是被广泛使用的。

协议分析能做什么呢？可以猜想到一定的 APP 内部逻辑，可以对产品数据进行作弊攻击。举个例子：你的 APP 通过某个渠道进行推广，为了统计渠道安装、注册或者日活，你往往会在 APP 中埋一个点，当 APP 启动时，发送一些信息到服务器。如果这个协议被破解了，渠道商根本不需要真正进行推广，只需要构造一些假消息发送到你的服务器就行了。仅看数据你可能会以为这个渠道推广效果特别好，其实只是骗局而已。

这类情况下，就要求对敏感协议内容进行额外的数据保护。最常用的做法，就是对协议内容进行一次额外的加密，为了性能，往往选用对称加密算法。那么问题来了，手机 APP 开发时，应该选用哪个加密算法？

关于这个选型，国内互联网圈有个怪现状值得谈一下，那就是 TEA 算法。因为该算法在腾讯有着广泛的应用，因而被很多客户端开发人员推崇。典型推荐理由往往是：“TEA加密算法不但比较简单，而且有很强的抗差分分析能力，加密速度也比较快，还可以根据需求设置加密轮数来增加加密强度”。这是真的吗？算法安全性可以直接看维基百科上 TEA 算法的介绍，我的理解是不够安全。但其实大部分用户也不那么地在乎它的安全强度，那么性能呢？加密速度真的很快吗？

这就要从历史的角度去看了。作为曾经手撸过 “DES 差分密码攻击” 代码的程序员，表示 TEA 算法的确足够简单。在 QQ 诞生的那个年代，TEA 在计算上的确有着不小的优势。但 QQ 已经 18 岁了啊同学们，18 年来中国发生了多大的变化，世界发生了多大的变化啊！

2008 年，Intel 就发布了 x86 的 AES 指令集扩展，近几年的服务器 CPU 应该都支持，不相信你
grep aes /proc/cpuinfo 就能看到；2011 年 ARM 也在 ARMv8 架构下直接提供了 AES 和 SHA-1/SHA-256 指令。这意味着什么？意味着服务端和客户端在硬件上直接支持 AES，意味着原来 N 条汇编指令只需要一条 AES 指令就完成了。其实也意味着，在绝大多数情况下 AES 才应该是你的首选。

口说无凭，咱们可以看一下测试数据，x86 服务器 CPU 测试可以直接看 Crypto++ 的 benchmark 。可以看到 AES/CTR (128-bit key) 与 TEA/CTR (128-bit key) 的加密速度比是：4499 MB/s 比 72 MB/s，62 倍的差异！这就是硬件实现的威力。

ARM 手机 CPU 加密算法的 Benchmark，我没有找到。但为了更有说服力，我自己实现了两个测试 APP，一个 Android 版，一个 iOS 版。写技术文章多不容易啊，写博客之前先写三个晚上代码，泪目！！！代码在 https://github.com/solrex/cipher-speed ，Android 版可以直接在 Release 里扫码安装。

首先介绍一下目前的旗舰 CPU，骁龙 835 (MSM8998) 的表现，测试机型是小米 6：

# Speed Test of 10MB Data Enc/Decryption #
# AES: 
* [AES/CBC/PKCS5Padding] ENC: 1146.9 KB/ms
* [AES/CBC/PKCS5Padding] DEC: 692.4 KB/ms
* [AES/CBC/NoPadding] ENC: 1118.8 KB/ms
* [AES/CBC/NoPadding] DEC: 1343.5 KB/ms
* [AES/ECB/PKCS5Padding] ENC: 990.4 KB/ms
* [AES/ECB/PKCS5Padding] DEC: 703.2 KB/ms
* [AES/ECB/NoPadding] ENC: 973.4 KB/ms
* [AES/ECB/NoPadding] DEC: 988.9 KB/ms
* [AES/GCM/NOPADDING] ENC: 13.9 KB/ms
* [AES/GCM/NOPADDING] DEC: 14.7 KB/ms
# DES: 
* [DES/CBC/PKCS5Padding] ENC: 20.1 KB/ms
* [DES/CBC/PKCS5Padding] DEC: 20.7 KB/ms
* [DES/CBC/NoPadding] ENC: 21.3 KB/ms
* [DES/CBC/NoPadding] DEC: 21.6 KB/ms
* [DES/ECB/PKCS5Padding] ENC: 26.3 KB/ms
* [DES/ECB/PKCS5Padding] DEC: 26.2 KB/ms
* [DES/ECB/NoPadding] ENC: 25.9 KB/ms
* [DES/ECB/NoPadding] DEC: 26.8 KB/ms
# 3DES: 
* [DESede/CBC/PKCS5Padding] ENC: 23.6 KB/ms
* [DESede/CBC/PKCS5Padding] DEC: 23.2 KB/ms
* [DESede/CBC/NoPadding] ENC: 23.6 KB/ms
* [DESede/CBC/NoPadding] DEC: 23.5 KB/ms
* [DESede/ECB/PKCS5Padding] ENC: 8.5 KB/ms
* [DESede/ECB/PKCS5Padding] DEC: 8.5 KB/ms
* [DESede/ECB/NoPadding] ENC: 8.5 KB/ms
* [DESede/ECB/NoPadding] DEC: 8.6 KB/ms
# TEA: 
* [TEA] ENC: 16.0 KB/ms
* [TEA] DEC: 18.1 KB/ms

可以看到，TEA:AES=16:990，这是多少倍？我都懒得算了。然后是 2 年前的中低端 CPU，联发科 Helio P10 (MT6755)，测试机型是魅蓝 Note 3：

# Speed Test of 10MB Data Enc/Decryption #
# AES: 
* [AES/CBC/PKCS5Padding] ENC: 358.8 KB/ms
* [AES/CBC/PKCS5Padding] DEC: 267.9 KB/ms
* [AES/CBC/NoPadding] ENC: 438.8 KB/ms
* [AES/CBC/NoPadding] DEC: 515.0 KB/ms
* [AES/ECB/PKCS5Padding] ENC: 310.6 KB/ms
* [AES/ECB/PKCS5Padding] DEC: 222.1 KB/ms
* [AES/ECB/NoPadding] ENC: 312.4 KB/ms
* [AES/ECB/NoPadding] DEC: 319.5 KB/ms
* [AES/GCM/NOPADDING] ENC: 5.1 KB/ms
* [AES/GCM/NOPADDING] DEC: 5.7 KB/ms
# DES: 
* [DES/CBC/PKCS5Padding] ENC: 7.5 KB/ms
* [DES/CBC/PKCS5Padding] DEC: 7.7 KB/ms
* [DES/CBC/NoPadding] ENC: 7.7 KB/ms
* [DES/CBC/NoPadding] DEC: 7.8 KB/ms
* [DES/ECB/PKCS5Padding] ENC: 9.3 KB/ms
* [DES/ECB/PKCS5Padding] DEC: 9.2 KB/ms
* [DES/ECB/NoPadding] ENC: 9.3 KB/ms
* [DES/ECB/NoPadding] DEC: 9.5 KB/ms
# 3DES: 
* [DESede/CBC/PKCS5Padding] ENC: 12.5 KB/ms
* [DESede/CBC/PKCS5Padding] DEC: 12.3 KB/ms
* [DESede/CBC/NoPadding] ENC: 12.3 KB/ms
* [DESede/CBC/NoPadding] DEC: 12.5 KB/ms
* [DESede/ECB/PKCS5Padding] ENC: 3.1 KB/ms
* [DESede/ECB/PKCS5Padding] DEC: 3.1 KB/ms
* [DESede/ECB/NoPadding] ENC: 3.1 KB/ms
* [DESede/ECB/NoPadding] DEC: 3.1 KB/ms
# TEA: 
* [TEA] ENC: 6.2 KB/ms
* [TEA] DEC: 8.0 KB/ms

然后是 3 年前的旗舰 CPU，Apple A8，测试机型是 iPhone6。别问我为啥不用今年的苹果旗舰 CPU...

# Speed Test of 10MB Data Enc/Decryption #
# AES
* [AES/CBC/PKC7Padding] ENC: 76.0 KB/ms
* [AES/CBC/PKC7Padding] DEC: 111.3 KB/ms
* [AES/CBC/NoPadding] ENC: 138.2 KB/ms
* [AES/CBC/NoPadding] DEC: 450.7 KB/ms
* [AES/ECB/PKC7Padding] ENC: 305.6 KB/ms
* [AES/ECB/PKC7Padding] DEC: 735.9 KB/ms
* [AES/ECB/NoPadding] ENC: 330.0 KB/ms
* [AES/ECB/NoPadding] DEC: 673.6 KB/ms
# DES
* [DES/CBC/PKC7Padding] ENC: 23.1 KB/ms
* [DES/CBC/PKC7Padding] DEC: 24.5 KB/ms
* [DES/CBCPadding] ENC: 23.1 KB/ms
* [DES/CBCPadding] DEC: 22.8 KB/ms
* [DES/ECB/PKC7Padding] ENC: 19.4 KB/ms
* [DES/ECB/PKC7Padding] DEC: 20.8 KB/ms
* [DES/ECBPadding] ENC: 22.2 KB/ms
* [DES/ECBPadding] DEC: 22.2 KB/ms
# 3DES
* [3DES/CBC/PKC7Padding] ENC: 9.7 KB/ms
* [3DES/CBC/PKC7Padding] DEC: 9.8 KB/ms
* [3DES/CBC/NoPadding] ENC: 9.8 KB/ms
* [3DES/CBC/NoPadding] DEC: 9.8 KB/ms
* [3DES/ECB/PKC7Padding] ENC: 9.4 KB/ms
* [3DES/ECB/PKC7Padding] DEC: 9.1 KB/ms
* [3DES/ECB/NoPadding] ENC: 9.2 KB/ms
* [3DES/ECB/NoPadding] DEC: 9.4 KB/ms
# TEA
* [TEA] ENC: 10.9 KB/ms
* [TEA] DEC: 11.1 KB/ms

关于 Apple A8 的测试多说两句。我上面的 AES 性能，离 GeekBench 发布的 A8 AES Single Core 还有不少差距，不知道是不是测试方法差异导致。但总的来说，不影响结论，那就是 TEA 跟 AES 差距巨大。

看到这里，可能大部分人心里已经做出选择了。即使还没做出选择的读者，我想你也可以考虑看看我的代码实现是否存在问题。不过最后还是回答一下开头提出的问题吧：

如果你使用平台语言来实现对称加密，也就是 Android 上用 Java，iOS 上用 OC 或者 Swift，AES 是不二选择。这样能充分利用硬件提供的能力，安全性+性能肯定是最优，不要再想其他选项了。
如果你使用 Native 语言来实现对称加密，在 Android 上使用 JNI 调用 C 编译的代码，的确不少人认为原生指令更难逆向。可能要在 ARM 架构上做个取舍，是取悦 v8 用户，还是取悦 v7 以下的用户，这可能影响到选型。不过我认为 AES 依然是一个好的选项，起码在服务器端，你肯定会节省成本。

700行代码帮你迈出打造专属Jarvis的第一步

前几天，Mark Zuckerberg 写了一篇博客《Building Jarvis》，立即风靡科技圈。智能家庭，Bill Gates 弄了一个，Zuckerberg 也搞了一个，科技圈的大佬们纷纷动手，让小民们看着很眼馋。

在《Building Jarvis》这篇文章中，Zuckerberg 写到：

These challenges always lead me to learn more than I expected, and this one also gave me a better sense of all the internal technology Facebook engineers get to use, as well as a thorough overview of home automation.

注意到这些酷炫的技术，都是 internal technology Facebook engineers get to use。那么到底有没有可能，使用公开领域的服务，构建一个类似于 Jarvis 的系统呢？

正好这段时间，我也在做一个基于人工智能技术的简单 APP：WhatIsWhat。这个 APP 目前很简单，甚至可以称得上简陋，但可能对你构建自己的 Jarvis 会有所帮助或启发。

背景

某天闲聊的时候，有个妈妈同事说，她家宝宝问她很多东西不懂，只好去搜索，发现百度百科的不少词条有个“秒懂百科”，用视频讲解百科词条，宝宝很爱看。只是可惜宝宝不认字，不会自己搜索。然后我就想，要是有个工具，能用语音问问题，语音或者视频回答问题，那挺不错啊，就有了这个 APP。

随着近几年语音识别准确率的大幅度提升，语音交互技术已经步入到非常成熟的阶段了。公开领域也有讯飞、百度等好几家免费服务可用，只是关注和使用这些的一般都是企业，个人开发者并不多。其实从我工作上的背景出发，语音交互背后的技术都是非常熟悉的。下面我就以我使用的百度语音开放平台为例，解释下能有哪些免费的语音交互服务可用。

语音识别

要想宝宝能使用语音问问题，首先需要有一个语音转文字的技术，我们一般称之为“语音识别”。从 20 世纪 70 年代 IBM 把 HMM 应用到语音识别技术上来以后，语音识别准确率一直在稳步提升。但到了 2000 年以后，语音识别的效果改进停滞了，而且一停就是 10 年。直到 2010年，Geoffrey Hinton、邓力和俞栋在微软研究院将深度学习引入语音识别技术后，平地一声惊雷，语音识别的准确率才又开始一次大跃进。

可以这样说，20 年前的语音识别和六七年前的语音识别，没有太大区别。但现在的语音识别技术，和六七年前的语音识别技术，是有革命性改进的。如果你还根据几年前的经验，认为语音识别是个 Tech Toy，识别结果充满了错漏。不妨试试最新的语音识别产品，比如讯飞语音输入法、百度语音搜索，结果会让你很吃惊的。

值得高兴的是，讯飞和百度都将最新的语音识别技术免费开放给所有人使用。比如百度的语音识别服务，单个应用每天可以免费调用 5 万次，而且可以通过申请提升这个免费上限。只需要到它的平台上注册成为开发者（不需要任何费用），申请新建一个应用，下载最新版的 SDK，参考文档集成到 APP 里就行了。

语音合成

如果想让手机使用语音回答问题，还需要一个文字转语音的技术，我们一般称之为“语音合成”或者“TTS”。语音合成在准确率方面的问题上，没有语音识别那么显著，但更大的困难来自于“怎么让机器发出的声音更像人声？”有很多个方面的考量，比如情绪、重音、停顿、语速、清晰度等等。现代的语音合成产品，一般都支持选择发声人（男声、女声、童声）和调整语速的功能。很多小说阅读器都配备的“语音朗读”，就是语音合成技术的典型应用。

讯飞和百度也都免费开放了自家的语音合成技术，也是类似于语音识别的SDK集成即可。值得一说的是，Google 在今年 9 月发表了自家的 WaveNets 语音合成模型，号称将 TTS 发声和人声的差距缩短了 50%（可以到这个页面体验一下），所以我们可以期待公开的语音合成服务效果有更进一步的改进。

语音唤醒

就像两个人交谈时你必须得称呼对方名字，他才知道你是在对他说话，机器也是一样。对着手机屏幕的时候，可以通过点击麦克风按钮来实现唤醒语音输入，但在远处或者不方便点击时（比如开车），需要用特定的指令唤醒它接收并处理你的输入。就像我们熟悉的“Hey，Siri”和“OK，Google”，我们一般称之为“语音唤醒”。

一般情况下，唤醒指令不依赖语音识别，也就是说，它纯粹是使用声学模型匹配你的声音。这样做也有好处，就是不依赖网络，待机功耗也更低。

讯飞的语音唤醒功能是收费的，但是百度的语音唤醒功能是免费的，可以定制自己的唤醒词，然后下载对应唤醒词的声学模型包，集成到语音识别 SDK 中即可。

如果希望打造一个专属的 Jarvis 的话，这个唤醒词声学模型最好是使用自己的语音训练出来的，这样召准率才能更高。但很遗憾，百度的免费语音唤醒还不支持这点，只能用百度语料库训练出来的模型。

自然语言理解

关于自然语言理解，Zuckerberg 的《Building Jarvis》已经解释得非常充分了，这是一个非常复杂和困难的技术领域。讯飞和百度也都在自身语音识别能力基础上，开放了自然语言理解的能力。用户甚至可以在云端自定义自己的语义，这样识别后不仅能拿到一个纯文本识别结果，还可以获取结构化的分析后结果。

我对 WhatIsWhat 这个 APP 的要求很简单，只需要理解“什么是什么？”这个问题即可。我没有用到百度的语义理解能力，而是简单地写了一个正则表达式匹配，主要是希望后续能充分利用语音识别的 Partial Result 对性能进行优化。

问题回答

目前很多搜索引擎（比如谷歌、百度）对语音发起的搜索，在给出搜索结果的同时，往往附带着一句或者几句语音的回答。但搜索引擎针对的往往是开放领域的搜索词，所以语音回答的覆盖比例并不高。限定到“什么是什么”这个特定的领域，百度百科的满足比例就高了。尤其是秒懂百科，使用视频的方式讲解百科词条，样式非常新颖。

在这个最初的版本中，我只采取了秒懂百科的结果。也就是先抓取百科结果页，提取秒懂百科链接，然后打开秒懂百科结果页。为了让播放视频更方便，我用 WebView 执行了一个自动的点击事件，这样第一条视频结果在打开页面后会直接播放，不需要再点击。

演示视频

下面是“WhatIsWhat”这个 APP 的演示视频，请点击查看，因为录音设备的冲突，视频的后半部分没有声音，敬请谅解。

源代码地址

你可以到 https://github.com/solrex/WhatIsWhat 这个链接查看“WhatIsWhat”的全部源代码。代码总共 700 多行，不多，需要有一点儿 Android 和 Java 基础来理解。

总结

WhatIsWhat 是从一个朴素 idea 出发的非常简单的 APP，这个产品集成了“语音识别、语音合成、语音唤醒、自然语言理解”几类人工智能服务。想要实现 Jarvis，可能还需要人脸识别、智能对话、开放硬件 API 等几项能力，并且需要一定的工程能力将这些功能整合起来。

虽然 WhatIsWhat 与 Jarvis 的复杂度不可比，但它演示了如何使用公共领域已有的人工智能服务，构造一个落地可用的产品。更重要的是，它便宜到不需花一分钱，简单到只有 700 行代码。

就像 Zuckerberg 所说“In a way, AI is both closer and farther off than we imagine. ”虽然很多人并没有意识到语音交互这类 AI 技术能够那么地触手可及，但技术的开放对 AI 应用普及的影响是巨大的。在这一点上，国内的人工智能产业巨头们做得并不差。这篇文章，WhatIsWhat 这个 APP，只能帮你迈出第一步，希望不远的将来，我们能够有更多的开放 AI 服务，使得搭建自己的专属 Jarvis 变成一件轻而易举的事情。

Android HTTPUrlConnection EOFException 历史 BUG

这是一个影响 Android 4.1-4.3 版本的 HTTPUrlConnection 库 BUG，但只会在特定条件下触发。

我们有一个 Android App，通过多个并发 POST 连接上传数据到服务器，没有加入单个请求重试机制。在某些 Android 机型上发现一个诡异的 bug，在使用中频繁出现上传失败的情况，但是在其它机型上并不能复现。

经过较长时间的排查，我们找到了上传失败出现的规律，并认为它跟 HTTP Keepalive 持久化连接机制有关。具体的规律是：当 App 上传一轮数据后，等待超过服务端 Nginx keepalive_timeout 时间后，再次尝试上传数据，就会出现上传失败，抛出 EOFException 异常。

更准确的特征可以通过连上手机的 adb shell 观察 netstat：当 App 上传一轮数据后，可以观察到有 N 个到服务器的连接处于 ESTABLISHED 状态；当等待超过服务端 Nginx keepalive_timeout 时间后，可以观察到这 N 个到服务器的连接处于 CLOSE_WAIT 状态；当上传失败后，发现部分 CLOSE_WAIT 状态的连接消失。

Java 的 HTTP Keepalive 机制，一直是由底层实现的，理论上来讲，不需要应用层关心。但从上面的 BUG 来看，对于 stale connection 的复用，在部分 Android 机型上是有问题的。为此我稍微研究了一下 Android 的源代码，的确发现了一些问题。

在 2011年12月15日，Android 开发者提交了这样一个 Commit，Commit Message 这样写到：

Change the way we cope with stale pooled connections.

Previously we'd attempt to detect if a connection was stale by
probing it. This was expensive (it relied on catching a 1-millisecond
read timing out with a SocketTimeoutException), and racy. If the
recycled connection was stale, the application would have to catch
the failure and retry.

The new approach is to try the stale connection directly and to recover
if that connection fails. This is simpler and avoids the isStale
heuristics.

This fixes some flakiness in URLConnectionTest tests like
testServerShutdownOutput and testServerClosesOutput.

Bug: http://b/2974888
Change-Id: I1f1711c0a6855f99e6ff9c348790740117c7ffb9

简单来说，这次 commit 做了一件事：在修改前，是在 TCP 连接池获取连接时，做 connection isStale 的探测。Android 开发者认为这样会在获取每个 connection 时都有 1ms 的 overhead，所以改成了在应用层发生异常时，再重试请求。但是这个重试有个前提，就是用户的请求不能是 ChunkedStreamingMode，不能是 FixedLengthStreamingMode，这两种模式下，底层无法重试。很不幸地是，我们正好使用到了 FixedLengthStreamingMode 带来的特性。

// Code snippet of: libcore.net.http.HttpURLConnectionImpl.java
while (true) {
  try {
    httpEngine.sendRequest();
    httpEngine.readResponse();
  } catch (IOException e) {
    /*
     * If the connection was recycled, its staleness may have caused
     * the failure. Silently retry with a different connection.
     */
    OutputStream requestBody = httpEngine.getRequestBody();
    // NOTE: FixedLengthOutputStream 和 ChunkedOutputStream
    // 不是 instance of RetryableOutputStream
    if (httpEngine.hasRecycledConnection()
        && (requestBody == null || requestBody instanceof RetryableOutputStream)) {
      httpEngine.release(false);
      httpEngine = newHttpEngine(method, rawRequestHeaders, null,
          (RetryableOutputStream) requestBody);
      continue;
    }
    httpEngineFailure = e;
    throw e;
}

由于 BUG 的根源在 Android 的核心库 libcore 中。这次改动影响了从 4.1 到 4.3 的所有 Android 版本， Android 4.4 网络库的 HTTP/HTTPS 从 libcore 切换到 okhttp，所以4.4以后的 Android 版本不受影响。

既然底层不重试，那么只有在应用层重试，所以我们在应用层增加了最多『http.maxConnections+1』次重试机制，以修复此问题。在重试的时候，尝试使用一个 stale connection 会导致 EOFException，底层也会自动关闭这个连接。『http.maxConnections+1』次重试保证即使连接池中全都是 stale connection，我们也能获得一个可用的连接。

网上应该也有人遇到过这个 BUG，所以我也在这个 StackOverflow 问题下做了回答。

Google App API Protocol - Voice Search

Google 在移动平台（Android 和 iOS）上提供了独立的 Search App，但它不仅仅是用一个移动浏览器封装了 Google Web Search，而是做了很多移动应用相关的改进。这个系列文章，通过抓包对 Android Google App 与 Server 间通讯协议进行简单分析，管中窥豹，以见一斑。

Google App API Protocol - Text Search
Google App API Protocol - Voice Search
Google App API Protocol - Search History

语音搜索

语音搜索与文本搜索不同，必须先进行语音识别（语音转文字），拿到识别结果后才能进行搜索，拿到搜索结果。语音识别过程是一个录音数据流上传过程，一般采取的都是流式分片上传。Google App 的语音搜索，仍然是沿袭 Google 一贯注重效率的风格，使用两个 HTTPS 请求，完成了录音数据的流式上传，以及识别结果、搜索结果和语音播报的流式下发。具体的做法是：

在用户发起语音请求时，Google App 与 Google 服务器同时建立两个 HTTPS POST 连接，以 URL 参数 "pair" 标识这是同一用户的一对连接：

https://www.google.com/m/voice-search/up?pair=4fc4d987-3f06-49d5-9f3a-986937a5e5fe
https://www.google.com/m/voice-search/down?pair=4fc4d987-3f06-49d5-9f3a-986937a5e5fe

Google App 基于 chunked 编码，在 up 连接中实现录音数据流式上传，在 down 连接中实现识别结果、搜索结果和语音播报的流式下发。

语音搜索 up 连接

在 up 连接中，Google App 仅利用了 POST 请求通路的 chunked 编码流式上传录音数据，直到所有数据上传完成，Google 服务器才会返回一个 Content-Length 为 0 的 200 响应消息。而且 POST 请求的 HTTP Header/Params 很简单，仅仅包含基本的信息。

Host	www.google.com
Connection	keep-alive
Transfer-Encoding	chunked
Cache-Control	no-cache, no-store
X-S3-Send-Compressible	1
User-Agent	Mozilla/5.0 (Linux; Android 4.4.4; HM 1S Build/KTU84P)
                AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 
                Mobile Safari/537.36 GSA/5.9.33.19.arm
Content-Type	application/octet-stream
Accept-Encoding	gzip, deflate

这里要注意 Cotent-Type 是 application/octet-stream，这代表上传的是二进制数据流，需要用专门的协议才能 decode 到真正内容。这给解析协议带来了很大的困难。简单观察二进制数据流，发现部分内容是遵从 protobuf 协议格式，但直接使用 application/x-protobuffer 的 Dilimited List 封包格式进行 docode 并不成功。无奈之下，只好采取比较笨的方法，观察二进制数据流，跳过那些明显不符合 protobuf 协议格式的部分，尽最大努力把 protobuf 消息先解包出来。然后再根据已经解包出来的部分，逐步推测未解析部分的编码格式。经过较长时间的分析，拿到了 Google App 语音搜索 up 连接的请求消息封包格式大致如下：

(10 bytes Header)
(Big Endian Fixed32 of Msg Len)(Msg)
(Big Endian Fixed32 of Msg Len)(Msg)
......
(Big Endian Fixed32 of Msg Len)(Msg)

对于 Header 长度是否恒为 10 字节，我持怀疑态度，有待通过更多分析发现规律。做了很多二进制码的分析工作，到最后才发现消息结构如此简单，让人不得不抱怨：Google 你直接用和文本搜索一样的 application/x-protobuffer 格式不得了吗？还搞得那么复杂！不过也许有一定历史原因吧。

和文本搜索一样，先建立一个 Empty protobuf Message，逐步去推导流式协议里 Message 的结构，尽最大猜测推导出来的 Google 语音搜索请求消息的 .proto 可能是这样的：

$ more voicesearch.proto
package com.google.search.app;

message VoiceSearchRequest {
    optional int32 fin_stream = 3;
    optional UserInfo user_info = 293000;
    optional VoiceSampling voice_sampling = 293100;
    optional VoiceData voice_data = 293101;
    optional ClientInfo client_info = 294000;
    optional UserPreference user_preference = 294500;
    optional Empty VSR27301014 = 27301014;
    optional Empty VSR27423252 = 27423252;
    optional Double VSR27801516 = 27801516;
    optional GetMethod get_method = 34352150;
    optional Empty VSR61914024 = 61914024;
    optional Empty VSR77499489 = 77499489;
    optional Empty VSR82185720 = 82185720;
}

message UserInfo {
    optional Empty lang = 2;
    optional Empty locale = 3;
    optional string uid = 5;
    optional GoogleNow google_now = 9;
}

message GoogleNow {
	optional string auth_url = 1;
	optional string auth_key = 2;
}

message VoiceSampling {
    optional float sample_rate = 2;
}

message VoiceData {
    optional bytes amr_stream = 1;
}

message ClientInfo {
	optional string type = 2;
	optional string user_agent = 4;
	repeated string expids = 5;
	optional string os = 8;
	optional string model = 9;
	optional string brand = 11;
}

message UserPreference {
    optional Favorites favorites = 1;
    optional Empty UP4 = 4;
    optional Empty UP25 = 25;
}

message Favorites {
	optional string lang = 9;
	repeated Empty favorites_data = 22;
}

message GetMethod {
	optional Empty params = 1;
	optional HttpHeader headers = 2;
	optional string path = 3;
}

message HttpHeader {
    repeated string name = 1;
    repeated string text_value = 2;
    repeated bytes binary_value = 4;
}

基于这个 .proto，对语音输入『北京天气』的 POST 请求消息进行解码，最终的结果摘要如下：

$ more up.txt
######## Data block info: offset=0xa blockSize=3717
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=3654
user_info {
  lang {
    1: "cmn-Hans-CN"
    2: 1
  }
  locale {
    1: "zh_CN"
    2: 2
  }
  uid: "******"
  google_now {
    auth_url: "https://www.googleapis.com/auth/googlenow"
    auth_key: "******"
    7: 1
  }
  8: "w "
}
voice_sampling {
  sample_rate: 16000.0
  3: 9
}
client_info {
  type: "voice-search"
  user_agent: "Mozilla/5.0 (Linux; Android 4.4.4; ......"
  expids: "p2016_01_27_20_58_17"
  expids: "8501679"
  expids: "8501680"
  expids: "8502094"
  expids: "8502157"
  expids: "8502159"
  expids: "8502312"
  expids: "8502347"
  expids: "8502369"
  expids: "8502376"
  expids: "8502490"
  expids: "8502491"
  expids: "8502618"
  expids: "8502679"
  expids: "8502705"
  expids: "8502947"
  expids: "8502986"
  expids: "8503012"
  expids: "8503037"
  expids: "8503109"
  expids: "8503110"
  expids: "8503132"
  expids: "8503133"
  expids: "8503157"
  expids: "8503158"
  expids: "8503208"
  expids: "8503212"
  expids: "8503214"
  expids: "8503303"
  expids: "8503306"
  expids: "8503367"
  expids: "8503368"
  expids: "8503404"
  expids: "8503512"
  expids: "8503559"
  expids: "8503585"
  expids: "8503604"
  expids: "8503606"
  expids: "8503729"
  expids: "8503730"
  expids: "8503751"
  expids: "8503752"
  expids: "8503755"
  expids: "8503805"
  expids: "8503815"
  expids: "8503832"
  expids: "8503835"
  expids: "8503844"
  expids: "8503853"
  expids: "8503855"
  expids: "8503907"
  expids: "8503925"
  expids: "8503927"
  expids: "8503994"
  expids: "8504022"
  expids: "8504059"
  os: "Android"
  model: "KTU84P"
  brand: "HM 1S"
  1: ""
  10: "300601416"
  12: 720
  13: 1280
  14: 320
  17: "assistant-query-entry"
}
user_preference {
  favorites {
    favorites_data {
      1: 2
      2: "fresh"
      9: "cmn-Hans-CN"
    }
    favorites_data {
      1: 2
      2: "favorite-phone"
      9: "cmn-Hans-CN"
    }
    favorites_data {
      1: 2
      2: "favorite-email"
      9: "cmn-Hans-CN"
    }
    favorites_data {
      1: 2
      2: "favorite-person"
      9: "cmn-Hans-CN"
    }
  }
  UP4 {
    1: 10
    2: 250
    3: 1
  }
  UP25 {
    1: 0
  }
  3: 5
  5: 1
  7: 0
  13: 1
  14: 1
  20: 1
  22: 0
}
VSR27301014 {
  1: 460
  2: 0
  3: 460
  4: 0
  5: 1
}
VSR27423252 {
  1: "rbshUd2M8t4"
}
VSR27801516 {
  d7: 0.6037593483924866
}
get_method {
  params {
    1: "noj"
    1: "tch"
    1: "spknlang"
    1: "ar"
    1: "br"
    1: "ttsm"
    1: "client"
    1: "hl"
    1: "oe"
    1: "safe"
    1: "gcc"
    1: "ctzn"
    1: "ctf"
    1: "v"
    1: "padt"
    1: "padb"
    1: "ntyp"
    1: "ram_mb"
    1: "qsubts"
    1: "wf"
    1: "inm"
    1: "source"
    1: "entrypoint"
    1: "action"
    2: "1"
    2: "6"
    2: "cmn-Hans-CN"
    2: "0"
    2: "0"
    2: "default"
    2: "ms-android-xiaomi"
    2: "zh-CN"
    2: "utf-8"
    2: "images"
    2: "cn"
    2: "Asia/Shanghai"
    2: "1"
    2: "5.9.33.19.arm"
    2: "200"
    2: "640"
    2: "1"
    2: "870"
    2: "1458289692542"
    2: "pp1"
    2: "vs-asst"
    2: "and/assist"
    2: "android-assistant-query-entry"
    2: "devloc"
  }
  headers {
    name: "User-Agent"
    name: "X-Speech-RequestId"
    name: "Cookie"
    name: "Host"
    name: "Date"
    name: "X-Client-Instance-Id"
    name: "X-Geo"
    name: "X-Client-Opt-In-Context"
    name: "X-Client-Data"
    text_value: "Mozilla/5.0 (Linux; Android 4.4.4; ......"
    text_value: "rbshUd2M8t4"
    text_value: "******"
    text_value: "www.google.com.hk"
    text_value: "Fri, 18 Mar 2016 08:28:13 GMT"
    text_value: "c6aef75ce70631e9518ae8e7011bb3d7957b24d59b62fd1b9d378262b3690cff"
    text_value: "w CAEQDKIBBTk6MTox"
    binary_value: "\037\213\b\000......"
    binary_value: "\b\257\363\206......gsa"
  }
  path: "/search"
  5: 0
}
VSR61914024 {
  1: 1
}
VSR77499489 {
  1: 1
}
VSR82185720 {
  1: "\b\001"
}
1: "voicesearch-web"
2: 1
4: 0

######## Data block info: offset=0xe93 blockSize=39
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=39
get_method {
  headers {
    name: "X-Geo"
    text_value: "w CAEQDKIBBTE6MTox"
    3: 2
  }
}
2: 1

######## Data block info: offset=0xebe blockSize=309
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=309
voice_data {
  amr_stream: "#!AMR-WB......"
}
2: 1

######## Data block info: offset=0xff7 blockSize=309
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=309
voice_data {
  amr_stream: "......"
}
2: 1

......

######## Data block info: offset=0x4394 blockSize=309
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=309
voice_data {
  amr_stream: "......"
}
2: 1

######## Data block info: offset=0x44cd blockSize=267
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=267
voice_data {
  amr_stream: "......"
}
2: 1

######## Data block info: offset=0x45dc blockSize=4
#### Proto: Voicesearch.VoiceSearchRequest Message with Size=4
fin_stream: 1
2: 1

语音搜索 down 连接

在 down 连接中，Google App 仅利用了 POST 响应通路的 chunked 编码流式下发识别结果、搜索结果和语音播报数据。App 发起的虽然是一个 POST 请求，但在请求中并没有任何 POST Data，Content-Length 为 0。响应消息的 header 如下：

Content-Type	application/vnd.google.octet-stream-compressible
Content-Disposition	attachment
Cache-Control	no-transform
X-Content-Type-Options	nosniff
Pragma	no-cache
Content-Encoding	gzip
Date	Fri, 18 Mar 2016 08:28:14 GMT
Server	S3 v1.0
X-XSS-Protection	1; mode=block
X-Frame-Options	SAMEORIGIN
Alternate-Protocol	443:quic,p=1
Alt-Svc	quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
Transfer-Encoding	chunked

这里值得注意的，仍然是 Cotent-Type，这次是 application/vnd.google.octet-stream-compressible，又一个二进制私有协议数据流。通过与 up 流分析类似的方法，发现 Google App 语音搜索 down 连接的响应消息封包格式大致如下：

(4 bytes Header)
(Big Endian Fixed32 of Msg Len)(Msg)
(Big Endian Fixed32 of Msg Len)(Msg)
......
(Big Endian Fixed32 of Msg Len)(Msg)

可以看到，除了 Header 长度不同以外，基本与 up 连接的请求消息封包格式一样。采取同样的方式推测到 Google 语音搜索响应消息的 .proto 可能是这样的：

$ more voicesearch.proto
package com.google.search.app;
message VoiceSearchResponse {
    optional int32 fin_stream = 1;
    optional RecogBlock recog_block = 1253625;
    optional SearchResult search_result = 39442181;
    optional TtsSound tts_sound = 28599812;
}

message RecogBlock {
    optional RecogResult recog_result = 1;
    optional VoiceRecording voice_recording = 2;
    optional string inputLang = 3;
    optional string searchLang = 4;
}

message RecogResult {
    optional CandidateResults can = 3;
    repeated RecogSegment recog_segment = 4;
    optional CandidateResults embededi15 = 5;
}

message VoiceRecording {
    optional int32 record_interval = 3;
}

message RecogSegment {
    optional DisplayResult display = 1;
    optional int32 seg_time = 3;
}

message DisplayResult {
    optional string query = 1;
    optional double prob = 2;
}

message CandidateResults {
    optional CandidateResult can3 = 3;
    optional Empty can4 = 4;
}

message CandidateResult {
    repeated string query = 1; 
    repeated string queryWords = 12; 
    optional float res2 = 2;
    repeated CandidateInfo res7 = 7;
}

message CandidateInfo {
    optional CandidateInfoMore inf1 = 1;
}

message CandidateInfoMore {
    optional CandidateInfoMoreDetial more1 = 1;
    optional string more3 = 3;
}

message CandidateInfoMoreDetial {
    optional string type = 1;
    optional string detial2 = 2;
    optional float detial3 = 3;
    optional CandidateInfoMoreDetialSnip detial7 = 7;
    optional string detial8 = 8;
}

message CandidateInfoMoreDetialSnip {
    optional string query = 1;
}

message SearchResult {
    optional string header = 1;
    optional bytes bodyBytes = 3;
}

message TtsSound {
    optional bytes sound_data = 1;
    optional int32 fin_stream = 2;
    optional Empty code_rate = 3;
}

message Empty {
}

基于这个 .proto，对语音输入『北京天气』的 down 响应消息进行解码，最终的结果摘要如下：

$ more down.txt
######## Raw Data block info: offset=0x4 size=41
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=41
recog_block {
  voice_recording {
    record_interval: 140000
    1: 0
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0x31 size=61
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=61
recog_block {
  recog_result {
    recog_segment {
      display {
        query: "北"
        prob: 0.01
      }
      seg_time: 1500000
      2: 0
    }
    1: 0
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0x72 size=64
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=64
recog_block {
  recog_result {
    recog_segment {
      display {
        query: "北京"
        prob: 0.01
      }
      seg_time: 1560000
      2: 0
    }
    1: 0
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0xb6 size=67
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=67
recog_block {
  recog_result {
    recog_segment {
      display {
        query: "北京天"
        prob: 0.01
      }
      seg_time: 1980000
      2: 0
    }
    1: 0
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0xfd size=71
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=71
recog_block {
  recog_result {
    recog_segment {
      display {
        query: "北京天气"
        prob: 0.01
      }
      seg_time: 2100000
      2: 0
    }
    1: 0
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0x148 size=71
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=71
recog_block {
  recog_result {
    recog_segment {
      display {
        query: "北京天气"
        prob: 0.9
      }
      seg_time: 2700000
      2: 0
    }
    1: 0
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0x193 size=14
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=14
recog_block {
  voice_recording {
    1: 1
    2: 2100000
  }
}

######## Raw Data block info: offset=0x1a5 size=40
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=40
recog_block {
  voice_recording {
    1: 2
    2: 3570000
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0x1d1 size=491
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=484
recog_block {
  recog_result {
    can {
      can3 {
        query: "北京天气"
        query: "北京天気"
        query: "北京天器"
        res2: 0.9156357
        queryWords: "北 京 天 气"
        queryWords: "北 京 天 気"
        queryWords: "北 京 天 器"
        6: "\020\n\030\001"
      }
      1: 0
      2: 3570000
    }
    embededi15 {
      can3 {
        query: "北京天气"
        query: "北京天気"
        query: "北京天器"
        res2: 0.9156357
        res7 {
          inf1 {
            more1 {
              type: "literal"
              detial2: "北京天气"
              detial3: 1.0
              detial7 {
                query: "北京天气"
                2: 0
                3: 75
              }
              detial8: "北 京 天 气"
            }
            more3: ""
          }
        }
        res7 {
          inf1 {
            more1 {
              type: "literal"
              detial2: "北京天気"
              detial3: 1.0
              detial7 {
                query: "北京天気"
                2: 0
                3: 75
              }
              detial8: "北 京 天 気"
            }
            more3: ""
          }
        }
        res7 {
          inf1 {
            more1 {
              type: "literal"
              detial2: "北京天器"
              detial3: 1.0
              detial7 {
                query: "北京天器"
                2: 0
                3: 75
              }
              detial8: "北 京 天 器"
            }
            more3: ""
          }
        }
        queryWords: "北 京 天 气"
        queryWords: "北 京 天 気"
        queryWords: "北 京 天 器"
      }
      1: 0
      2: 3570000
    }
    1: 1
    2: 0
  }
  inputLang: "cmn-hans-cn"
  searchLang: "cmn-Hans-CN"
}

######## Raw Data block info: offset=0x3c0 size=29759
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=29759
search_result {
  header: "HTTP/1.1 200 OK
  Content-Type: application/x-protobuffer
  Date: Fri, 18 Mar 2016 08:28:17 GMT
  Expires: -1
  Cache-Control: no-store
  Set-Cookie: ******
  Trailer: X-Google-GFE-Current-Request-Cost-From-GWS
  Set-Cookie: ******
  Content-Disposition: attachment; filename=\"f.txt\"
  
  "
  bodyBytes: "\301R\n\026IbzrVsTgFsK0jwP1iY34CQ .... charset=UTF-8H\001"
  2: 1
  4: 0
}
## Bodybytes Proto: Textsearch.SearchResponse with Size=10561
search_id: "IbzrVsTgFsK0jwP1iY34CQ"
msg_type: 97000
result {
  fin_stream: 0
  text_data: "北京天气"
  html_data: "<!doctype html><html ......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
## Bodybytes Proto: Textsearch.SearchResponse with Size=16951
search_id: "IbzrVsTgFsK0jwP1iY34CQ"
result {
  fin_stream: 0
  html_data: "<style data-jiis=\"cc\" ......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
## Bodybytes Proto: Textsearch.SearchResponse with Size=1511
......

######## Raw Data block info: offset=0x7803 size=81
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=81
search_result {
  bodyBytes: "D\n\026IbzrVsTgFsK0jwP1iY34CQ\......"
  2: 1
  4: 0
}
## Bodybytes Proto: Textsearch.SearchResponse with Size=68
......

######## Raw Data block info: offset=0x7858 size=107685
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=107685
......

## Bodybytes Proto: Textsearch.SearchResponse with Size=103014
......
## Bodybytes Proto: Textsearch.SearchResponse with Size=2454
......
## Bodybytes Proto: Textsearch.SearchResponse with Size=2194
......

######## Raw Data block info: offset=0x21d01 size=8480
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=8480
......
## Bodybytes Proto: Textsearch.SearchResponse with Size=7260
......
## Bodybytes Proto: Textsearch.SearchResponse with Size=1202
......

######## Raw Data block info: offset=0x23e25 size=1615
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=1615
tts_sound {
  sound_data: "\377\363@\304\......"
  code_rate {
    1: 22050
  }
}

######## Raw Data block info: offset=0x24478 size=1609
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=1609
tts_sound {
  sound_data: "k\224ed4= \213......"
}

######## Raw Data block info: offset=0x24ac5 size=1609
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=1609
......

######## Raw Data block info: offset=0x25112 size=1609
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=1609
......

######## Raw Data block info: offset=0x2575f size=1609
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=1609
......

######## Raw Data block info: offset=0x25dac size=1518
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=1518
......

######## Raw Data block info: offset=0x2639e size=7
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=7
tts_sound {
  fin_stream: 1
}

######## Raw Data block info: offset=0x263a9 size=2
#### Proto: Voicesearch.VoiceSearchResponse Message with Size=2
fin_stream: 1

协议分析和启发

针对以上解码结果，对 Google App 语音搜索协议分析如下：

双向流式通信模式

上传音频采用流式方式，这个并不难想，但是识别结果、搜索结果和语音播报音频流全部在一个流里回传，需要做很多复杂的架构升级工作，带来的收益也是很明显的：

识别结果实时上屏。语音识别在解码时，需要收集到足够的语音流之后，才能识别出来文字，也就是说文字结果的出现时间比较随机。流式的识别结果下发能实现一旦有识别中间结果，就可以用最快的速度下发到 App 端展示给用户。
减少一次搜索请求开销。从逻辑上讲，应该先进行语音识别，再用识别出的 Query 发起搜索。但 Google 把这一步放在了服务端，不需要用户再发起一次搜索结果的 GET 请求。因为 Google Search 的域名和 locale 有关，新的 GET 请求可能需要发给 google.com.hk，这就需要 App 新建一个 HTTPS 连接，开销还是比较大的。而且服务器端还可以进一步优化，比如在识别出中间结果的同时请求即时搜索，不知道 Google 有没有做。
减少一次语音播报请求开销。原理同上
提升了 TCP 信道利用率。在同等传输数据量下，减少网络连接数，受 TCP 拥塞控制策略影响，TCP 信道的传输性能能得到一定提升。

录音小块回传

从 up 解码结果来看，Google App 音频流的是以固定每 300 字节一个封包，基于 AMR-WB 压缩这基本相当于 100ms 左右的录音。说明录音数据的上传还是很频繁的，这也能够让服务端尽早地识别出中间结果。还有就是，300字节的设计比较容易 fit in 1500 左右的以太网 MTU、576 的 3G、4G MTU。

搜索结果内置

搜索结果内置，其实相当于在服务器端『代理』App 发起一次内网搜索请求，那服务器端必须要知道正常的 App 请求参数是怎样的。所以在 App 端发起语音请求时，首先向服务器端传送了一些 App 端的配置信息，比如语言、地域、终端类型、用户偏好、搜索参数、搜索 Header 等。有了这些信息，服务器端就可以伪装成 App，通过内网发起搜索请求，获取搜索结果然后把结果内置到语音搜索结果里。但注意到中文语音搜索和文本搜索的域名不同，分别是 google.com 和 google.com.hk，在机房部署上如何高效地实现全球机房的高效内网访问，这仍然是个架构难题，这里无法窥知答案。

对文本搜索结果的分析我们了解到，Google App 的搜索结果是用 Protobuf Message 数组的方式下传的。但语音搜索并没有使用与文本搜索相同的数组元素 Message，所以文本搜索结果是以 bytes 方式，将序列化后的文本搜索 Message 放到语音搜索 Message 中的一个字段中。这也许是为了协议解耦，避免单方面协议改动带来的同步问题。但可能是基于效率考虑，多个文本搜索 Message 可能会被放到同一个语音搜索 Message 中，也是以 Dilimited List 的方式序列化后放入。语音搜索模块解码出来 bytes 之后，可以直接塞给文本搜索的渲染模块渲染，与文本搜索接收的协议格式完全相同。

语音播报

语音播报的音频也是以流式下传，这样可以边播边收，也有效率优势。

Google App API Protocol - Text Search

Google App API Protocol - Text Search
Google App API Protocol - Voice Search
Google App API Protocol - Search History

HTTPS 抓包分析

Google Service 已经全面普及了 HTTPS 接入，所以想探索 Google 的通讯协议，首先必备的是 HTTPS 抓包能力。所谓的 HTTPS 抓包，实质上是通过代理服务器实现对测试手机上 HTTPS 连接的中间人攻击，所以必须在测试手机上安装代理服务器的 CA 证书，才能保证测试手机相信 HTTPS 连接是安全的。

有很多测试用代理服务器支持 HTTPS 抓包，例如 Fiddler 和 Charles，HTTPS 配置具体可以参见它们的官方文档：Configure Fiddler to Decrypt HTTPS Traffic 和 SSL CERTIFICATES.

文本 IS 请求

Google App 上的文本搜索请求，并不一定以用户按下搜索按钮才开始，而是在输入过程中就可能发生，类似于 Instant Search 即时搜索。这一切发生在输入文本过程中的 "/s?" 请求内。

Google 在接口上，已经将搜索推荐和即时搜索合二为一，通过发起对 "https://www.google.com[.hk]/s?" 的 GET 请求，根据用户已经输入的短语，获取搜索推荐词。如果 Google 认为用户已经完成输入，它会在这个请求的应答消息中直接返回搜索结果。

以小米手机上安装的 Google App 为例，当用户输入『上海』这个词时，GET 请求的参数，主要有以下这些：

noj	1
q	上海
tch	6
ar	0
br	0
client	ms-android-xiaomi
hl	zh-CN
oe	utf-8
safe	images
gcc	cn
ctzn	Asia/Shanghai
ctf	1
v	5.9.33.19.arm
biw	360
bih	615
padt	200
padb	640
ntyp	1
ram_mb	870
qsd	3670
qsubts	1458723210129
wf	pp1
action	devloc
pf	i
sclient	qsb-android-asbl
cp	2
psi	bLxzwaswPFc.1458723200693.3
ech	2
gl	us
sla	1

请求的 HTTP Header，主要有以下这些：

Connection	keep-alive
Cache-Control	no-cache, no-store
Date	Wed, 23 Mar 2016 08:53:26 GMT
X-Client-Instance-Id	c6aef75ce70631e9518ae8e7011bb3d7957b24d59b62f...
Cookie	******
X-Geo	w CAEQDKIBBTk6MTox
X-Client-Opt-In-Context	H4sIAAAAAAAAAONi4WAWYBD4DwOMUiwcj...
X-Client-Discourse-Context	H4sIAAAAAAAAAB1PS07DMBSUehe...
X-Client-Data	CM72hgQIjfeGBAiP94YECKj4hgQIy...
User-Agent	Mozilla/5.0 (Linux; Android 4.4.4; HM 1S Build/KTU84P)
 AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Mobile
 Safari/537.36 GSA/5.9.33.19.arm
Accept-Encoding	gzip, deflate, sdch

文本 IS 应答消息解码

文本 IS 应答消息的 HTTP Header 如下所示：

HTTP/1.1 200 OK
Content-Type	application/x-protobuffer
Date	Wed, 23 Mar 2016 08:56:47 GMT
Expires	-1
Cache-Control	no-store
Content-Disposition	attachment; filename="f.txt"
Content-Encoding	gzip
Server	gws
X-XSS-Protection	1; mode=block
X-Frame-Options	SAMEORIGIN
Alternate-Protocol	443:quic,p=1
Alt-Svc	quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
Transfer-Encoding	chunked

这里最值得关注的，是 Content-Type。application/x-protobuffer 不是一个常见的 Media Type，起初我以为它就是简单的 protobuffer message 序列化二进制内容，搜索到的一些信息也是这样说的，但用 protobuf 对其 Decode，并不能正确解析消息体。后来我还是在 Charles 的这篇文档中找到了思路，其实 application/x-protobuffer 在实现时区分单个消息和多个消息的格式（但 Content-Type 里并不显式说明）。多个消息，即 Dilimited List，的封包协议是这样的：

(Varint of Msg Len)(Msg)(Varint of Msg Len)(Msg)...(Varint of Msg Len)(Msg)EOF

解包时也很简单，Protobuf 的 Java 库提供了 Message.Builder.mergeDelimitedFrom(...) 来直接从 InputStream 里循环读取多个 Message 的封包数据。

但这时候我们还不知道应答消息里的 protobuf Message 格式，无法构建 Message 的 Builder。这时候有个简单的办法去逐步推导，也就是新建一个 Empty Message，如下所示：

$ more textsearch.proto
message Empty {}

用这个 Empty Message 构建 Builder，对 IS 的应答消息进行 Decode，将 Decode 结果打印出来时会发现所有的字段都是无名字段。然后根据对 protobuf wire data 的理解，逐步推导它的 Message 格式，尽最大的努力去猜测各个字段的作用，最终推导出来 IS 应答消息的 .proto 可能是这样的：

$ more textsearch.proto
package com.google.search.app;

message SearchResponse {
    required string search_id = 1;
    optional uint32 msg_type = 4;
    optional SearchResultPart sug = 100;
    optional SearchResultPart result = 101;
    optional Empty SR102 = 102;
}

message SearchResultPart {
    optional uint32 fin_stream = 1;
    optional string text_data = 2;
    optional string html_data = 7;
    optional string encoding = 8;
}

message Empty {
}

基于这个 .proto，对 Query 『上海天气』 IS 的应答消息进行 Decode，最终的结果摘要如下：

$ more s.txt
#### Proto: Textsearch.SearchResponse with Size=758
search_id: "iVnyVrChHsTAjwPdh4PwBA"
msg_type: 97000
sug {
  fin_stream: 1
  text_data: "[\"上海天气\",[[\"上海天气\",35,[39,70],......}]"
}

#### Proto: Textsearch.SearchResponse with Size=10561
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
msg_type: 97000
result {
  fin_stream: 0
  text_data: "上海天气"
  html_data: "<!doctype html><html itemscope=\"\" ......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
#### Proto: Textsearch.SearchResponse with Size=16951
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: "<style data-jiis=\"cc\" id=\"gstyle\">......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
#### Proto: Textsearch.SearchResponse with Size=1511
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: "<title>上海天气 - Google 搜索</title></head><body ......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
#### Proto: Textsearch.SearchResponse with Size=68
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: ""
  encoding: "text/html; charset=UTF-8"
  3: 0
  9: 1
}
SR102 {
  1: 1
  4: ""
}
#### Proto: Textsearch.SearchResponse with Size=104557
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: "<div data-jiis=\"cc\" id=\"doc-info\">......</script>"
  encoding: "text/html; charset=UTF-8"
  4: 8
  4: 10
  4: 6
  4: 13
  4: 12
  4: 2
  4: 21
  4: 20
  9: 1
  10: 1
}
#### Proto: Textsearch.SearchResponse with Size=2198
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: "<script>google.y.first.push(function()......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
#### Proto: Textsearch.SearchResponse with Size=2146
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: "<script>......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
#### Proto: Textsearch.SearchResponse with Size=7261
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 0
  html_data: "<script>......</script>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}
#### Proto: Textsearch.SearchResponse with Size=1202
search_id: "iVnyVsnMH8TAjwPdh4PwBA"
result {
  fin_stream: 1
  html_data: " <div id=\"main-loading-icon\" ......</div></body></html>"
  encoding: "text/html; charset=UTF-8"
  9: 1
}

观察到 sug_data 看似是 JSON 格式的数据，专门对 sug_data 进行 JSON Decode，得到以下结果：

## JSONArray: sug_data ##
[
  "上海天气",
  [
    [
      "上海天气",
      35,
      [
        39,
        70
      ],
      {
        "ansc": "1458723207451",
        "ansb": "2338",
        "du": "/complete/deleteitems?client=qsb-android-asbl&delq=上海天气
               &deltok=AKtL3uTL0hK_EMlKCgutzvQvzXfh2VRAgg",
        "ansa": {"l": [
          {"il": {"t": [{
            "tt": 13,
            "t": "上海天气"
          }]}},
          {"il": {
            "at": {
              "tt": 12,
              "t": "周三"
            },
            "t": [
              {
                "tt": 1,
                "t": "54"
              },
              {
                "tt": 3,
                "t": "°F"
              }
            ],
            "i": {
              "d": "//ssl.gstatic.com/onebox/weather/128/partly_cloudy.png",
              "t": 3
            }
          }}
        ]},
        "zc": 602
      }
    ],
    [
      "上海天气<b>预报<\/b>",
      0,
      [],
      {"zc": 601}
    ],
    [
      "上海天气<b>预报10天<\/b>",
      0,
      [],
      {"zc": 600}
    ],
    [
      "上海天气<b>预报15天<\/b>",
      0,
      [],
      {"zc": 551}
    ]
  ],
  {
    "q": "W9D2ISTC-TXK4QauyTt2SFqJzvo",
    "n": 0
  }
]

非 IS 搜索请求和搜索应答解码

当 IS 应答消息里有搜索结果时，点击搜索按钮不会再发起一次搜索。但如果 IS 应答只有 SUG，没有搜索结果，Google App 就会发起一次非 IS 的正常搜索请求。这次请求除了请求的 URL path 从 "/s" 变成 "/search" 以外，主要的 GET 参数保持一致，会有部分附加参数的不同。以『上海天气』（有 IS 结果）和『上海天气好不好呢』（无 IS 结果）为例，GET 参数有以下区别：

-qsd	3670
-pf	i
-sclient	qsb-android-asbl
-cp	4
-psi	bLxzwaswPFc.1458723200693.3
-ech	3
-gl	us
-sla	1
+gs_lp	EhBxc2ItYW5kcm9pZC1h...
+source	and/assist
+entrypoint	android-assistant-query-entry

而非 IS 搜索应答和 IS 应答对比，区别主要在于非 IS 搜索应答消息中，没有搜索词 SUG Message 包。

协议分析和启发

请求消息协议

搜索请求是通过 GET 协议实现的，所以请求主要分为两部分：HTTP 头和 GET 参数。从请求上来看，Google 对 GET 参数的使用是非常节省的，很多字段都是极其精简的缩写。但它倒是在 HTTP 头里放了很多比较大的数据字段，从 Header 名来猜测，应该是跟设备、登录用户相关的一些加密字段。

因为搜索请求是 App 发出的，所以理论上 GET 请求和 POST 请求的实现难度是差不多的，POST 的时候可以进行数据压缩，Header 倒是不能压缩（HTTP 1.x）。那为什么 Google 反而选择把这么长的数据放在 HTTP Header 里呢？我的猜测是为了充分利用 HTTP/2 的特性。在 HTTP/2 里有个特性，叫做 Header Compression，在多次请求时，同一个 Header 原文仅需要压缩传输一次即可。但由于现在还没有 HTTP/2 的抓包工具，所以还无法判断 Google App 是已经用上了这个特性，还是为未来的使用做好准备。不过这至少给了我们一个启发，为了充分利用底层协议的特性，应用层约定可能也需要一些适配工作。

应答消息协议

Google App 的搜索结果，并没有像普通网站服务一样，直接用标准的 HTML 协议返回一个 Web Page。而是将渲染好的 Web Page 分段放到应答消息中，由 App 端提取、拼接成最终的搜索结果页。猜测有以下几点考虑：

便于与 SUG 服务集成。很多搜索框都提供 Sug 功能，但 Google 为了让用户感觉更快，在输入过程中不仅有 Sug，还会直接显示搜索结果，桌面版上叫做『即时搜索』。移动版 App 的做法跟桌面版类似，但实现上有不同的地方。移动 App 的输入框不是 HTML 的 <input> 标签，而是一个系统原生的输入框，所以无法依赖 Javascript 去响应事件，刷新结果页。而且网络请求是 App 发起的，为了充分利用网络连接，将搜索结果集成到 SUG 结果里也是顺理成章的事情。不过这还意味着在 App 上，不能仅返回数据通过 Ajax 技术无缝刷新结果页，必须得在消息里返回整个搜索结果页。
减少解码内存使用，改善性能。如果将整个搜索结果页放到一个 Protobuf Message 中，客户端为了解码这个消息，需要申请很大一块内存。而在移动设备上，内存是很 critical 的资源，尤其是在 Android 设备上，使用大块内存会导致频繁的 GC，性能很差。
模拟 Chunked 编码。Web 服务器可以通过 HTTP 1.1 引入的 Chunked transfer encoding 将网页分块传输给浏览器，浏览器无需等待网页传输结束，就能够开始页面渲染。当网页通过 Protobuf Message 传输时，无法利用浏览器的 chunked 处理技术，只好用分拆为多个 Message 的方式模拟 chunked 模式。虽然 Android 原生的 Webview 并没有支持 chunked 的 LoadData 接口，相信 Google 自己的 App 实现一个类似功能并不困难。

但 Google 这种直接下发网页数据的做法，也存在一个问题，就是没有合法的网页 URL。合法的网页 URL，有以下几个潜在的作用，Google App 做了一些额外的工作来处理：

刷新页面。Google App 没有提供页面刷新功能；
前进后退。Google App 没有提供前进后退功能，而是通过 Search History 来满足后退功能。
浏览历史。Google App 没有提供浏览历史，只提供了搜索历史。
页面分享。Google App 没有提供页面分享功能。

Android 版本的 Google App 连搜索结果都需要用第三方浏览器打开，结合上述功能处理，可以发现 Android 版本 Google App 只是想做一个精悍的搜索应用，无意于把自己变成一个完善的浏览器。但 iOS 版本 Google App 对上述问题的处理略有不同，iOS 版本内置了一个浏览器，搜索结果可以在 App 内打开。但主要的搜索结果页，仍然是采用类似于 Android 的方式处理。也就是说，iOS 版本的浏览器，可能仅仅是一个 UIWebview。