AngularJS通过单个注入项暴露多个服务的实现及弊端咨询

我在多次搜索后仅能找到关于服务间命名空间冲突或服务注入方法的内容。假设我有两个独立服务：

angular.module('app')
 .service('OneService', function() {
 this.func = function() {
 console.log('service one');
 };
 })
 .service('TwoService', function() {
 this.func = function() {
 console.log('service two');
 };
 });

我将它们注入名为“namespace”的factory：

angular.module('app')
 .factory('namespace', function(OneService, TwoService) {
 return {
 OneService: OneService,
 TwoService: TwoService
 };
 });

随后我只需注入单个依赖即可使用这两个服务：

angular.module('app')
 .controller('ctrl', function(namespace) {
 namespace.OneService.func(); //=> 'service one'
 namespace.TwoService.func(); //=> 'service two'
 });

这种方式可整合多个工具类函数，无需逐个注入。除了可能暴露组件未使用的功能外，该注入方式是否存在效率、性能等方面的弊端？

好问题！咱们从AngularJS的运行机制和实际项目影响两个层面来拆解：

性能/效率层面的弊端 #

• 打包体积膨胀（树摇失效）：如果你的项目用了Webpack这类支持树摇的打包工具，直接注入单个服务时，工具能很容易识别出哪些服务从未被使用，从而在打包时剔除它们。但用namespace包裹后，打包工具无法准确判断你到底用到了里面的哪些服务，大概率会把所有被包裹的服务都打包进最终bundle里。这在大型应用中会明显增加资源加载体积，拖慢页面首屏加载速度。
• 可忽略的运行时开销：每次通过namespace.OneService访问服务时，会多一次对象属性查找的操作。不过这个开销在JavaScript里极其微小，除非你在每秒调用上万次的高频场景下使用，否则完全不会影响用户体验，几乎可以忽略不计。

非性能但值得重视的隐性问题 #

虽然你问的是效率性能，但这些点也会间接影响项目的长期维护效率：

• 测试成本上升：当测试控制器时，你需要mock整个namespace对象，而不是只mock实际用到的单个服务。比如你只用到了OneService，却不得不为namespace模拟出包含TwoService的结构，增加了测试代码的复杂度。
• 依赖关系模糊：其他开发者阅读代码时，无法一眼看出控制器依赖了哪些具体服务，必须跳转到namespace的定义处才能理清依赖，降低了代码的可读性和可维护性，在团队协作的大型项目里这点尤为明显。
• 循环依赖排查难度增加：如果namespace中的服务之间存在循环依赖，或者namespace本身和其他服务形成循环依赖，排查问题时会比单个服务的循环依赖更棘手，因为你需要梳理整个包裹体的依赖链。

总结 #

运行时的性能开销几乎可以忽略，但打包体积的膨胀是最实际的性能相关弊端。此外，这种方式在可维护性、测试便利性上的隐性成本也需要你根据项目规模和团队协作情况去权衡。如果是小型项目，这种方式带来的注入便捷性可能大于弊端；但如果是大型项目，更推荐按需注入单个服务，保持依赖清晰。

内容的提问来源于stack exchange，提问作者Callan Heard