两岸风景

两岸风景 查看完整档案

南京编辑东南大学  |  计算机科学与技术 编辑腾讯科技(深圳)有限公司  |  Android开发 编辑 www.my404.club 编辑
编辑

I am NaOH

个人动态

两岸风景 关注了用户 · 2018-01-19

jasminecjc @jasminecjc

关注 37

两岸风景 发布了文章 · 2017-11-20

Android调试神器stetho使用详解和改造

概述


stetho是Facebook开源的一个Android调试工具,项目地址:facebook/stetho
通过Stetho,开发者可以使用chrome的inspect功能,对Android应用进行调试和查看。 功能概述

stetho提供的功能主要有:

  • Network Inspection:网络抓包,如果你使用的是当前流行的OkHttp或者Android自带的 HttpURLConnection,你可以轻松地在chrome inspect窗口的network一栏抓到所有的网络请求和回包,还用啥Postman,还用啥Fiddler哦(开个玩笑,一些场合还是需要用的,毕竟Stetho Network Inspection 只是用来查看回报和发送数据是否有误,在开发初期,调试API还是用Postman快一点)
  • Database Inspection:数据库查看,可以直接看到当前应用的sqlite数据库,而且是可视化的,不需要再下什么奇怪的工具或者用命令行看了。这个确实非常棒!
  • View Hierarchy:布局层级查看,免去使用查看布局边界的花花绿绿带来的痛苦和卡顿,而且能看到每个view和layout的各类属性。
  • Dump App:命令行拓展,构造了一个命令行与Android App的交互通道,在命令行输入一行命令,App可以收到并且在命令行上进行反馈输出。
  • Javascript Console:Javascript控制台,在inspect的console窗口,输入Javascript可以直接进行Java调用。使用这个功能,得先引入facebook/stethostetho-js-rhino和mozilla/rhino。

在这里,笔者先承认这个文章有点标题党了——在我实际使用体验过后,第一感觉是:这个所谓神器也没有特别神的感觉…造成首次使用感觉不太好的原因在于:

  • 使用教程不太全,尤其是Dump App的使用,不管是在README还是wiki中都没有太多的叙述。
  • Network Inspection 抓包只封装了OkHttp和HttpURLConnection的,然而大多数情况下,各个应用开发者可能都会有自己的一套网络请求库,它提供的接口这时候就不太友好了,得自己包装一下。
  • View Hierarchy 用起来有一丝丝的不方便,因为调试视图还包括了Android系统自带的状态栏布局之类的,导致Activity的布局天然处于一个比较深的节点,每次还要手动一层一层展开(其实这里有一个技巧,后面会提到)。
  • Javascript Console 感觉是最鸡肋的功能,因为自带的console只能关联到application的context,能进行的操作非常有限,且在控制台写js调用Java层的函数是没有自动补全的,容易写错不说,要换成Js的语法也是相当费劲。就算解决这几个问题,也还是想不到什么合适的使用场景。

后面将会对Dump App和Network Inspection进行详细介绍(其他的几个功能都比较简单)。

初始化Stetho

首先引入在安卓项目中引用必要的依赖包,可以使用gradle,也可以直接下载jar包。

dependencies { 
    compile 'com.facebook.stetho:stetho:1.5.0' 
} 

需要注意的是如果使用Javascript Console需要额外引入facebook/stethostetho-js-rhino和mozilla/rhino。
然后在应用的Application初始化时,进行Stetho初始化。这些都在官网有详细的说明,不再赘述了。

开始使用

由于大部分功能依赖于Chrome DevTools
所以第一步你需要先打开Chrome,然后在浏览器地址栏输入:chrome://inspect
接触过前端开发或者Webview开发的捧油应该是很熟悉这个套路了。你会看到一个如下界面:
v2-47a55a2f2dbb00136d33c4b9b9d25446_b.jpg

inspect界面

v2-6ccfc4a0183c5acfc201d91b0d41db3a_b.jpg
你会发现这里有两项,是因为我的这个示例应用有两个进程。由于App的每个进程都会单独创建一个Application,所以在应用包含多个进程时,Stetho也会为每个进程都初始化一次。那么这里我要调试的是主进程,就点击第一项inspect就行了。
接下来我们就开始搞事情了:

View Hierarchy

查看布局层级没啥好说的,但是之前提到,由于系统的view层级也包括进来了,所以我们Activity的Layout层级都很深,每次一层一层点开很难找,这里提供一个简便方法,在Elements面板,按Ctrl + F,搜索 @android:id/content 即可快速定位到我们当前界面根布局,例如这里的Constraintlayout:

v2-6ccfc4a0183c5acfc201d91b0d41db3a_b.jpg

Database Inspection

点击Resource-Web SQL即可查看App的数据库:

v2-cedc7998f9064c780d2d092e0808e141_b.jpg

Javascript Console

在Console面板,输入context可以看到目前的ApplicationContext:

v2-36da6e653dec238edf875d46222c147f_b.jpg
输入如下代码弹出Toast:

importPackage(android.widget);
importPackage(android.os);
var handler = new Handler(Looper.getMainLooper());
handler.post(function() { Toast.makeText(context, "Hello from JavaScript", Toast.LENGTH_LONG).show() });

应用场景比较有限,但是mozilla/rhino这个Javascript引擎倒是挺有意思的,可以用来做一些有趣的事情,以后有机会再分享一下。

Dump App

官方对dump app的使用说明实在太少了,感觉非常捉急。研究了一番,大概知道了使用流程,即首先需要在App内,通过enableDumpapp方法注册自己的插件:
Stetho.initialize(Stetho.newInitializerBuilder(context)

.enableDumpapp(new DumperPluginsProvider() {
  @Override
  public Iterable<DumperPlugin> get() {
    return new Stetho.DefaultDumperPluginsBuilder(context)
        .provide(new MyDumperPlugin())
        .finish();
  }
})
.enableWebKitInspector(Stetho.defaultInspectorModulesProvider(context))
.build())

