Answerworks runtime что это

Обновлено: 09.01.2025

Нигде не нашел чёткого опрделения этми двумя понятиям.

Я понимаю фреймворк, как платформу, которая необходима для работы каких-либо приложений. Например, набор динамически линкуемых библиотек для нескольких приложений - уже фреймворк. Также под это определение подохдит и Java Runtime Environment (в том числе и JVM). Однако что такое рантайм? С одной стороны это всего лишь фаза выполнения программы. С другой стороны есть куча терминов, как runtime libraries, runtime system. Что вкладывает майкрософт в это понятие тоже неясно. Объясните, пожалуйста!

183 1 1 золотой знак 1 1 серебряный знак 4 4 бронзовых знака

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

runtime - это часть кода, существует в выполнимом файле (либо в отдельных so/dll) и обеспечивает всякие "удобства". Например, узнать тип объекта или сделать те же виртуальные вызовы. Добавляется обычно компилятором и обычный пользователь может даже не знать о нем. Также словом runtime называют то время, когда программа выполняется. Что конкретно имеется ввиду - нужно сдедить за контекстом.

runtime libraries - это библиотеки, которые используются во время работы программы. Иногда библиотеки поставляются в двух видах - для разработки и для обычной работы (вторые часто оптимизированы и с них выброшено лишнее). Хороший пример - bpl файлы делфи. Для одного и того же компонента могут быть библиотеки, которые содержат всякие инструметы для IDE, а есть которые только для работоспособности кода.

JRE - это не фреймворк, это runtime библиотека. Хотя с другой стороны это фреймворк для байткода. Но так как на байткоде пищут только особые извращенцы, то обычному программисту это не фреймфорк. А вот вся java - это один сплошной фреймворк:)

Текст объемный и рассчитан на:

Примеры процессов выполнения описаны для ОС Windows, но работают по тому же принципу и на других ОС (с учетом различных расширений исполняемых файлов и нативных библиотек).

0. Pay-for-Play

BCL располагается в GAC, откуда приложения загружают необходимые для работы зависимости.

Примеры компонентов, которые поставляются через NuGet:

Этот подход называется «pay-for-play»; другими словами, приложения загружают только ту функциональность, которая им необходима, но каждая такая функциональность содержится в отдельной сборке.

1. FDD vs SCD

• Portable (Framework-dependent deployment — FDD)
• Standalone (Self-contained deployment — SCD)

В Standalone (SCD)-приложении все компоненты для выполнения (CoreCLR, CoreFX), а также сторонние библиотеки, то есть абсолютно все зависимости, поставляются вместе с самим приложением (чаще всего в одной папке).

Важно понимать, что Standalone-приложение привязано к определенной ОС и архитектуре (например, Windows 7 x64 или OSX 10.12 x64). Такой идентификатор называется Runtime identifier (RID). Для каждой ОС/архитектуры существует своя версия библиотеки Core CLR (и прочих нативных компонентов), поэтому для Standalone-приложений на этапе компиляции в свойстве RuntimeIdentifier нужно указывать параметры целевой системы (RID).

Файлы фреймворка(-ов) хранятся в папке C:\Program Files\dotnet\shared.

Можно установить несколько версий фреймворка:

Для выполнения Portable-приложения необходимо запустить хост-процесс dotnet.exe и передать ему в качестве аргумента путь к управляемой сборке.

«C:\Program Files\dotnet» добавляется к значению переменной среды PATH, благодаря чему Portable-приложения теперь могут запускаться из командной строки:

Этот файл является обязательным для Portable-приложений.

Уменьшение количества файлов объясняется тем, что в Core FX 1.0 отсутствовали многие библиотеки, поэтому они шли в составе приложения, как обычные зависимости. В Core FX 2.0 эти сборки были добавлены, поэтому они больше не поставляются с приложением, а берутся из папки фреймворка.

Наблюдается картина, противоположная Portable-приложениям — чем больше становится Core FX, тем больше файлов поставляется с приложением.

