Сравнение памяти и производительности внедренных и одноэлементных сервисов в Angular 7

Означает ли это, что если у меня есть, например, 50 компонентов, мне понадобится в 50 раз больше требований к памяти для внедренного сервиса, чем одноэлементного сервиса, который является общим для всех?

Это произойдет, только если каждый компонент имеет свой модуль и: [ 119]

• каждый модуль предоставляет услугу;

• или услуга предоставляется в одном модуле, и этот модуль импортируется в каждый компонентный модуль;

Если какой-либо компонент совместно использует модуль, который предоставляет услугу, он будет единичным вокруг этих компонентов.

Я читал очень хорошую статью из Нетанела Базала - «Угловые услуги НЕ должны быть Singleton »

Где он говорит об одноэлементных сервисах:

The sole purpose of the service is to share data between child’s components and to provide a couple of helper’s methods.

Если у вас есть одноэлементный сервис, это будет только один экземпляр, но во всем жизненном цикле приложения (даже если вы его не используете), в противном случае, если у вас есть не одноэлементные экземпляры служб, они будут потреблять гораздо больше памяти, и каждый экземпляр службы будет уничтожен только после уничтожения всех компонентов его модуля.

Я бы сказал, что вы можете попытаться контролировать компромисс этих преимуществ в своем приложении.

Другое не одноразовое преимущество:

Мы даже можем реализовать жизненный цикл ngOnInit и ngOnDestroy, вы можете проверить его здесь .

Я хотел бы понять, как влияют на память и производительность одиночные и внедренные сервисы в Angular 7.

Зависимости в Angular обрабатываются через провайдеров. Существует много типов поставщиков, таких как постоянные значения, фабрики, классы и т. Д. И т. Д.

Служба относится к инъецируемому классу, для которого был создан экземпляр. Когда создается , зависит от , когда ему предоставляется , предоставляется . Наиболее распространенным местом для объявления провайдера является объявление модуля . Таким образом, мы называем это областью действия провайдера.

Поставщик по умолчанию является одиночным распознавателем значения , но можно настроить поставщика как кратное . Для простоты мешков давайте предположим, что провайдеры - это одиночки в рамках.

Область может иметь родительских и детей . Когда провайдер объявляется , он предоставляется в текущей области . Модули имеют тенденцию быть очень высоко на дереве инжекторов с корнем наверху.

Когда создается компонент, мы можем думать об этом как о новой области видимости. С компонентом начальной загрузки в верхней части дерева компонентов, но с учетом того, что вы можете использовать фабрику для создания нового компонента, это означает, что вы не должны предполагать, что все является частью одного и того же дерева.

Да, это может быть сложно.

Например, предположим, что у меня есть список компонентов на странице, и каждому из них добавляется одна и та же услуга (т. е. она указана в поставщиках компонентов).

Давайте предположим, что эта служба называется FooBarService. Я могу объяснить множество разных вещей, которые могут произойти, основываясь на том, как вы настроили инжектор зависимостей.

1. Инжектор выдаст ошибку, что FooBarService является неизвестной зависимостью.
2. Корневой модуль предоставил FooBarService, и этот компонент и все другие компоненты получат тот же экземпляр.
3. Модуль с отложенной загрузкой предоставил FooBarService, и этот компонент получит экземпляр, но компоненты вне модуля с отложенной загрузкой будут выдавать ошибку неизвестной зависимости.
4. Родительский компонент предоставил FooBarService, и все его дочерние компоненты получат экземпляр.
5. Каждый компонент предоставил FooBarService, и каждый компонент получает новый экземпляр.

Поскольку вы указали «он указан в поставщиках компонентов», тогда будет применяться опция № 5.

См. Эту ссылку: https://angular.io/guide/providers#providing-services-in-modules-vs-components

Означает ли это, что если У меня есть например Для 50 компонентов мне понадобится в 50 раз больше требований к памяти для внедренной службы, чем для единой службы, которая является общей для всех?

Да, если вы объявили поставщика в области действия компонента а не объем модуля. Для каждого компонента, который объявил его, будет один экземпляр, но этот экземпляр является общим для дочерних элементов этого компонента.

Есть ли какие-либо другие факторы, влияющие на производительность?

Да, требуется больше памяти и времени для создания 50 компонентов, если инжектор должен создавать новые экземпляры. Повлияет ли это на ваше программное обеспечение? Как и в случае любого решения, это зависит от того, почему вы это делаете. Если это должно решить проблему зависимости, то это может быть единственным способом сделать это. Если бы вы могли вместо этого использовать общий синглтон-сервис, я бы удивился, почему вы этого не сделали.