也可以使用默认的插件:
Stetho.initialize(Stetho.newInitializerBuilder(this)

            .enableDumpapp(new DumperPluginsProvider() {
                public Iterable<DumperPlugin> get() {
                    return (new Stetho.DefaultDumperPluginsBuilder(StethoNetworkApplication.this)).finish();
                }
            }).enableWebKitInspector(Stetho.defaultInspectorModulesProvider(context))
.build())

然后,stetho的github项目地址下有一个script文件夹:facebook/stetho-script
把这个文件夹下到本地,发现里面有几个文件:
.gitignore
dumpapp
hprof_dump.sh
stetho_open.py
说实话第一眼看上去根本不知道这东西干啥用的,dumpapp这文件看起来就跟可执行文件似的,但事实上它又不是exe,用记事本打开一看,是Python3的文件,我也是醉了…

v2-99c6adbe9d074b479ba581e701610d62_b.jpg

所以使用Python3.x来运行这个文件即可。(由于他还引用了stetho_open.py,为了看起来不那么别扭,我把几个文件都整合在一齐,搞了一个dump.py)
这里我并没有注册任何插件,但是由于Stetho自带了几个插件,我们可以看看他们的实现:

例如files插件,来试用一下:

v2-9a91983cafaed29dae468d9c9ae423d9_b.jpg

即用户发送命令时,Plugin的dump方法会被调用,Plugin通过dumpContext.getStdout()来获取输出流,将反馈输出到命令行:

public void dump(DumperContext dumpContext) throws DumpException {
        Iterator<String> args = dumpContext.getArgsAsList().iterator();
        String command = ArgsHelper.nextOptionalArg(args, "");
        if("ls".equals(command)) {
            this.doLs(dumpContext.getStdout());
        } else if("tree".equals(command)) {
            this.doTree(dumpContext.getStdout());
        } else if("download".equals(command)) {
            this.doDownload(dumpContext.getStdout(), args);
        } else {
            this.doUsage(dumpContext.getStdout());
            if(!"".equals(command)) {
                throw new DumpUsageException("Unknown command: " + command);
            }
        }

    }

Network Inspection