Рекомендации по выбору типа развертывания

5. Runtime Configuration Files

dotnet.exe ([AppName].exe) использует файл [AppName].deps.json для определения абсолютных путей всех зависимостей приложения при его запуске.

Структура [AppName].deps.json:

Секция targets определяет платформу и дерево зависимостей для нее в формате

[ID зависимости (пакета)]/[версия]: dependencies: < список зависимостей (пакетов) данного пакета >,
относительные пути к управляемым и нативным файлам данного пакета
>

Рассмотрим подробнее содержимое файла deps.json Standalone-приложения:

В свойстве dependencies перечислены зависимости (пакеты) конкретного пакета.
Свойство runtimeTargets используется в deps-файле Portable-приложения и определяет пути файлов библиотек для конкретного RID. Такие RID-specific библиотеки поставляются вместе с Portable-приложением в папке runtimes.

Свойства runtime и native содержат относительные пути управляемых (managed) и нативных библиотек соответственно. Свойство resources содержит относительные пути и локали локализованных сборок-ресурсов.

Пути относительны к NuGet package cache, а не deps-файлу.

Добавить сторонний deps-файл можно передав значение аргумента --additional-deps или переменную среды DOTNET_ADDITIONAL_DEPS.

Такая возможность доступна только для Portable приложений.

Когда dotnet.exe (MyApp.exe) определяет пути зависимостей приложения, для каждой отдельной библиотеки составляется список из runtime- и native-путей.

6.1. Запуск приложения
выполняется при помощи мультплексора (muxer) из командной строки (одинаково на любой ОС).

6.2. [corehost] Поиск и загрузка Framework Resolver (hostfxr.dll)
На этом этапе dotnet.exe идет в папку [own directory]/host/fxr/. Для Portable-приложений эта библиотека расположена в общей папке C:\Program Files\dotnet\host\fxr\[FXR version]\hostfxr.dll. Если версий будет несколько, dotnet.exe будет всегда использовать последнюю.

После загрузки hostfxr.dll (Framework Resolver) процесс запуска переходит в рамки этой библиотеки.

6.3. [hostfxr] Определение режима выполнения (standalone, muxer, split/FX)
Первая задача hostfxr — определить режим, в котором будет работать хост процесс и таким образом тип приложения — Portable (FDD) или Standalone (SCD). В Portable (FDD)-режиме он также определяет: это запускаемое приложение или команда SDK.

— если среди аргументов есть такой, значение которого оканчивается на .dll или .exe — процесс запуска продолжится в режиме выполнение указанного файла. Если такого аргумента нет, управление будет передано SDK. Для этого из папки [own directory]\sdk\[version] (если такая существует) будет запущен dotnet.dll (как Portable приложение), и этой сборке будут переданы аргументы текущего хост процесса.

Алгоритм проверки очень простой — если в папке, откуда был запущен мультиплексор [AppName].exe (в нашем случае dotnet.exe), отсутствует coreclr.dll или [AppName].dll, то приложение Portable. Если один из этих двух файлов существует, то далее идет проверка — приложение Portable (split/FX) или Standalone. Если существует [AppName].dll, то приложение Standalone, иначе — Portable (split/FX).

Запуск Portable-приложения может также осуществляться в так называемом Exec mode.
Для этого команда запуска первым аргументом должна содержать exec C:\> dotnet exec . .

При запуске в таком режиме можно явно указать пути к файлам конфигурации:
--depsfile <PАTH>
--runtimeconfig <PАTH>
которые будут использованы вместо файлов в папке приложения.

На текущем этапе hostfxr определяет (по данным файла конфигурации), является ли приложение Portable или Standalone.

При выборе версии учитывается параметр Roll Forward On No Candidate Fx, который указывает строгость соответствия заданной версии и имеющихся на машине.

