アプリ パッケージの更新プログラムApp package updates

最新の Windows アプリ パッケージの更新処理は、アプリの重要な変更部分のみをダウンロードして既存の Windows アプリを更新するように最適化されています。Updating modern Windows app packages is optimized to ensure that only the essential changed bits of the app are downloaded to update an existing Windows app.

AppxBlockMap.xml ファイル内のメタデータMetadata in the AppxBlockMap.xml file

大まかに言うと、パッケージ作成中に 1 つのメタデータが作成され、アプリ パッケージ ファイル (.appx または .msix) に保存されます。これにより、パッケージの一部を Windows で一意に識別できます。At a high level, during package creation, a piece of metadata is created and stored in the app package file (.appx or .msix) which allows parts of the package to be uniquely identified by Windows. アプリ パッケージを更新するとき、Windows ではメタデータ ファイルを使用して古いパッケージと新しいパッケージを比較し、デバイスに何をダウンロードする必要があるかを判断します。When updating an app package, Windows uses the metadata file to compare the old package to the new package and determine what needs to be downloaded to the device.

メタデータによってパッケージの一部を一意に識別できるため、差分更新機構がパッケージの任意のバージョンからパッケージの他の任意のバージョンまで完全に機能します (ソース パッケージのバージョンがターゲット パッケージより低いことを想定しています)。Since the metadata allows parts of the package to be uniquely identified, this means the differential update machinery fully functions from any version of a package to any other version of a package (assuming the source package has a lower version than the target package).

メタデータは、AppxBlockMap.xml ファイル (前述のメタデータ) に含まれます。The metadata is contained in the AppxBlockMap.xml file (the aforementioned metadata). AppxBlockMap.xml ファイルは、パッケージ内のファイルに関する情報の 2 次元の一覧が含まれている XML ファイルです。The AppxBlockMap.xml file is an XML file that contains a two dimensional list of information about files in the package. 最初の次元はファイルに関する高レベルの詳細 (たとえば、名前およびサイズ) を示し、2 番目の次元はそのファイルの各 64 KB スライス ("ブロック") の SHA2-256 ハッシュ表現を提供します。The first dimension lays out high level details on the file (e.g., name and size) and the second dimension provides SHA2-256 hash representations of each 64KB slice of that file (the "block").

AppxBlockMap.xml ファイルのサンプルを次に示します。Here's a sample of an AppxBlockMap.xml file.

<!--?xml version="1.0" encoding="UTF-8"?-->
<blockmap hashmethod="http://www.w3.org/2001/04/xmlenc#sha256" 
          xmlns="http://schemas.microsoft.com/appx/2010/blockmap">
  <file lfhsize="66" size="101188" name="asset1.jpg">
    <block hash="2bidNE0JyaO+FjaTpRe0g8HzUCblUf/cfBcTXiZR74c="/>
    <block hash="+jeFwKrGk5gw9wSICWsWRtEQXwcLC7af4EWS7DgrAkY="/>
  </file>
  <file lfhsize="61" size="108823" name="asset2.jpg">
    <block hash="u0+5S0GOzwyAfYx54tKycZyHRBYm2ybvq27dkIKqDsQ="/>
    <block hash="F9h0FRMetL6BNCszAYB0bgyx2KWN+dO1bls4Q9m267c="/>
  </file>
  ...
</blockmap>

最初のファイル (asset1.jpg) には、2 つのブロック ハッシュがあります。 最初のハッシュは、ファイルの最初の 64 KB ブロックを表します。2 番目のハッシュは、残りの 35 KB を表します (ファイルのサイズが 101,188 バイトの場合)。The first hash represents the first 64KB block of the file and the second hash represents the remaining 35KB - given the file is 101188 bytes.

更新中にこのファイルの 2 番目のブロックが変更されると、それを反映するようハッシュも更新されます。During an update, if the second block of that file is modified, the hash is also updated to reflect that. ダウンロード コンポーネントによって 2 番目のブロックが取得され、変更されていない最初のブロックは古いパッケージから再利用されます。The download component pulls down the second block and reuses the first unchanged block from the old package.

