2016年9月

Angular 实践总结

搞了快一年的 Angular,Angular 真的是一个非常强大非常齐全非常好用的框架,而且拥有强大的社区支持,虽然踩了很多坑,但是仍然无悔学习了这样一个框架。Angular 2 已经正式发布了,我也打算学 Angular2 去了,现在手头上还有一个用 Angular 的项目,这个项目我是想把我学到的很多 Angular 的最佳实践都用进去,借此我就想干脆也写几篇博客总结下好了,我写的比较散,想到什么就说什么。

使用单次绑定或单向绑定

从 Angular 1.3 开始就有了 once-time binding,Angular 1.5 开始支持了指令和组件的 one-way binding。看看他们的用法:

单次绑定很简单,加上:: 就可以了。

<p>{{::vm.title}}</p>

An expression that starts with :: is considered a one-time expression. One-time expressions will stop recalculating once they are stable, which happens after the first digest if the expression result is a non-undefined value (see value stabilization algorithm below).

当 digest 结束之后并且单次绑定的值不为 undefined 时,这个值将不再被监听。官方称这个算法为 Value stabilization algorithm 还解释了一下。看到这个,再想起 Angular 源码那注释,觉得真的业界良心啊。想具体了解下单次绑定,出门右转 -> docs.angularjs

在视图进行单向绑定也很简单,使用 ng-bind 就可以了,这里主要说的是指令和组件中的单向绑定。

其实 Angular1 还是不断再发展,现在最新的是 1.5.9,加了很多新的东西,也做了很多性能优化。单向绑定也是 1.5 之后才引入的新东西。1.5 也引入了一个新的东西叫 component,和 directive 差不多,具体我没用过我也不太了解,不过写法简洁了很多。单向绑定主要就是用于 component 和 directive 的。

随便找个比较简单的例子来说下,

- 阅读剩余部分 -

Angular1 之折腾记

前几天 Angular2 正式发布了,虽然他也在我的学习计划里面,但我并没有把他应用在我最近开展的一个项目中。最近在写一个 Rss 订阅器,基于 Angular1 和 Koa2(总感觉两个有点不搭 =.= ),主要是不想在这个项目花太长时间,再者我还想集我目前掌握的所有技术之大成写一个能拿的出手的项目,所以就没有选择 Angular2 了。至于 Koa2,其实很早就想学了,只是之前一直在忙别的。

angular-resource 介绍

今天捣鼓 Angular 的 Resource 功能,前端后端都掌握在自己的手上时去用 Angular 的 Resource 特别舒服,大大减少了代码量,特么强大。

(function() {
    angular
        .module('app')
        .factory('Post', $resource => {
            return $resource('/api/feed/:feed_id/post/:id', {id: '@_id'}, {
                update: {method: 'PUT'},
                get: {method: 'GET', cache: true}
            });
        })
}());

在上面我定义了一个 Post 资源,一旦创建完成后,他就自动拥有了以下方法。

{
    'get': {method: 'GET'},
    'save': {method: 'POST'},
    'query': {method: 'GET', isArray: true},
    'remove': {method: 'DELETE'},
    'delete': {method: 'DELETE'}
}

有些 IE 浏览器可能不支持 delete,这时候可以使用 remove
我们还可以自定义或者修改里面的方法,比如我上面中就自定义了一个 update 方法以及给 get 方法开启了缓存。

- 阅读剩余部分 -

提升网站加载速度的 N 个方法

Web 这几年的一个变化之一估计就是各种优化小技巧不断涌出...自己也琢磨和尝试了不少优化,毕竟自己项目的网页首屏加载也是一度接近 2M 的。以下针对 HTTP1 和 HTTP1.1,在 HTTP2 中,很多最佳实践都适得其反了。

减少文件传输数量

现在前端代码发布上线的时候一般都会进行压缩,混淆,合并等操作,他们起到了减少文件体积和数量以及混淆代码降低可读性的作用。

浏览器针对同一域名的并发请求数目是有限制的,而在 HTTP1 和 HTTP1.1 中每传输一个资源就得建立一条连接。因此当网站的请求资源数量过多时,会导致后面资源请求的阻塞,也会导致频繁的连接建立和关闭带来的开销。一般浏览器的并发请求数量在4-8之间。因此我们针对同一域名的资源不宜过多,否则就会导致后面资源的阻塞。

