优化

在开发时，避免在同一流程内多次使用setData当然是最佳实践。采取人工维护肯定是能够实现的，就好比能用原生 js 能写出比众多框架更高效的性能一样。但当页面逻辑负责起来之后，花很大的精力去维护都不一定能保证每个流程只存在一次setData，而且可维护性也不高。因此，WePY选择使用脏检查去做数据绑定优化。用户不用再担心在我的流程里，数据被修改了多少次，只会在流程最后做一次脏检查，并且按需执行setData。

脏检测机制借鉴自AngularJS，多数人一听到脏检查都会觉得是低效率的一种作法，认为使用 Vue.js 中的 getter，setter更高效。其实不然，两种机制都是对同一件事的不同实现方式。各有优劣，取决于使用的人在使用过程中是否正好放大了机制中的劣势面。

WePY 中的 setData 就好比是一个 setter，在每次调用时都会去渲染视图。因此如果再封装一层 getter、setter 就完全没有意义，没有任何优化可言。这也就是为什么一个类 Vue.js 的小程序框架却选择了与之相反的另外一种数据绑定方式。

再回来看脏检查的问题在哪里，从上面实验的代码可以看出，脏检查的性能问题在于每次进行脏检查时，需要遍历所以数据并且作值的深比较，性能取决于遍历以及比较数据的大小。WePY 中深比较是使用的 underscore 的 isEqual 方法。为了验证效率问题，使用不同的比较方法对一个 16.7 KB 的复杂 JSON 数据进行深比较，测试用例请看这里：deep-compare-test-case

得到的结果如下：

图片描述

从结果来看，对于一个 16.7 KB 的数据深比较是完全不足以产生性能问题的。那 AngularJS 1.x 脏检查的性能问题是怎么出现的呢？

AngularJS 1.x 中没有组件的概念，页面数据就位于 controller 的 $scope 当中。每一次脏检查都是从 $rootScope 开始，随后遍历至所有子 $scope。参考这里 angular.js:L1081。对于一个大型的单页应用来说，所有 $scope 中的数据可能达到了上百甚至上千个都有可能。那时，脏检查的每次遍历就可能真的会成为了性能的瓶颈了。

反观 WePY，使用类似于 Vue.js 的组件化开发，在抛开父子组件双向绑定通信的情况下，组件的脏检查仅针对组件本身的数据进行，一个组件的数据通常不会太多，数据太多时可以细化组件划分的粒度。因此在这种情况下，脏检查并不会导致性能问题。

其实，在很多情况下，框架封装的解决方案都不是性能优化的最优解决方案，使用原生肯定能优化出更快的代码。但它们之所以存在并且有价值，那都是因为它们是在性能、开发效率、可维护性上寻找到一个平衡点，这也是为什么 WePY 选择使用脏检查作为数据绑定的优化。