其实这也是重点之一了。我在这里添加了一个OkHttp的Inspector。
注意:此处有坑,因为你会发现用gradle添加的stetho依赖中没有StethoInterceptor这个类,你可以到stetho的github页面下载一下,同事需要跟你的OkHttp版本对应,因为2.x跟3.x对应的StethoInterceptor还有差异):
下载地址:
facebook/stetho-okhttp3
facebook/stetho-okhttp
代码示例如下:
public void testOkHttp(){

Thread thread = new Thread(new Runnable() {
    @Override
    public void run() {
        String url = "http://www.zhihu.com/";
        OkHttpClient.Builder builder = new OkHttpClient.Builder()

.addNetworkInterceptor(new StethoInterceptor());

        OkHttpClient client = builder.build();
        Request request = new Request.Builder()
                .url(url)
                .get()
                .build();
        try {

            Response response = client.newCall(request).execute();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
});
thread.start();

}

运行这个函数,可以看到Network一栏的请求,每项网络请求发出时,Status处于Pending状态,收到回包后,Status等栏目都会变化,展示httpcode,请求耗时、回包数据类型等信息。

v2-cdb592459d693e2b937dae2b252fa8d4_b.jpg
v2-48246d6d7b44a215a1958ab60f19aeb7_b.jpg

当然这不是重点。重点是我们要对这个东西改造一下,他是如何抓下包来发送给Chrome的呢?
看一下StethoInterceptor的intercept函数,写了些注释:

private final NetworkEventReporter mEventReporter = 
    NetworkEventReporterImpl.get();
public Response intercept(Chain chain) throws IOException {
    // 构造一个独特的eventID,一对网络事件(请求和回包)对应一个eventID
    String requestId = mEventReporter.nextRequestId();

    Request request = chain.request();
    
    // 准备发送请求
    RequestBodyHelper requestBodyHelper = null;
    if (mEventReporter.isEnabled()) {
      requestBodyHelper = new RequestBodyHelper(mEventReporter, requestId);
      OkHttpInspectorRequest inspectorRequest =
          new OkHttpInspectorRequest(requestId, request, requestBodyHelper);
      // 请求即将发送,构造一个OkHttpInspectorRequest,报告给Chrome,此时Network会显示一条请求,处于Pending状态
      mEventReporter.requestWillBeSent(inspectorRequest);
    }

    Response response;
    try {
      // 发送请求,获得回包
      response = chain.proceed(request);
    } catch (IOException e) {
      // 如果发生了IO Exception,则通知Chrome网络请求失败了,显示对应的错误信息
      if (mEventReporter.isEnabled()) {
        mEventReporter.httpExchangeFailed(requestId, e.toString());
      }
      throw e;
    }

    if (mEventReporter.isEnabled()) {
      if (requestBodyHelper != null && requestBodyHelper.hasBody()) {
        requestBodyHelper.reportDataSent();
      }

      Connection connection = chain.connection();
      
      // 回包的header已收到,构造一个OkHttpInspectorResponse,发送给Chrome用于展示
      mEventReporter.responseHeadersReceived(
          new OkHttpInspectorResponse(
              requestId,
              request,
              response,
              connection));

      // 展示回包信息
      ResponseBody body = response.body();
      MediaType contentType = null;
      InputStream responseStream = null;
      if (body != null) {
        contentType = body.contentType();
        responseStream = body.byteStream();
      }

      responseStream = mEventReporter.interpretResponseStream(
          requestId,
          contentType != null ? contentType.toString() : null,
          response.header("Content-Encoding"),
          responseStream,
          new DefaultResponseHandler(mEventReporter, requestId));
      if (responseStream != null) {
        response = response.newBuilder()
            .body(new ForwardingResponseBody(body, responseStream))
            .build();
      }
    }

    return response;
  }

所以整个流程我们可以简化为:发送请求时,给Chrome发了条消息,收到请求时,再给Chrome发条消息(具体怎么发的可以看NetworkEventReporterImpl的实现)
两条消息通过EventID联系起来,它们的类型分别是OkHttpInspectorRequest 和 OkHttpInspectorResponse,两者分别继承自NetworkEventReporter.InspectorRequest和NetworkEventReporter.InspectorResponse。我们只要也继承自这两个类,在自己的网络库发送和收到请求时,构造一个Request和Response并发送给Chrome即可。
发送部分示例:

PulseInspectorRequest 继承自NetworkEventReporter.InspectorRequest
   public void reportRequestSend(PulseInspectorRequest request){
        String requestId = request.id();

        // request will be sent
        RequestBodyHelper requestBodyHelper = null;
        if (mEventReporter.isEnabled()) {
            requestBodyHelper = new RequestBodyHelper(mEventReporter, requestId);
            mEventReporter.requestWillBeSent(request);

            // report request send
            if (requestBodyHelper.hasBody()) {
                requestBodyHelper.reportDataSent();
            }
        }

    }

回包获取成功:

public void reportRequestSuccess(PulseInspectorResponse response){
    mEventReporter.responseHeadersReceived(response);
    mEventReporter.responseReadFinished(response.requestId());

    String requestId = response.requestId();
    String contentType = "application/json";
    String encoding = null;
    InputStream responseStream = new ByteArrayInputStream(response.getResponseBody().getBytes());

    InputStream responseHandlingInputStream = mEventReporter.interpretResponseStream(
            requestId,
            contentType,
            encoding,
            responseStream,
            new DefaultResponseHandler(mEventReporter, requestId));
    try {
        if (responseHandlingInputStream == null) return;
        // 重点在这,这两行代码一定要加上,StethoInterceptor之所以不需要加,
        // 是因为OkHttp本身对请求采取了职责链式的处理,
        // 虽然在StethoInterceptor的intercept函数里没有进行read和close
        // 但是后续的Interceptor会进行这个操作,实际上这里,才把回包数据发送给了Chrome
        responseHandlingInputStream.read(response.getResponseBody().getBytes());
        responseHandlingInputStream.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

回包获取失败

public void reportRequestFail(String eventId,String errMsg){
        mEventReporter.httpExchangeFailed(eventId, errMsg);
}

至于PulseInspectorResponse 和PulseInspectorRequest如何实现,就依赖实际使用场景了。

总结

stetho 为开发者提供了一个很好的调试手段,但是自带的基础功能还比较弱,开发者可以根据自己的需求去改造。(不过官网文档是有点太少了……)
如果说这个工具有啥亮点,想来想去,大概App跟Chrome的通信,火狐的rhino引擎更可以被称之为亮点= .=|||3

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/dev...

查看原文

赞 7 收藏 7 评论 0

两岸风景 赞了文章 · 2017-11-02

如何快速将 '*' 重复 9 次?

如果是将 '*' 重复 8 次,一下子就可以想到这种快速算法:

  1. '*' + '*' => '**'
  2. '**' + '**' => '****'
  3. '****' + '****' => Bingo!

JavaScript 代码实现:

var n = 8;
var str = '*';
while ((n >>>= 1) > 0) {
  str += str;
}
console.log(str);

同样的算法可用于 16 次、32 次、64 次、1024 次...


但是如果是要求重复 9呢?这就需要调整一下上述的算法。

先抽象出一个函数 repeat: (str: string, n: number) => string:

  • repeat('*', 3) => '***'
  • repeat('ab', 1) => 'ab'
  • repeat('abcd', 0) => ''
  • ...

然后开始分析:

  1. n 为偶数时:

    • repeat(str, n) <= repeat(str, n >>> 1) + repeat(str, n >>> 1)
    • 比如:repeat('abc', 12) <= repeat('abc', 6) + repeat('abc', 6)
  2. n 为奇数时,即 n - 1 为偶数:

    • repeat(str, n) <= str + repeat(str, n - 1)
    • 比如:repeat('*', 21) <= '*' + repeat('*', 20)
  3. n1 时:repeat(str, 1) <= str
  4. n0 时:repeat(str, 0) <= ''

JavaScript 代码实现:

function repeat(str/*:string*/, n/*:number*/) {
  if (n === 0) return '';
  if (n === 1) return str;
  // `n` 为奇数
  if (n % 2) return str + repeat(str, n - 1);

  // `n` 为偶数,
  // 但是要把 `repeat(str, n >>> 1)` 缓存起来,
  // 以避免重复两次计算
  return (str = repeat(str, n >>> 1)) + str;
}








查看原文

赞 5 收藏 17 评论 10

两岸风景 赞了文章 · 2017-09-25

传统 Ajax 已死,Fetch 永生

image

原谅我做一次标题党,Ajax 不会死,传统 Ajax 指的是 XMLHttpRequest(XHR),未来现在已被 Fetch 替代。

最近把阿里一个千万级 PV 的数据产品全部由 jQuery 的 $.ajax 迁移到 Fetch,上线一个多月以来运行非常稳定。结果证明,对于 IE8+ 以上浏览器,在生产环境使用 Fetch 是可行的。

由于 Fetch API 是基于 Promise 设计,有必要先学习一下 Promise,推荐阅读 MDN Promise 教程。旧浏览器不支持 Promise,需要使用 polyfill es6-promise

本文不是 Fetch API 科普贴,其实是讲异步处理和 Promise 的。Fetch API 很简单,看文档很快就学会了。推荐 MDN Fetch 教程 和 万能的WHATWG Fetch 规范

Why Fetch

XMLHttpRequest 是一个设计粗糙的 API,不符合关注分离(Separation of Concerns)的原则,配置和调用方式非常混乱,而且基于事件的异步模型写起来也没有现代的 Promise,generator/yield,async/await 友好。

Fetch 的出现就是为了解决 XHR 的问题,拿例子说明:

使用 XHR 发送一个 json 请求一般是这样:

var xhr = new XMLHttpRequest();
xhr.open('GET', url);
xhr.responseType = 'json';

xhr.onload = function() {
  console.log(xhr.response);
};

xhr.onerror = function() {
  console.log("Oops, error");
};

xhr.send();

使用 Fetch 后,顿时看起来好一点

fetch(url).then(function(response) {
  return response.json();
}).then(function(data) {
  console.log(data);
}).catch(function(e) {
  console.log("Oops, error");
});

使用 ES6 的 箭头函数 后:

fetch(url).then(response => response.json())
  .then(data => console.log(data))
  .catch(e => console.log("Oops, error", e))

现在看起来好很多了,但这种 Promise 的写法还是有 Callback 的影子,而且 promise 使用 catch 方法来进行错误处理的方式有点奇怪。不用急,下面使用 async/await 来做最终优化:

注:async/await 是非常新的 API,属于 ES7,目前尚在 Stage 1(提议) 阶段,这是它的完整规范。使用 Babel 开启 runtime 模式后可以把 async/await 无痛编译成 ES5 代码。也可以直接使用 regenerator 来编译到 ES5。

try {
  let response = await fetch(url);
  let data = response.json();
  console.log(data);
} catch(e) {
  console.log("Oops, error", e);
}
// 注:这段代码如果想运行,外面需要包一个 async function

duang~~ 的一声,使用 await 后,写异步代码就像写同步代码一样爽await 后面可以跟 Promise 对象,表示等待 Promise resolve() 才会继续向下执行,如果 Promise 被 reject() 或抛出异常则会被外面的 try...catch 捕获。

Promise,generator/yield,await/async 都是现在和未来 JS 解决异步的标准做法,可以完美搭配使用。这也是使用标准 Promise 一大好处。最近也把项目中使用第三方 Promise 库的代码全部转成标准 Promise,为以后全面使用 async/await 做准备。

另外,Fetch 也很适合做现在流行的同构应用,有人基于 Fetch 的语法,在 Node 端基于 http 库实现了 node-fetch,又有人封装了用于同构应用的 isomorphic-fetch

注:同构(isomorphic/universal)就是使前后端运行同一套代码的意思,后端一般是指 NodeJS 环境。

总结一下,Fetch 优点主要有:

  1. 语法简洁,更加语义化

  2. 基于标准 Promise 实现,支持 async/await

  3. 同构方便,使用 isomorphic-fetch

Fetch 启用方法

下面是重点↓↓↓

先看一下 Fetch 原生支持率:
image

原生支持率并不高,幸运的是,引入下面这些 polyfill 后可以完美支持 IE8+ :

  1. 由于 IE8 是 ES3,需要引入 ES5 的 polyfill: es5-shim, es5-sham

  2. 引入 Promise 的 polyfill: es6-promise

  3. 引入 fetch 探测库:fetch-detector

  4. 引入 fetch 的 polyfill: fetch-ie8

  5. 可选:如果你还使用了 jsonp,引入 fetch-jsonp

  6. 可选:开启 Babel 的 runtime 模式,现在就使用 async/await

Fetch polyfill 的基本原理是探测是否存在 window.fetch 方法,如果没有则用 XHR 实现。这也是 github/fetch 的做法,但是有些浏览器(Chrome 45)原生支持 Fetch,但响应中有中文时会乱码,老外又不太关心这种问题,所以我自己才封装了 fetch-detectorfetch-ie8 只在浏览器稳定支持 Fetch 情况下才使用原生 Fetch。这些库现在每天有几千万个请求都在使用,绝对靠谱

终于,引用了这一堆 polyfill 后,可以愉快地使用 Fetch 了。但要小心,下面有坑:

Fetch 常见坑

  • Fetch 请求默认是不带 cookie 的,需要设置 fetch(url, {credentials: 'include'})

  • 服务器返回 400,500 错误码时并不会 reject,只有网络错误这些导致请求不能完成时,fetch 才会被 reject。

竟然没有提到 IE,这实在太不科学了,现在来详细说下 IE

IE 使用策略

所有版本的 IE 均不支持原生 Fetch,fetch-ie8 会自动使用 XHR 做 polyfill。但在跨域时有个问题需要处理。

IE8, 9 的 XHR 不支持 CORS 跨域,虽然提供 XDomainRequest,但这个东西就是玩具,不支持传 Cookie!如果接口需要权限验证,还是乖乖地使用 jsonp 吧,推荐使用 fetch-jsonp。如果有问题直接提 issue,我会第一时间解决。

标准 Promise 的不足

由于 Fetch 是典型的异步场景,所以大部分遇到的问题不是 Fetch 的,其实是 Promise 的。ES6 的 Promise 是基于 Promises/A+ 标准,为了保持简单简洁,只提供极简的几个 API。如果你用过一些牛 X 的异步库,如 jQuery(不要笑) 、Q.js 或者 RSVP.js,可能会感觉 Promise 功能太少了。

没有 Deferred

Deferred 可以在创建 Promise 时可以减少一层嵌套,还有就是跨方法使用时很方便。
ECMAScript 11 年就有过 Deferred 提案,但后来没被接受。其实用 Promise 不到十行代码就能实现 Deferred:es6-deferred。现在有了 async/await,generator/yield 后,deferred 就没有使用价值了。

没有获取状态方法:isRejected,isResolved

标准 Promise 没有提供获取当前状态 rejected 或者 resolved 的方法。只允许外部传入成功或失败后的回调。我认为这其实是优点,这是一种声明式的接口,更简单。

缺少其它一些方法:always,progress,finally

always 可以通过在 then 和 catch 里重复调用方法实现。finally 也类似。progress 这种进度通知的功能还没有用过,暂不知道如何替代。

最后

Fetch 替换 XHR 只是时间问题,现在看到国外很多新的库都默认使用了 Fetch。

最后再做一个大胆预测:由于 async/await 这类新异步语法的出现,第三方的 Promise 类库会逐渐被标准 Promise 替代,使用 polyfill 是现在比较明智的做法。

转至我的博客,原文地址:https://github.com/camsong/blog/issues/2

想不想加入阿里巴巴一起玩 ES7,React,FRP 等最新技术,欢迎简历到 neosoyn@gmail.com

查看原文

赞 199 收藏 779 评论 39

两岸风景 赞了文章 · 2017-08-25

Sass 与 SCSS 是什么关系?

我最近写了很多 Sass 代码,但是最近发现并不是每一个人都知道 Sass 具体是什么。下面是一个简短的说明:

当我们说起 Sass ,我们经常指的是两种事物:一种 css 预处理器和一种语言。我们经常这样说,“我们正在使用 Sass”,或者 “这是一个 Sass mixin”。同时,Sass (预处理器)有两种不同的语法:

  • Sass,一种缩进语法

  • SCSS,一种 CSS-like 语法

历史

最开始,Sass 是Haml的一部分,Haml 是一种预处理器,由 Ruby 开发者设计和开发。因为这样,Sass 使用类似 Ruby的语法,没有花括号,没有分号,具有严格的缩进,就像这样:

// Variable
!primary-color= hotpink

// Mixin
=border-radius(!radius)
    -webkit-border-radius= !radius
    -moz-border-radius= !radius
    border-radius= !radius

.my-element
    color= !primary-color
    width= 100%
    overflow= hidden

.my-other-element
    +border-radius(5px)

你可以就看到,这和CSS代码有很大的区别!即使你是一个 Sass(预处理器) 用户,你也会发现这和你正在使用的有很大的差别。变量的标志用 !,而不是$,分配符是=而不是:。非常怪异。

但是在2010年五月之前,Sass 就是这个样子的。2010年5月,官方推出了一个全新的语法,被叫做 SCSS,意思是 Sassy CSS。这个语法带来了对 CSS 友好的语法,试图弥合 Sass 和 CSS 之间的鸿沟。

// Variable
$primary-color: hotpink;

// Mixin
@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;
}

.my-element {
    color: $primary-color;
    width: 100%;
    overflow: hidden;
}

.my-other-element {
    @include border-radius(5px);
}

SCSS 和 Sass 相比更加贴近 CSS 语法。也就是说,Sass 维护者做了大量的工作,把缩进语法中的!=换成了 SCSS 中的 $:

现在,在开始一个新项目时,你也许疑惑要用哪种语法。让我们来看看两种语法的优劣。

Sass缩进语法的优劣

虽然语法看起来怪异,但是缩进语法有很多有趣的点。首先,它 更短并且更易于书写。没有花括号,没有分号,你完全不需要这些东西。更好的是,你甚至不需要@mixin 或者 @include, 一个字符就足够了:=+

同时 Sass 通过严格的缩进来强制 clean coding standards。因为一个错误的缩进就会破坏整个.sass文件,这使得整个代码总是clean 和格式良好的。只有一种写 Sass 代码的方式:正确的方式。

但是请注意!缩进在 Sass 中是有意义的。当你缩进了一个元素,这意味这你将它变为了之前元素的子元素。比如:

.element-a
    color: hotpink

    .element-b
        float: left

以上会输出下面的 CSS 代码:

.element-a {
    color: hotpink;
}

.element-a .element-b {
    float: left;
}

.element-b 向右一格以为着它变成了 .element-a 的子元素,改变了输出 CSS 代码的结果。所以一定要小心你的代码缩进。

另外,我觉得基于缩进的语法适合于 Ruby/Python 团队,而不适合 PHP/Java 团队。(这是值得商榷的,我也希望听到不同的声音)

SCSS语法的优劣

对于初学者,SCSS 是完全和 CSS 兼容的,这意味着几乎为零的学习曲线。SCSS语法即是:它只是加了一些功能的 CSS。当你和没经验的开发者一起工作时这很重要:他们可以很快开始编码而不需要首先去学习Sass。

此外,SCSS 还是 易于阅读 的,因为它是有语义的,而不是用符号表示。当你读到 @mixin,你就会知道这是一个 mixin 声明;当你看到 @include ,你就是在引用一个 mixin。他并没有用任何缩写,当你大声读出来时所有的都很明了。

还有,现在几乎所有 Sass 的工具,插件和 demo 都是基于 SCSS语法来开发的。随着时间过去,SCSS 会变成大家首选的选择。比如,你现在很难找到一个 Sass 缩进语法的高亮插件,通常都只有 SCSS 的可以用。

总结

如何选择取决于你,但是除非你有很好的理由一定要使用缩进的语法,我强烈推荐使用 SCSS 。不仅仅它很简单,同时他也很方便。

最后请注意 Sass 从来没有大写过,无论你指的是语法或者这个语言。同时, SCSS 一直是大写的。甚至有一个网站专门来提醒你这件事!

翻译自What’s the Difference Between Sass and SCSS?

查看原文

赞 29 收藏 38 评论 4

两岸风景 发布了文章 · 2017-08-22

tornado下https配置

问题背景

越来越多的网站已经支持https,相比于http更安全。尤其有的开发网站只支持https,例如微信公众平台。
这里暂时不提tornado如何搭建https服务,回头有时间再记一下。

SSLError

可以用AsyncHTTPClient发送一个简单的https请求

https_url = "https://path"      
https_client = AsyncHTTPClient()
response = yield YieldTask(token_client.fetch, access_token_url)

结果出现了如下问题

ssl.SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

参考tornado rejects valid SSL certificates

这个原因是因为证书设置不正确,那么我们可以通过下面的操作给AsyncHTTPClient设置证书。

 import certifi
 AsyncHTTPClient.configure(None, defaults=dict(ca_certs=certifi.where()))

但是这个设置以后,会发现虽然不报错了,但是请求还是会失败,错误原因依然是certificate verify failed

查看了certifi的主页
certifi

发现官方也给出了解释:

Unfortunately, old versions of OpenSSL (less than 1.0.2) sometimes
fail to validate certificate chains that use the strong roots. For
this reason, if you fail to validate a certificate using the
certifi.where() mechanism, you can intentionally re-add the 1024-bit
roots back into your bundle by calling certifi.old_where() instead.
This is not recommended in production: if at all possible you should
upgrade to a newer OpenSSL. However, if you have no other option, this
may work for you.

其实大概就是因为openssl的老版本(地域1.0.2)用的校验是strong roots(指的是只信任了少部分ca吗?我也没太懂)。总之,有好几个解决方法:
1、换老版本的certifi来解决(因为老版本的certifi证书比较老,跟老版本的openssl正好合得来),但是这种方法不是非常好,目前看网上用的是certifi==2015.04.28版本,这个版本也没有certifi.old_where(),因为本身就是老的……

2、就用新版本的certifi,但是验证时用certifi.old_where()下面的证书来进行配置

import certifi
AsyncHTTPClient.configure(None, defaults=dict(ca_certs=certifi.old_where()))

3、升级python版本到2.7.9以上,因为这之后,python进行https请求时,不用再通过certifi来配置,而是已经内置了相关的证书。

4、升级openssl到1.0.2及以上。

推荐升级openssl或者Python版本,如果因为环境限制,实在没办法的话用old_where也行。

查看原文

赞 1 收藏 1 评论 0

两岸风景 关注了用户 · 2017-08-18

腾讯开源 @tengxunkaiyuan_58fdcd0c099d6

2019年,腾讯开源开始向“自下而上”与“自上而下”相结合的协同式开发演进。在内部协同共建的基础上,推动更底层、更重磅的技术对外开放,不断完善开源治理,打造开发者共建的生态。
腾讯开源也与腾讯云紧密结合,为开发者提供更多便利的基础服务、工具和开源项目。
在自主开源方面,截至2020年1月,腾讯共对外开源93个项目,包含微信、腾讯云、大数据、游戏、AI、安全等领域,并覆盖所有BG(事业群)。

关注 461

两岸风景 赞了文章 · 2017-08-18

腾讯祭出大招VasSonic,让你的H5页面首屏秒开

VasSonic成长历程


前言

2017.8.8 14时,SNG增值产品部Vas团队研发的轻量级高性能Hybrid框架VasSonic通过了公司最终审核,作为腾讯开源组件分享给大家。从当初立项优化页面加载速度,到不断摸索、优化,再到整理代码、文档,最终在Github上开源,并且在24小时内获取star数超过1600。我们非常高兴看到我们的成果收到这么多的关注,趁此机会,正好回顾一下VasSonic的成长历程,也希望能够让大家更了解VasSonic。

项目背景

Web相信大家再熟悉不过了,它具有快速迭代发布的天然优势,但也存在中一些让人诟病的问题,比如加载速度慢,体验差等。在此之前,手Q上很多页面首屏打开速度居高不下,甚至有些耗时达到3s以上,这意味着用户打开页面必须经过3秒之后才能进行交互操作,体验相当差,很多用户忍受不了这个漫长的时间直接流失掉了。

为了提升用户体验和业务用户留存率,我们很多业务一开始通过Web开发,等页面模型验证符合预期后,再将H5页面转化成原生界面。我们很快意识到这不是一种健康的可持续的开发模式,一方面存在重复人力浪费,另外一方面原生商城除了速度快一点,要运营活动改版都很难。

所以后来团队改了切入方向,安排人力专心研究如何加快页面打开速度,经过了一系列的摸爬滚打和优化探索,最终我们研发出了VasSonic框架,让H5页面首屏达到秒开,给用户一个更好的H5体验。下面就和大家分享VasSonic框架的发展历程。

业务形态

任何一个技术框架都是结合具体的业务形态来进行发展优化的,技术是为了更好地服务业务,业务也会驱动技术的发展。在此首先介绍一下业务形态,我们是来自手Q增值产品部门的VAS团队,负责手机QQ上很多深受年轻人喜欢的个性化增值服务,比如气泡、挂件、主题等等。手Q上大部分的业务还是基于H5开发的,大家对手Q的业务形态可能有简单的了解。比如下图的游戏分发中心、会员特权中心、个性化装扮商城等。这部分商城的特点比较明显,页面的很多数据都是动态的,是由我们的产品经理在后台配置的。
业务

这些都是很常见页面,我们通常将html/js/css等静态资源放到CDN上,然后页面加载后,再通过CGI去拉取最新的数据,进行拼接展示, 这样子可以利用到CDN的多地部署和就近接入等优势,同时提高了服务器的并发能力。这种传统模式的加载流程如下所示:
加载流程

  1. 用户点击后,经过终端一系列初始化流程,比如进程启动、Runtime初始化、创建WebView等等。
  2. 完成初始化后,WebView开始去CDN上面请求Html加载页面。
  3. 页面发起CGI请求对应的数据或者通过localStorage获取数据,数据回来后再对DOM进行操作更新

可以看出上述流程存在着几个问题:

  1. 从外网统计数据来看,用户的终端耗时在1s以上,这意味着在这1s多的时间里,网络完全是空闲在等待的,非常浪费;
  2. 页面的资源和数据完全依赖于网络,特别是用户在弱网络场景下,页面会出现很长时间的白屏,体验非常差;
  3. 因为页面的数据依赖于动态拉取,加载完页面后,往往是看到一些模块先转菊花,再展示,体验也是不好的。同时这里涉及到较多数据更新,经常要更新DOM,性能上也有不少开销。

所以针对以上几个问题,我们也对应做了很多优化和探索。

问题

VasSonic的前世

优化终端

针对终端耗时1s以上的情况,我们对手Q WebView框架进行了重构:

  1. 启动流程彻底拆分,设计为一个状态机按序按需执行
  2. View相关拆分模块化设计,尽可能懒加载,IO异步化
  3. X5内核在手Q中的独立进程中提前预加载
  4. 创建WebView对象复用池

关于第四点,我们想分享一些Android平台上的细节,由于Android系统的生态原因,导致用户的系统版本和系统Webkit内核处于极其分裂状态,所以我们公司在手Q和微信统一使用X5内核。相对系统WebView来说,首次启动X5内核时,创建WebView比较耗时,因此我们尽量想复用WebView,但是WebView却是与Activity Context绑定。销毁复用的时候,需要释放Activity的Context,否则会内存泄露。针对这种情况,有没有一种两全其美的办法呢?

计算机有一句经典的名言:计算机领域任何一个问题都可以通过引入中间层来解决。于是我们通过包装的方式,实现了一个Context的壳,真正的实现体包装在里面,逻辑调用真正调用到对应的实现体的函数。 经过实验发现,Android系统本身提供了这么一个MutableContextWrapper,作为Context的一个中间层。

我们会将Activity context包在MutableContextWrapper里面,destory的时候,会将WebView的Context设置为Application的Context,从而释放Activity Context。
类似如下:


//precreate WebView
MutableContextWrapper contextWrapper = new MutableContextWrapper(BaseApplicationImpl.sApplication);
mPool[0] = new WebView(contextWrapper);

//reset WebView 
ct =(MutableContextWrapper)webview.getContext();
ct.setBaseContext(getApplication());

//reuse WebView
((MutableContextWrapper)webview.getContext()).setBaseContext(activityContext);

静态直出

“直出”这个概念对前端同学来说,并不陌生。为了优化首屏体验,大部分主流的页面都会在服务器端拉取首屏数据后通过NodeJs进行渲染,然后生成一个包含了首屏数据的Html文件,这样子展示首屏的时候,就可以解决内容转菊花的问题了。
当然这种页面“直出”的方式也会带来一个问题,服务器需要拉取首屏数据,意味着服务端处理耗时增加。
不过因为现在Html都会发布到CDN上,WebView直接从CDN上面获取,这块耗时没有对用户造成影响。
手Q里面有一套自动化的构建系统Vnues,当产品经理修改数据发布后,可以一键启动构建任务,Vnues系统就会自动同步最新的代码和数据,然后生成新的含首屏Html,并发布到CDN上面去。

直出

离线预推

页面发布到CDN上面去后,那么WebView需要发起网络请求去拉取。当用户在弱网络或者网速比较差的环境下,这个加载时间会很长。于是我们通过离线预推的方式,把页面的资源提前拉取到本地,当用户加载资源的时候,相当于从本地加载,即使没有网络,也能展示首屏页面。这个也就是大家熟悉的离线包。
手Q使用7Z生成离线包, 同时离线包服务器将新的离线包跟业务对应的历史离线包进行BsDiff做二进制差分,生成增量包,进一步降低下载离线包时的带宽成本,下载所消耗的流量从一个完整的离线包(253KB)降低为一个增量包(3KB)。
带宽优化

经过一系列优化后,在Android平台上,点击到页面首屏展示的耗时从平均3s多降低为1.8s,优化40% 以上

数据对比

VasSonic的诞生

虽然通过静态直出和离线预推等方式优化后,速度已经达到1.8s,但还存在很大的优化空间,当我们准备持续深入优化时,我们的业务形态发生了新的变化。

之前我们页面内容的数据主要是由产品经理要配置的,用户看到的内容基本都是一样的。而现在页面为了更好地为用户推荐喜欢的内容,我们后台引入机器学习和随机算法来做智能个性化推荐。比如左边新用户推荐的是新货精选,而右边活跃用户展示的是潮品推荐。另外还有部分的内容是随机算法推荐的。这意味着不同用户看到的内容是不同的,同一个用户不同时间看到的内容也有可能不同。

新业务

所以为了满足业务的需求,我们只能实时拉取用户数据并在服务端渲染后返回给客户端,也就是动态直出的方案。

但是动态直出方案存在几个比较明显的问题:

  1. 服务端实时拉取数据渲染导致白屏时间长,因为服务器要先实时拉取个人数据,然后进行渲染直出,这个耗时不可控;
  2. 首屏无法使用离线预推等缓存策略,因为每个用户看到的内容不一样,我们无法通过静态直出的方式那样把Html全部发布到CDN;

虽然动态直出方案下,页面首屏无法通过离线预推等方式进行加载优化,但前面优化积累的经验给我们提供了思路:要优化白屏问题,核心还是得从提升资源加载速度方向入手。所以我们重点在资源加载方面进行了深度优化。

并行加载

首先在加载流程方面,我们发现这里WebView访问依然是串行的, WebView要等终端初始化完成之后,才发起请求。虽然终端耗时优化了不少,但是从外网的统计数据来看,终端初始化还是存在几百毫秒的耗时,而这段时间内网络是在空等的。

串行

因此性能上不够极致,我们优化代码,这两个操作并行处理,流程改为:

并行

并行处理后速度有所改善,但我们发现在某些场景下,终端初始化比较快,但数据没有完成返回,这意味着内核在空等,而内核是支持边加载边渲染的,我们在并行的同时,能否也利用内核的这个特性呢?

于是我们加入了一个中间层来桥接内核和数据,内部称为流式拦截:

桥接流

  1. 启动子线程请求页面主资源,子线程中不断讲网络数据读取到内存中,也就是网络流(NetStream)和内存流(MemStream)之间的转换;
  2. 当WebView初始化完成的时候,提供一个中间层BridgeStream来连接WebView和数据流;
  3. 当WebView读取数据的时候,中间层BridgeStream会先把内存的数据读取返回后,再继续读取网络的数据。

通过这种桥接流的方式,整个内核无需等待,继续做到边加载边解析。这种并行的方式让首屏的速度优化15%以上,进一步提升了页面加载速度。

动态缓存

通过并行加载,我们极大地提升了WebView请求的速度,但是在弱网络场景下白屏时间还是非常长,用户体验非常糟糕。于是我们在思考,是否能够将用户的已经加载的页面内容缓存下来,等用户下此点击页面的时候,我们先加载展示页面缓存,第一时间让用户看到内容,然后同时去请求新的页面数据,等新的页面数据拉取下来之后,我们再重新加载一遍即可。

动态缓存

保存页面内容这个工作很简单,因为现在我们资源读取都是通过中间层BridgeStream来管理的,只需要将整个读取的内容缓存下来即可。
于是我们就按动态缓存这种方案去实现了,但很快就发现了问题。用户打开页面之后,先是看到历史页面,等用户准备去操作的时候,突然页面白闪一下,重新加载了一遍,这种体验非常差,特别在一些低端机器上,这个白闪的过程太明显,非常影响体验,这是用户和产品经理都不能接受的。于是我们在思考,能否只做局部的刷新,仅刷新变化的元素呢?

通过分析,我们发现同一个用户的页面,大部分数据都是不变的,经常变化的只有少量数据,于是我们提出了模板(template)和数据块(data)的概念:页面中经常变化的数据我们称为数据块,除了数据块之外的数据称为模板。

页面分离

我们将整个页面html通过VasSonic标签进行划分,包裹在标签中的内容为data,标签外的内容为模版。

页面规范

首先我们对Html内容进行了扩展,通过代码注释的方式,增加了“sonicdiff-xxx”来标注一个数据块的开始与结束。
而模板就是将数据块抠掉之后的Html,然后通过{albums}来表示这个是一个数据块占位。
数据就是JSON格式,直接Key-Value。
当然,为了完美地兼容Html,我们对协议头部进行了扩展,比如增加accept-diff来标注是否支持增量更新、template-tag来标注模板的md5是多少等。OK,有了上面这个规则或者公式后,我们就可以实现增量更新了。

请求规范约定

VasSonic为了支持区分客户端是否支持增量更新等能力,对头部字段进行了扩展

字段说明请求头(Y/N)响应头(Y/N)
accept-diff表示终端是否支持VasSonic模式,true为支持,否则不支持YN
If-none-match本地缓存的etag,给服务端判断是否命中304YN
etag页面内容的唯一标识(哈希值)NY
template-tag模版唯一标识(哈希值),客户端使用本地校验 或 服务端使用判断是模板有变更YY
template-change标记模版是否变更,客户端使用NY
cache-offline客户端端使用,根据不同类型进行不同行为NY

cache-offline字段说明

字段说明
true缓存到磁盘并展示返回内容
false展示返回内容,无需缓存到磁盘
store缓存到磁盘,如果已经加载缓存,则下次加载,否则展示返回内容
http容灾字段,如果http表示终端六个小时之内不会采用sonic请求该URL

模式介绍

VasSonic根据本地是否有缓存以及本地缓存数据跟服务器数据的差异情况分为以下四种模式。

模式说明条件
首次加载本地没有缓存,即第一次加载页面etag为空值或template_tag为空值
完全缓存本地有缓存,且缓存内容跟服务器内容完全一样etag一致
数据更新本地有缓存,本地模版内容跟服务器模版内容一样,但数据块有变化etag不一致 且 template_tag一致
模版更新本地有缓存,缓存的模版内容跟服务器的模版内容不一样etag不一致 且 template_tag不一致

首次加载

我们会在请求头部带上支持accept-diff为true和sdk版本号等标识着首次加载的信息。当请求返回后,VasSonic会在延迟几秒后(避免激烈IO竞争)将页面抽离成模板和数据并保存到本地。此时终端缓存目录下,该页面将对应三个缓存文件xxx.html、xxx.template、xxx.data,其中xxx是该页面的唯一标识(即sonicSessionId)。

对于页面非首次加载场景,VasSonic优先加载本地缓存, 同时我们会在请求头部带上当前缓存和模板的md5,后台进行模板md5对比之后,分为以下几种情况:

非首次加载之完全缓存

本地有缓存,且缓存内容跟服务器内容完全一样.

非首次加载之增量数据

增量数据

如果模板发现没有变化,那么会在响应头部返回template-change=false,同时响应包体返回的数据不再是完整的html,而是一段JSON数据,及全部的数据块。我们现在需要跟本地数据进行差分,找出真正的增量数据,如上图中,后台返回了N个数据,实际上仅有一个数据是有变化的,那么我们仅需要将这个变化的数据提交到页面即可。一般场景下,这个差异的数据比全部数据要小很多。如果页面拆分数据得更细,那么页面的变动就更小,这个取决于前端同学对数据块的细化程度。

获得变化数据块(diff_data)后,客户端只需要通知页面页面设置的回调接口(getDiffDataCallback)进行界面元素更新即可。这里javascript的通信方式也可以自由定义(可以使用webview标准的javascript通信方式,也可以使用伪协议的方式),只要页面跟终端协商一致就可以。
提交增量

对于数据更新这种场景,终端还会将新的数据和模板拼接成为新的页面,保持缓存最新。当终端初始化比较慢的时候,WebView去加载缓存的时候,这个页面可能已经是最新的了,连数据刷新都不需要。

非首次加载之模板更新

与数据更新模式不一样,由于业务需求,页面的模板会发生更改。当终端在获取到新的模板和数据后,本地在子线程中进行合并,生成一个新的缓存,然后回调通知终端,刷新WebView来加载新的缓存。

我们来看一下最终的流程图,跟动态缓存对比,有不少细节优化:

整体流程

我们从第2步开始,SonicSession首先会去读取缓存。会抛个消息通知WebView读取缓存,如果Webview已经准备好,则直接加载缓存,如果没有,则缓存先放在内存里面。同时SonicSession也会带上模板等信息到后台拉取新的内容,后台经过Sonic-Diff之后,会返回新的数据。SonicSession拿到新的数据后,首先会跟本地数据进行Diff,如果发现WebView已经加载缓存,则直接提交增量数据给页面。否则继续拼接最新的页面,替换掉内存里面的缓存,同时保存到本地。这个时候WebView如果Ready,则直接进行第5步load最新的内容即可。

效果统计

效果统计

这个是我们外网的统计数据。在数据更新模式下,首屏的耗时在1s左右,相比普通的动态直出,优化了50%以上。模板更新这个会比首次高,是因为加载了两次页面,不过从模式占比上来看,我们大部分页面都是数据更新。针对模板更新这种耗时比较高的情况,前面优化积累的经验给我们提供了思路,核心还是从提前获取资源方向入手,因此我们优先考虑如何预加载模板更新。

预加载

实际上整个SonicSession在没有WebView的情况下,也是可以独立完成所有逻辑的,当用户点击页面的时候,我们在将WebView和SonicSession绑定起来即可。于是我们支持了两种预加载的模式,一种是通过后台push的方式,来提前获取数据。还有一种就是JSAPI,页面可以调用JSAPI来预加载用户可能操作的下一个页面。通过这两种方式,我们可以把需要的增量更新数据提前拉取回来
预加载

效果对比

Pic 1: 没有使用VasSonicPic 2: 使用VasSonic
default modeVasSonic mode

展望未来

开源只是故事的开始,我们仍会持续对 VasSonic 做改进,包括更易用的接口、更好的性能、更高的可靠性,同时快速响应解决开源后的issue和PR。这些改进最终也会原封不动地在手Q内使用,这一切都是为了更快的WebView加载速度。

Talk is cheap,read the fucking code. If you are interested in VasSonic, don't forget to STAR VasSonic.
Thank you for reading ~

查看原文

赞 96 收藏 346 评论 22

认证与成就

  • 获得 18 次点赞
  • 获得 2 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 2 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2015-03-15
个人主页被 985 人浏览