通过

进程间通信 (IPC)

  • 项目

本主题说明了在通用 Windows 平台 (UWP) 应用程序与 Win32 应用程序之间执行进程间通信 (IPC) 的各种方式。

应用服务

应用服务使应用程序可以公开在后台接受和返回基元属性包 (ValueSet) 的服务。 如果进行了序列化，则可以传递丰富的对象。

应用服务可以作为后台任务在进程外运行，或是采用前台应用程序在进程内运行。

应用服务最适合用于共享少量数据，在这种情况下，不需要几乎实时的延迟。

COM

COM 是一种面向对象的分布式系统，用于创建可进行交互和通信的二进制软件组件。 作为开发人员，会使用 COM 为应用程序创建可重用的软件组件和自动化层。 COM 组件可以在进程内或进程外，它们可以通过客户端和服务器模型进行通信。 进程外 COM 服务器以来一直用作对象间通信的一种方法。

具有 runFullTrust 功能的打包应用程序可以通过程序包清单为 IPC 注册进程外 COM 服务器。 这称为打包的 COM。

Filesystem

BroadFileSystemAccess

打包的应用程序可以通过声明 broadFileSystemAccess 受限功能来使用广泛的文件系统执行 IPC。 此功能会向 Windows.Storage API 和 xxxFromApp Win32 API 授予对广泛的文件系统的访问权限。

默认情况下，针对打包的应用程序通过文件系统进行的 IPC 仅限于此部分中所述的其他机制。

PublisherCacheFolder

PublisherCacheFolder 使打包的应用程序可以在其清单中声明可以由同一发布者与其他程序包共享的文件夹。

共享存储文件夹具有以下要求和限制：

  • 共享存储文件夹中的数据不会进行备份或漫游。
  • 用户可以清除共享存储文件夹的内容。
  • 无法使用共享存储文件夹在来自不同发布者的应用程序间共享数据。
  • 无法使用共享存储文件夹在不同用户间共享数据。
  • 共享存储文件夹没有版本管理。

如果你发布多个应用程序并且在寻找一种简单的机制用于在它们之间共享数据，则 PublisherCacheFolder 是基于文件系统的简单选项。

SharedAccessStorageManager

SharedAccessStorageManager 与应用服务、协议激活（例如 LaunchUriForResultsAsync）等结合使用，以便通过令牌共享 StorageFiles。

FullTrustProcessLauncher

利用 runFullTrust 功能，打包的应用程序可以在同一程序包中启动完全信任进程。

对于程序包限制是一种负担或缺少 IPC 选项的情况，应用程序可以使用完全信任进程作为代理来与系统交互，然后通过应用服务或其他一些受良好支持的 IPC 机制与完全信任进程本身进行 IPC。

LaunchUriForResultsAsync

LaunchUriForResultsAsync 用于与实现 ProtocolForResults 激活协定的其他打包的应用程序进行简单 (ValueSet) 数据交换。 与通常在后台运行的应用服务不同，目标应用程序在前台启动。

可以通过 ValueSet 将 SharedStorageAccessManager 令牌传递给应用程序来共享文件。

环回

环回是与侦听 localhost（环回地址）的网络服务器进行通信的过程。

为了维护安全和网络隔离，默认情况下对于打包的应用程序，会阻止 IPC 的环回连接。 可以使用功能和清单属性，在受信任的打包的应用程序间启用环回连接。

  • 所有参与环回连接的打包的应用程序都需要在其程序包清单中声明 privateNetworkClientServer 功能。
  • 两个打包的应用程序可以在其程序包清单中声明 LoopbackAccessRules通过环回进行通信。
    • 每个应用程序都必须在其 LoopbackAccessRules 中列出另一个。 客户端为服务器声明“出”规则，服务器为其支持的客户端声明“入”规则。

注意

可以通过 Visual Studio 中的程序包清单编辑器（在开发时）、通过合作伙伴中心（对于通过 Microsoft Store 发布的应用程序）或通过 Get-AppxPackage PowerShell 命令（对于已安装的应用程序），找到在这些规则中标识应用程序所需的程序包系列名称。

未打包的应用程序和服务没有程序包标识符，因此无法在 LoopbackAccessRules 中声明它们。 你可以通过 CheckNetIsolation.exe 将打包的应用程序配置为通过环回与未打包的应用程序和服务进行连接，但这仅适用于你对计算机具有本地访问权限并且你具有管理员权限的旁加载或调试方案。

  • 所有参与环回连接的打包的应用程序都需要在其程序包清单中声明 privateNetworkClientServer 功能。
  • 如果打包的应用程序连接到未打包的应用程序或服务，则运行 CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> 为打包的应用程序添加环回免除。
  • 如果未打包的应用程序或服务在连接到打包的应用程序，请运行 CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> 以使打包的应用程序能够接收入站环回连接。
    • 打包的应用程序在侦听连接期间，CheckNetIsolation.exe 必须连续运行。
    • -is 标志在 Windows 10 版本 1607（10.0；内部版本 14393）中引入。

注意

可以通过 Visual Studio 中的程序包清单编辑器（在开发时）、通过合作伙伴中心（对于通过 Microsoft Store 发布的应用程序）或通过 Get-AppxPackage PowerShell 命令（对于已安装的应用程序），找到 CheckNetIsolation.exe 的 -n 标志所需的程序包系列名称。

CheckNetIsolation.exe 对于调试网络隔离问题也十分有用。

管道

管道可在管道服务器与一个或多个管道客户端之间实现简单通信。

支持匿名管道和命名管道，但存在以下约束：

  • 默认情况下，仅在同一程序包中的进程之间支持打包的应用程序中的命名管道，除非进程是完全信任。
  • 可以按照共享命名对象的指导原则，在程序包间共享命名管道。
  • 命名管道（位于打包和未打包的应用程序中）必须对管道名称使用语法 \\.\pipe\LOCAL\。

注册表

通常不建议对 IPC 使用注册表，但现有代码支持该用法。 打包的应用程序只能访问它们有权访问的注册表项。

通常，打包的桌面应用程序（请参阅从代码生成 MSIX 包）利用注册表虚拟化，以便将全局注册表写入包含在 MSIX 程序包的专用配置单元中。 这可以实现源代码兼容性，同时最大限度地减小全局注册表影响，并且可用于同一程序包中的进程之间的 IPC。 如果必须使用注册表，则首选使用此模型，而不是操作全局注册表。

RPC

RPC 可以用于将打包的应用程序连接到 Win32 RPC 终结点，前提是打包的应用程序具有与 RPC 终结点上的 ACL 匹配的正确功能。

自定义功能使 OEM 和 IHV 能够定义任意功能将具有这些功能的 RPC 终结点加入 ACL，然后向客授权户端应用程序授予这些功能。 有关完整的示例应用程序，请参阅 CustomCapability 示例。

RPC 终结点也可加入特定打包的应用程序的 ACL，以将对终结点的访问仅限于这些应用程序，而无需自定义功能的管理开销。 可以使用 DeriveAppContainerSidFromAppContainerName API 从程序包系列名称派生 SID，然后使用 SID 将 RPC 终结点加入 ACL，如 CustomCapability 示例中所示。

Shared Memory

文件映射可用于在两个或多个进程之间共享文件或内存，但具有以下约束：

  • 默认情况下，仅在同一程序包中的进程之间支持打包的应用程序中的文件映射，除非进程是完全信任。
  • 可以按照共享命名对象的指导原则，在程序包间共享文件映射。

建议使用共享内存来高效共享和操作大量数据。