6.5. [hostfxr] Поиск и загрузка hostpolicy.dll
На текущем этапе всё готово для определения путей runtime-компонентов. Этой задачей занимается библиотека hostpolicy.dll, которая называется Host library.

Если файл не был найден на предыдущем этапе, hostpolicy.dll будет найдено в папке фреймворка.

Как только опеределена hostpolicy.dll, hostfxr загружает эту библиотеку и передает ей управление.

6.6. [hostpolicy] Определение списка зависимостей
Библиотека hostpolicy.dll отвечает за определение абсолютных путей всех зависимостей приложения.

Прежде всего hostpolicy создаст компонент под названием Dependencies Resolver, который в свою очередь загрузит два deps-файла — файл фреймворка и файл приложения.

Сперва загружается список из deps-файл фреймворка, где будут определены такие зависимости, как CoreCLR и библиотеки CoreFX. Затем список из deps-файла приложения, в котором указаны сборки нашего приложения и их зависимости.

Для каждого deps-файла Dependency Resolver составляет список всех зависимостей для указанной runtimeTarget.

Для каждого пакета сначала составляется список файлов из всех секций runtimeTargets (RID specific зависимости), далее — список всех файлов из секций native и runtime. Такой объединенный список относительных путей всех зависимостей в условном формате
ID пакета — RID — тип asset'а (runtime, native) — пути к файлам называется Target assets.

После того, как были составлены эти два списка файлов зависимостей (RID и не RID), выполняется процесс под названием Reconciling libraries with targets (согласования). Он заключается в том, что для каждого пакета из секции libraries проверяется, существует ли RID specific-файлы, которые должны переопределить обычные.

6.7. [hostpolicy] Определение путей TPA, Core CLR и CLR Jit
Далее Dependency resolver составляет список абсолютных путей файлов управляемых сборок — зависимостей приложения. Этот список называется TPA (Trusted Platform Assemblies) и передается Core CLR для настройки AppDomain. Также составляется список абсолютных путей директорий, в которых находятся остальных файлы зависимостей (кроме coreclr, corejit).

Определение абсолютных путей управляемых сборок происходит путем поиска файлов в Probe paths (путей зондирования). По умолчанию их два — папка фреймворка и папка приложения, и они основаны на расположении deps-файлов. Также можно добавить дополнительные пути:

1) передав аргумент --additionalprobingpath, например
--additionalprobingpath %UserProfile%\\.nuget\\packages

В папке фреймворка и приложения наличие файла проверятся (при условии, что он был указан в соответствующем deps-файле) без учета относительного пути, в остальных директориях с учетом относительно пути, потому что эти директории рассматриваются как кеш NuGet-пакета.

• папка приложения;
• папка фреймворка
• Probe paths

После составления списка TPA, определяются пути CoreCLR и CLRJit.

При отсутствии deps-файла приложения, dotnet.exe вначале попытается найти эти библиотеки в [app directory]\lib\. При обычном выполнении пути берутся из папки фреймворка (отбросив относительный путь и взяв только имя файла).

Устанавливаются следующие настройки CoreCLR:

• TRUSTED_PLATFORM_ASSEMBLIES — список обсолютных путей всех управляемых библиотек приложения.
• NATIVE_DLL_SEARCH_DIRECTORIES — абсолютные пути директорий, где найдены нативные зависимости.
• PLATFORM_RESOURCE_ROOTS — абсолютные пути директорий, где найдены зависимости-ресурсы
• AppDomainCompatSwitch — константа «UseLatestBehaviorWhenTFMNotSpecified».
• APP_CONTEXT_BASE_DIRECTORY — папка приложения.
• APP_CONTEXT_DEPS_FILES — абсолютные пути deps-файлов приложения и фреймворка.
• FX_DEPS_FILE — абсолютный путь deps-файла фреймворка.
• PROBING_DIRECTORIES — дополнительные пути зондирования (если они были указаны).

Процесс запуска Standalone-приложения отличается от Portable только начальным этапом, а также местоположением компонентов, которые по умолчанию должны располагаться в папке приложения.

