AngularJS 2 尽管还在Alpha阶段，但主要功能和文档已经发布。让我我们了解下Angular 1 和 2 的区别，以及新的设计目标将如何实现。
Angular 2 当前仍处于 Alpha/开发预览阶段，但是主要功能和核心文档都已经可用了。让我们一起了解下 Angular 2 的设计目标，以及实现它们的计划：
Angular 2 主要目标
更易于推论
Angular 1 vs Angular 2 变化侦测
基于 Zones 的更透明的内部构件
改进的堆栈跟踪
大幅提升的性能 (以及原理)
改进的模块化
改进的依赖注入
Web 组件友好 (如何达成以及原理)
支持影子 DOM
支持 Android 和 iOS 的原生移动渲染
支持服务端渲染
改进的可测试性
向 Angular 2 迁移的路径
总结
Angular 2 主要目标
Angular 2 的主要目标是创建一个简单易用并且快速工作的 web 框架。让我们看看这是如何达到的：
目标：更易于推论
在当前版本的 Angular 中，我们有时不得已对应特定的使用场景推论框架内部构建，比如必须推论应用事件初始化和摘要循环：
在 Angular 1 中没有摘要循环结束事件 (查看原因)，因为这种事件可能会促发更多的变化，以至于使摘要循环持续下去
我们必须推论何时调用 $scope.apply 或 $cope.digest，而这并不总是容易的
有时我们必须调用 $timeoutto让Angular 结束摘要循环，当 DOM 稳定时再做一些操作
为了使 Angular 2 更易于推论，一个目标是创建更多开箱即用的透明内部构建。开始之前，让我们看看 Angular 1 的绑定机制是如何实现的，然后如何使它更透明。
Angular 1 如何实现绑定
Angular 1 这么流行的主要原因之一是，ng-model 功能可以使界面上的改动立即反应在一个简单 Javascript 对象上。
根据这个 podcast (查看 3:50 处)，Angular 1 是这样完成此功能的：
Javascript 运行时中，每一样东西都是可以依设计打补丁的 – 如果需要我们可以改变 Number 类
Angular 在启动时会给所有的异步交互点打补丁：
超时
Ajax 请求
浏览器事件
Websockets，等等
在那些交互点，Angular 会对 scope 对象进行变动检查，如果发现有变动就激发相应的监视器
重新运行变动检查，检查是否有更多的变化发生，重新运行监视器，等等
Angular 1 绑定运行的后果
结果是 DOM 一直同简单 Javascript 对象进行同步，尽管这样可以工作，但是这使得有时难以进行推论：
不清楚哪些监视器会运行，什么顺序，多少次
模型更新顺序难以推论和预期
摘要循环多次运行导致时间消耗
Angular 团队制定 Angular 2 开发方向时，其中一点是提取 Angular 代码中的异步交互点补丁机制，以便可以重用它。
Zones 介绍
这些重构的结果就是 Zone.js，它类似于 Java 中的 thread-local 上下文。
他可以用于很多场景，比如可以允许框架生成更长的跨越多个 JavaScript VM 的堆栈跟踪信息。
Angular 2 如何因 Zones 而更透明
Angular 2 使用 zones 机制使摘要循环不再被需要。简单的非 Angular 指定代码可以透明地激发一个Angular 2 摘要，如下是由一个 zone 中的组件激发的示例：
element.addEventListener('keyup', function () {
console.log('Key pressed.');
});
});不再需要 $scope.apply 或 $scope.digest，每样东西都透明地工作。或许我们不必推论出 zones 适用于大多数一般场景，但是可以通过使用 VmTurnZone 在 Angular zone 外运行代码。
目标: 提升性能
上面描述的消化周期明确表示，这一切都将会耗费时间，尽管很多性能在 Angular 1.3 和 Angular 1.4 版本中得到改进。
但不清楚哪些性能可以改进更多，原因之一是存在变化检测循环的可能性。
为了更好地理解如何实现性能提升（比 Angular 1 快5到10倍），参考了很多播客和博客 。我会尽量在这里总结 Angular 2 更快的两个主要原因：
更为快速的检测一个单向绑定
它提供了一项检测单向绑定的机制，这项机制可以允许 Javascript 虚拟机对于代码到源代码的实时编译进行优化和完善。相对于递归性扫描对像的变化，这份机制会创建一个方法，这个方法将在 Angular 启动时去检查这个绑定是否已经改变。有了这样的一个检测函数，我们很容易的自己亲手编写类似函数来测试绑定对象的变化，同时它也很容易被虚拟机优化。
避免扫描部分组件树
Angular2 也可以让开发者为变化检测机制做出相应的一些保障，而不用不断地扫描一部分的组件树。就基本上来说，开发者将有两个选择：
创建一个可见的对象：Angular 将会发现这个对象并且注册去观察这个对象。在这种状况下，如果这个对象发生改变或者保留原来的装态，Angular 将会通过观察机制获得消息，所以就不需要为这个对象运行变化检测机制。
创建一个不可变的对象， 可以使用 Facebook 提供的 immutable.js。 同样的，Angular 也会检测到这个对象，而且也不需要变化检测机制去检测这个不可变的对象。
目标: 提升模块化
在 Angular 1 中，Angular 的模块几乎都依赖于注入容器以及其他相关功能。
这些模块的例子都不是异步加载的，以 AMD 模块为例，根据他们的依赖性列出第一次的加载所需的依赖。
Angular 1 和模块懒加载
Angular 1 的懒加载是类似于 ocLazyLoad 方式的解决方案，但是理想情况下应该是本地框架能更易懂，这在这个播客的 (13:06)的地方，Angular 2 也是这样的情况。
将 npm 优化为前端包的管理工具
同时 Angular 团队一直尝试改进 NPM，让它变得更加前端友好化；不仅仅是对于 Angular 而言，同时也是对于任何前端 library 而言。
而 Angular 2 则没有这样的问题，假如我们选择npm, 我们完全可以利用新型的ES6 模块加载器，ES6通过利用es6-module-loader pollyfill 使其变成一个标准的同步模块加载器。
目标： 改进依赖注入
在Angular 1 的世界里，依赖注入在构建多模块应用时是一项技术的飞跃， 但是在一些极端的案例中，如果不做出一些重要的变化是不能解决这些问题的。
Angular 1 包含对象全局池
Angular 1 其中一个 DI 案例中每个应用仅有一个对象全局池。这就意味着，如果说主路由 loadsbackendService 我们导向了路由 B，可以延迟加载其他服务指定到这个路由。
问题就是，我们说可以延迟加载一个 secondbackendService，使用完全不同的实现：这就会重写第一个！当前还没有办法同一名字有两个不同实现的两个服务，这就会阻止用一个安全的方式从 Angular 1 实现延迟加载。
Angular 1 会静默重写模块，当他们有相同的名字
这是一个特性，允许在测试的时候模拟替换服务层的服务，但是如果恰巧在同一模块加载了两次就会发生问题。
Angular 1 的多重依赖注入机制
在 Angular 1 中， 我们可以使用在多重地方使用不同的方法进行注入：
在链接方法中通过位置注入
在直接定义中通过名字注入
在controller方法中通过名字，等等。
Angular 2 将会作出怎样的该进
而在 Angular 2 中有且仅有一种依赖注入机制： 在构造函数中通过类型注入。
constructor(keyUtils: KeyboardUtils) {
this.keyUtils = keyUtils;
}
});事实上，如果只有一种机制，那么它将变得更加容易学习。同时这种依赖注入器是类似层级结构，在不同层次的组件树，有可能实现对相同类型的不同实现。
文章转载自 开源中国社区[https://www.oschina.net]