针对该问题,我们可以采用合并文件,将资源分到不同域名,缓加载资源,提前加载资源,缓存等手段。具体如下:

  1. 合并文件以减少并发请求数量
    合并文件也不能简单粗暴的合并为一个,对于长时间不会改变的文件我们要单独合并出来,这个文件是可以进行长期缓存的,而一些变动较为频繁的我们就不应该和上面的这些文件合并在一起,并且他们也不应该设置过激的缓存策略。
  2. 将次要文件延迟加载,比如 Google Analysis
    一些无关痛痒的文件可以放到页面最尾部,这是最佳实践,这里特别想提一下 async 和 defer,他们并没有对文件的请求产生影响,只是影响了执行的过程,所以我们不应该使用 async 或者 defer 方法来优化。
    async-defer.jpg
    使用 async,会立即开始并行加载,加载完成后会进行执行并阻塞主渲染进程。
    使用 defer,会立即开始并行加载,但会延迟到最后才执行。
  3. 分散资源到不同域名
    比如图片有专门的域名(img.xxx.com)来存储。一些资源可以考虑第三方 CDN 比如 Bootcss 的 CDN,因为这类 CDN 使用较广,有可能用户浏览器已经有过缓存,这就避免了再次请求和加载,同时也减轻了服务器压力。
  4. 使用雪碧图(css sprites)来合并小图片
    这个优化技术其实挺常见,将图片合并为一个后使用 background-image 和 background-position 等来控制显示雪碧图的哪一部分就好了,据说还可以自动生成雪碧图自动定位。
  5. 利用 200 缓存
    这是一个比较极端的缓存方式,200 缓存时浏览器不发出网络请求,直接调用本地缓存,这需要强制浏览器使用本地缓存。我们可以使用 Expires 标志。即给出日期时间,超出该时间后则认为是过时,浏览器才会重新发起请求。这个具体细节我还不太了解。过后补充。
  6. 使用懒加载(lazy load)
    很多网站特别是有大量图片的网站都会使用该技术。当用户下滑页面时,才开始加载下面的图片。一来减少了页面加载的请求数和加载时间,二来也减少用户流量。不过可能有人会说这样体验不太好,好在业内有人把这个技术做到了堪称极致的地步,就是预先加载一个高度压缩的原图,然后淡出原图。大家应该有体验到类似的技术,就不多说了。
  7. 使用预加载技术(prefetch)
    这个技术知道的人可能不多,MDN 上面是这样解释的:

    页面资源预加载(Link prefetch)是浏览器提供的一个技巧,目的是让浏览器在空闲时间下载或预读取一些文档资源,用户在将来将会访问这些资源。一个Web页面可以对浏览器设置一系列的预加载指示,当浏览器加载完当前页面后,它会在后台静悄悄的加载指定的文档,并把它们存储在缓存里。当用户访问到这些预加载的文档后,浏览器能快速的从缓存里提取给用户。

    不过资源预加载其实使用的并不多,可能是因为技术本身不成熟,浏览器支持不够等原因。目前没有发现有哪个网站使用了这个技术。感兴趣的自己去了解下,这里不多阐述这个技术。

  8. 集中加载资源
    额,这个名字是我自己起的,姑且我认为也是一种优化手段,主要针对的时 SPA。比如 Angular 搭建的 SPA。Angular 提供了 templateCache 这个模块。这个在前面的博客中已经介绍过,简单说就是一个数组,我们把模板全部都预先放入这个数组中。Angular 在请求页面的时候会先检查 templateCache 是否已经缓存了,如果有则直接调用这个缓存的模板,否则发出网络请求获取该模板,同时会放入 templateCache 中缓存。有人可能会问那不是增加了首屏加载的体积大小了吗?的确,但比起用户每点击一个新的页面就发起一个请求而言,这种方式无疑会更适合不是吗?并且如果你的文件确实太大了,那你应该考虑下你是否充分利用了指令功能。

减少文件大小

除了减少文件数量,减少文件大小也同样重要,不过比起合并文件这样简单的减少文件数量的操作,减少文件大小就没来的那么简单了。常用的方法如下:

- 阅读剩余部分 -

浅谈 Angular 脏检查

Angular 的脏值检查机制一直是 Angular 被人诟病的地方,但瑕不掩瑜,Angular 还是一个非常优秀的框架,并且 Angular2 也已经抛弃了这个脏值检查的算法。
最近在看《AngularJS 深度剖析与最佳实践》,不得不说是一本很好的书籍,作者在第三章开始讲背后的原理,这里分析了 Angular 的 $digest 函数,即脏检查机制。所以自己也去下载了 Angular 最新的源码去瞧了下,然后做下笔记吧。

首先要注意,Angular 的 digest 的触发不是定时的,只有在指定的事件触发之后才会进入 $digest。基本上我们用的带 $ 的东西调用之后都可能会触发 digest。比如我们使用 setTimeout 就不会触发 digest,即当你使用 setTimeout 更改 viewmodel 的值后,它不会同步的反映到用户的视图中去,解决方法有两个,一个是使用 Angular 提供的 $timeout 替代 setTimeout$timeout 会在执行结束之后自动触发 digest; 另一个方法是手动调用 $apply,$apply 是 Angular 对 digest 的一层封装,我们一般不会直接调用 digest 而是通过使用 $apply 方法。比如对于 setTimeout,我们就可以这样触发 digest。

setTimeout(() => {
  $scope.$apply(() => {
    $scope.test = 123;
  })    
}, 500);

我们看一个例子,这也是 Angular 源码 $digest 部分的一个示例。

var scope = ...;
scope.name = 'misko';
scope.counter = 0;

expect(scope.counter).toEqual(0);
scope.$watch('name', function(newValue, oldValue){
  scope.counter = scope.counter + 1;
});
expect(scope.counter).toEqual(0);

// 执行第一次 digest,第一次 digest 会遍历全部的 watcher,并触发上面的方法,从而使的 count+1
scope.$digest();
expect(scope.counter).toEqual(1);

// 第二次调用时,由于上一次调用检查 name 不脏,所以不会再去处理
scope.$digest();
expect(scope.counter).toEqual(1);

// 第三次调用时,由于 name 发生了变化,使得当前值和上一次保存的值不同,所以会触发起 $watch 方法
scope.name = 'adam';
scope.$digest();
expect(scope.counter).toEqual(2);

Angular 的脏值检查过程大致如下:
对当前作用域和子作用域上的 $$watchers 进行遍历,$$watches 保存着 scope 上的所有变量以及其 $watch 方法,调用时会取当前值和上一次值进行比较,如果不相等则会调用 $watch 方法,同时会保存当前的值以在下一次进行比较,并且记录此次检查结果为脏。然后重复进行直到数据不脏为止,因此至少要 digest 两次,超出 10 次会报错,可以调高这个次数限制。当数据不再脏即 model 稳定下来之后, Angular 才会开始一次性批量更新 UI。从而减少了浏览器的 repaint 次数,提升性能。

深入到源码来看:

- 阅读剩余部分 -