7.2. Процесс запуска
происходит так же, как у Portable-приложения, за исключением того, что существует только один deps-файл и все зависимости ищутся в папке приложения или по указанным --additionalprobepaths.

Что такое служба NET Runtime Optimization

Служба оптимизации времени выполнения, известная как Mscorsvw.exe, используется для быстрого запуска приложений. Как правило, этот процесс не потребляет слишком много памяти. Но, если процесс оптимизации занимает много времени, это может привести к высокой загрузке ЦП.

Оптимизация NET Runtime Service

Чтобы ускорить процесс, нам нужно выполнить следующие команды:

Примечание. Буква C обозначает диск, на котором установлена операционная система. Если она установлена на другом диске, замените её.

В случае, если это не сработает, вы можете перейти к следующему решению.

Просканируйте систему на наличие инфекций

Чтобы решить эту проблему, рекомендуется использовать антивирусное программное обеспечение. Запустите глубокое сканирование и дождитесь результатов.

Запустите официальный скрипт Microsoft

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

Чтобы запустить его, выполните следующие действия:

1. Посетите GitHub для получения официального скрипта или щелкните здесь
2. Щелкните правой кнопкой мыши кнопку Raw → выберите Сохранить ссылку как

После выполнения сценария служба оптимизации должна начать работать быстрее, и высокая загрузка ЦП, с которой вы столкнулись, будет исправлена.

Если это не помогает, перейдём к следующему шагу.

Перезапустите службу NET Runtime Optimization

Высокая загрузка процессора, вызванная mscorsvw.exe, может быть устранена перезапуском службы.

Чтобы сделать это, выполните следующие действия:

1. Нажмите Win + R
2. Введите services.msc и нажмите OK .
3. Перейдите к NVIDIA Telemetry Container → щелкните правой кнопкой мыши → Свойства.
4. Щелкните стрелку вниз рядом с полем «Тип запуска» и выберите «Автоматически» → «Применить» → «ОК».

Теперь перейдите в диспетчер задач, вы больше не должны видеть высокую загрузку ЦП службой NET Runtime.

Однако, если и это не помогло, попробуем выполнить чистую загрузку.

Выполните чистую загрузку Windows

Чтобы выполнить эту задачу, выполните следующие действия:

1. Нажмите Win + R
2. Введите msconfig → ОК .
3. Перейдите на вкладку Службы → установите флажок Не отображать службы Microsoft → затем нажмите Отключить все → ОК .

Это должно помочь решить проблему.

Мы не рекомендуем отключать сервис. Однако, если вы столкнулись с высокой загрузкой ЦП из-за этого, вы можете оптимизировать её с помощью команды или можете просканировать систему на предмет заражения, используя антивирус для Windows.

Что представляет собой служба NET Runtime Optimization и mscorsvw.exe?

Mscorsvw.exe – это компонент Windows, используемый для оптимизации компьютеров и более быстрого запуска приложений.

Runtime Broker в семействе ОС Windows восьмой серии и выше – это служебная утилита, которая обеспечивает правильную работу приложений, а также управляет разрешениями стандартных программ от Windows.

Как снизить нагрузку на ЦП из-за Runtime Broker

Microsoft на своем сайте поддержки предлагает такое решение:

1. Запустите диспетчер задач, зажав одновременно клавиши Ctrl, Shift и Esc .
2. Раскройте вкладку «Процессы», а в ней найдите строку с именем Runtime Broker.
3. Щелкните на нее мышкой и в списке опций укажите «Завершить задачу».
4. Перезагрузите систему.

Но не стоит радоваться – это временное устранение проблемы и при следующем использовании приложений она вновь появится.

Так как Runtime Broker является посредником, грузит ЦП не процесс сам по себе, а приложение, которое его использует. Часто это приложения по умолчанию или системные уведомления. Поэтому лучше начать решение проблемы с ее корня.