大きな規模では、ファイル全体が変更されない場合 (変更されないブロックの完全なセットによって決定されます)、そのファイルを既存のパッケージから再利用して時間とリソースを節約できます。On a larger scale, if an entire file does not change (determined by a full set of blocks not changing), that file can be reused from the existing package, saving time and resources.

アプリの更新プログラムの制約App update constraints

更新は同じパッケージ ファミリ内で実行されるUpdates are performed within the same package family

パッケージ ファミリは、パッケージ名と発行元で構成されます。The package family is comprised of the Package Name and Publisher. 更新できるようにするには、新しいパッケージのメタデータを、以前にインストールしたパッケージと同じにする必要があります。To be able to update, the new package metadata will need to be the same as the previously installed package.

アプリの更新によってより高いバージョンにインクリメントする必要があるApp updates must increment to a higher version

一般に、アプリの更新プログラムでは、新しいパッケージのバージョンを現在のものよりも高くする必要があります。In general, app updates require the version of the new package to be higher than the current one. アプリの更新プロセスでは、既定で下位バージョンのパッケージをインストールすることはできません。The app update process will not allow packages with lower versions to be installed by default. Windows 10 バージョン 1809 以降、更新の引数の一部として上書きスイッチが提供されている場合は、ForceUpdateToAnyVersion を使用して、より低いバージョンのパッケージをインストールすることができます。Starting in Windows 10 version 1809, you can use ForceUpdateToAnyVersion to allow lower version packages to be installed when an override switch is provided as part of the update arguments. これは、現在、ForceUpdateFromAnyVersion スイッチを使用する PowerShell と AppInstaller ファイルで使用可能です。It is currently available in PowerShell using the ForceUpdateFromAnyVersion switch and in the AppInstaller file.

アプリの更新プログラム パッケージはさまざまなアーキテクチャを備えることができるApp update package can have a different architecture

現在インストールされているアプリ パッケージに対する更新プログラム パッケージは、新しいアーキテクチャが展開先の OS でサポートされている限り、異なるアーキテクチャにすることができます。The update package to the currently installed app package can be of a different architecture as long as the new architecture is supported on the OS where it is being deployed to. 次に、例を示します。x64 Windows 10 デバイスに x86 バージョンの MyFavApp (v1.0.0.0) がインストールされていて、更新プログラム パッケージ (v2.0.0.0) が x64 バージョンの場合: MyFavApp (1.0.0.0) は MyFavApp (v2.0.0.0) に正常に更新されます。For example: If you have x86 version of MyFavApp(v1.0.0.0) installed on a x64 Windows 10 device and the update package(v2.0.0.0) is x64 version: MyFavApp(1.0.0.0) will be updated to MyFavApp(v2.0.0.0) successfully.

パッケージは MSIX から MSIXbundle に更新できるPackages can update from an MSIX to an MSIXbundle

更新プログラム パッケージは MSIX パッケージから MSIXbundle パッケージに変更できますが、その逆はできません。An update package can go from MSIX package to an MSIXbundle package but not vice-versa. MSIXbundle がインストールされている場合、パッケージの更新プログラムはバンドルのままである必要があります。When an MSIXbundle is installed, the package update will need to remain a bundle.

差分更新テクノロジの最適化Optimize differential update technology

差分更新テクノロジが最大限に最適化されるようにするための方法はいくつかあります。There are a few ways to ensure that the differential update technology is optimized to the max.

  • パッケージ内のファイルを小さく保つ - これにより、ファイル全体に影響を与えるような変更が必要になった場合でも、更新プログラムを小さいままにすることができます。Keep files in the package small - doing this will ensure that if a change is needed that would impact the full file, the update would still be small.
  • 可能であれば、ファイルへの変更を追加的にする - 追加的な変更にすることで、変更されたそれらのブロックのみがエンド ユーザーのデバイスにダウンロードされるようになります。Changes to files should be additive if possible - additive changes will ensure that end-user devices only download those changed blocks.
  • 可能であれば、ファイルへの変更を 64 KB ブロックに収める - アプリのファイルが大きく、そのファイルの途中に変更を加える必要がある場合は、ブロックのセットに変更を含めると非常に役立ちます。Changes to files should be contained to 64KB blocks if possible - if your app does have large files and requires changes to the middle of a file, containing changes to a set of blocks will help significantly.