Убедитесь, что Runtime Broker не является вирусом

Одно из самых главных действий, которое нужно выполнить сразу при обнаружении проблем с производительностью – это проверка Runtime Broker на вирусность.

Один из легких методов узнать действительно ли это системный процесс или это все же вирус – это проверить, где расположен файл утилиты runtimebroker.exe. Он должен находиться в системной папке:

C: \windows \system32 \

Для проверки выполните эти действия:

1. Одновременно зажмите сочетание Ctrl, Shift и Esc, чтобы запустить диспетчер происходящих процессов.
2. Отыщите на вкладке с процессами в списке строку Runtime Broker.
3. Кликните на название процесса мышкой, чтобы раскрыть контекстное меню, и выберите «Открыть расположение файла».

Если перед вами откроется системная папка, которую мы указали выше – все в порядке. Но если откроется другое расположение, то это вирус, с которым нужно срочно начать борьбу.

Убедитесь, что все программы и операционная система обновлены до последних версий

Простым и в то же время действенным способом решить проблемы с лишним расходом производительности из-за процесса Runtime Broker может стать обновление программного обеспечения.

Проверьте, все ли приложения на вашем компьютере обновлены до последних версий. Также не забудьте зайти в Центр обновления Windiows и проверить обновления операционки. Очень часто именно в этом заключается проблемы с производительностью.

Сократите список приложений, работающих в фоновом режиме

Некоторые программы могут незаметно для вас продолжать свою работу. Даже если вы их редко используете, они будут все-равно расходовать ресурсы системы. Все это дает лишнюю нагрузку на ЦП. А если эти приложения к тому же используют брокера среды выполнения, то нагрузка усиливается.

Посмотрите параметры системы, возможно, вам не нужны какие-то приложения, работающие в фоновом режиме. Сделать проверку можно так:

Отключите подсказки системы, использующие Runtime Broker

Некоторые пользователи Windows 10 обнаружили, что отключение подсказок Windows здорово снижает загрузку ЦП.

1. Откройте меню: «Параметры» > «Система» > «Уведомления и действия».
2. Деактивируйте «Показывать подсказки…», передвинув ползунок.
3. Перезагрузите систему.
4. Проследите за загрузкой ЦП, чтобы убедиться, что этот способ сработал.

Если вы по-прежнему видите, что Runtime Broker затрачивает необоснованно много ресурсов ОЗУ, то проблему следует искать в приложениях, использующих этот процесс.

Совет: зажав комбинацию горячих клавиш Ctrl и I, можно быстро открыть меню «Параметры».

Удалите приложения, использующие Runtime Broker

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

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

Например, стандартная программа от Виндовс для обработки и просмотра фотографий очень часто перегружает работу ЦП. Большой объем загруженных файлов изображений может повлиять на работоспособность приложения Windows Photo. Если приложение тормозит работу системы или вообще выдает ошибку, то лучше его удалить.

Чтобы быстро удалить приложение, воспользуйтесь утилитой для выполнения команд PowerShell. Найти ее можно в строке поиска Windows, введя ее имя. Запускать это средство для выполнения команд нужно только от имени администратора. Утилита PowerShell помогает удалить такие приложения, которые обычным способом удалить не удается.

Чтобы без проблем полностью удалить программу «Фотографии» с вашего компьютера, нужно ввести такую команду:

Get-AppxPackage *photos* | Remove -AppxPackage

После ввода команды не забудьте нажать кнопку Enter для запуска процесса.

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

Скорее всего, как только вы удалите это приложение, ошибка высокой загрузки ЦП исчезнет. Если этого не произойдет, рассмотрите возможность удаления других приложений с помощью одной из следующих команд:

Читайте также:

  
• Кто знает коробочки зеленые как армейские о планшет
  
• Как отправить пустое сообщение в скайпе
  
• Ssd samsung 960 pro обзор
  
• Ошибка 7f на материнской плате
  
• Постоянно выскакивает диспетчер realtek hd