Appのアセットを最適化する

(音楽)

(拍手) こんにちは Optimizing App Assetsへ ようこそ Cocoaフレームワーク エンジニアのウィルです 今日は同僚のパトリックと アセットの最適化について お話しします

現在 多くのアプリケーションに 高品質のアセットが使われ すばらしいユーザ体験を 生み出しています アセットの活用で多くの人を 惹き付けているのです 皆さんの役に立てるよう 今日はいくつかお話しします アセットカタログの ベストプラクティスや― アセットのより効率的な 配備方法 そして ユーザ体験を 向上させる方法です

話の中で 基本的な デザインや開発 配備など ワークフローの各工程に 触れていきます その中で まず私がお話ししたいトピックは 画像の圧縮です

画像圧縮は アセットカタログエディタの核です

そしてコンパイル作業の 最終工程で 他の工程の最適化にも 大きく関係します

アセットカタログにはデフォルトで 様々な圧縮タイプがあります また使用する画像やテクスチャに 最適な圧縮タイプを選べます これで十分とも言えますが すべてのオプションを知ることも 大切です さらにトレードオフや プロジェクトへの影響を 理解した方がいいでしょう

さて画像圧縮の詳しい話を 進める前に アセットカタログの もう１つの最適化の話をします その機能は すべての圧縮に関連するもので Automatic Image Packing といいます

アセットカタログが導入される前は アセットを配備するのに 大量の画像ファイルを ただ入れ込むだけでした 注意すべき点は この方法には多くの欠点と トレードオフがある点です まず２つの欠点を 覚えておいてください １つはディスク容量が 追加で必要なことです

従来の画像コンテナの フォーマットは メタデータの保存に 余分な容量を必要とします 画像の属性も同様です アプリケーションに膨大な数の アセットとメタデータがある場合 意味もなく同じ情報が 二重に保存されます

それにアセットの大半が 小さい場合は 画像圧縮の利点が あまり生かされません

もう１つの欠点は 構成上のオーバーヘッドです 未整理の画像ファイルは 作業が大変です それをNSImageや UIImageなどで処理するのは さらに大変なことです

しかも統一されていない フォーマットや― 属性を扱う必要性が生じます 例えばアートワークに 透過性の画像とそうでないものが 混在するなどです 同じことが 色空間と色域にも当てはまります

アセットカタログは すべて解決できます 同じスペクトルの カラープロファイルを持つ画像を グループ化し より大きな 画像のアトラスを作ります そうすれば同じメタデータを 何度も保存せずに済むのです また画像圧縮の利点を より生かせます

では実際の例を見ていきましょう

左側に12個の アートワークがあります 我々のプラットフォームで 見たことがあるでしょう それぞれは小さいですが 全体のサイズは50KBを超えます

そこで Automatic Image Packingです アセットカタログはこれらの画像が よく似たスペクトルだと識別 そしてグループ化し １つの画像アトラスを生成します

この方法では―

全体のディスク容量が 元々のわずか20％に下がります つまり80％もサイズを減らせました

この最適化の割合を把握することも 重要です アプリケーションの アセットの数が増えるほど 最適化の恩恵も大きくなります

Automatic Image Packingでした

次はロッシー圧縮の話をします

これは画像の解像度を 少し落とす代わりに 高い圧縮率を実現する方法です ロッシー圧縮を使用すべきかは アプリケーションの状態によります

通常 スクリーン表示時間が短い アートワークには ロッシー圧縮を推奨します

例えばアプリケーションの スプラッシュ画面や アニメーションや効果に 使う画像です

これからご紹介するのは アセットカタログの 新しいロッシー圧縮です それは 今年サポートを 拡大することになるHEIF ハイ･エフィシエンシー･イメージ･ ファイル･フォーマットです

昨年の発表を見た方は HEIFフォーマットの導入を ご存知ですね すべてのプラットフォームと アセットカタログに採用しました 今年はもう１歩前進します アセットカタログに HEIFのロッシー圧縮を追加します

(拍手) どうも

では HEIFの長所を 手短にお話ししましょう

最大の利点は 従来のロッシー圧縮に比べ HEIFの圧縮率は非常に高いことです 従来のフォーマットとは JPEGなどです

他にも多くの長所があります すぐに使える透過性の サポートなどです

もっと重要な特徴もあります アセットカタログは 他のフォーマットの画像ファイルを 自動でHEIFに変換できます つまり画像アセットを ロッシー圧縮にひも付けておけば 開発側は 他に何もしなくていいのです コンパイル時にすべて自動で 行われます

HEIFフォーマットの詳しい情報は 昨年のセッションを参照ください

ではロスレス圧縮の話に移ります これはデフォルトの圧縮タイプで アセットの大半に使われています

ですからロスレス圧縮の最適化は 非常に重要です

通常 アートワークは カラースペクトルのプロファイルで ２つのグループに分類されます ロスレス圧縮によるメリットは それぞれ異なります 見てみましょう

１種類目はいわゆる 単純なアートワークです 単純とされる理由は― カラースペクトルの範囲が狭いこと そして個別のカラー値が 小さいことです

シンプルなデザインだからです 多くのアイコンがこのタイプです

もう一方のタイプはいわゆる 複雑なアートワークです

前述のとおり ロスレス圧縮の 利点は各タイプで異なります 両タイプともロスレス圧縮に 適しているため 非常に効果的です

我々はこの両方が重要だと 気付きました それに すべてのアセットを 最高のロスレス圧縮で配備したい そこで新機能を追加しました アセットカタログの 新しいロスレス圧縮です

その名はApple Deep Pixel Image Compressionです

(拍手) ありがとう

この新機能は カラースペクトルに適応する― フレキシブルな圧縮です カラースペクトルの特質に合わせ 最適な圧縮アルゴリズムが 選択されるのです

今年発表のこの新しい圧縮は 皆さんだけでなく 我々のすべてのプラットフォームと アプリケーションでも利用可能です

これにより既存の全プロジェクトで 平均20％のサイズ縮小が 可能になりました 大きな改良です (拍手)

では数字を見てみましょう

この表は各プラットフォームの アセットカタログの 全体のサイズを示しています

すべてのプラットフォームで 最大20％も サイズが削減されていますね

ロスレス圧縮で重要なのは 圧縮率だけではありません 大半のアプリケーションで 使用されているため デコード時間も同様に大事です Apple Deep Pixel Image Compressionは デコード時間も 最大20％短縮できます

以上がロスレス圧縮でした 今から ２つのトピックについて話します 互いに関連するものです 先ほど話した最適化と圧縮にも 大きく関連します

それは配備とApp Thinningです

まずはApp Thinningの概要です App Thinningは App Store内のプロセスです 全デバイスモデルと 配備ターゲットのバージョンに プロジェクトのバリアントを 生成します

App Thinningが有効な時とは？ それはアプリケーションの 配備ターゲットのバージョンが 最新ではない場合です そうすれば 幅広く利用されるからです

App Thinningは すべてのバリアントを自動で生成し 各ユーザに最適なものを 配備できます

今年 Xcode 10と iOS 12用のSDKで開発すれば 自動的にあらゆる最適化と 最新の圧縮機能が利用できます

しかし以前のバージョンを 配備ターゲットとする際は

最新の最適化は適用されません

旧バージョンと 互換性のあるバリアントを 生成する必要があるからです

しかし私たちはアセットを 最適な方法で配備したいので これは理想的ではありません そこで今年はApp Thinningの 新バージョンを発表します OS Variant Thinningです

OS Variant Thinningでも

古いプラットフォームを 配備ターゲットにできます 例えばiOS 9からiOS 11です

OS Variant Thinningは 最新のiOSに 特別なバリアントを生成します そして最新の最適化と圧縮機能が 使えるのです つまり最も効率の良いバージョンを みんなが利用でき みんなが満足できます

(拍手) App Thinningと逆行の配備でした

次はXcode上で App Thinningを使い ローカルにエクスポートする方法を ご説明します

やり方は簡単です Xcodeの“Archive”を 選ぶだけです これでXcodeが バリアントを生成できます

次に“Organizer”を クリックしてください すると生成したバリアントが 表示されます

これがウインドウで 今回の例はGarageBandです

まずは配信方法の選択画面が 表示されます すべてのバリアントの配信用です

この例では配信は“Ad Hoc”を 選びます

次のウインドウの App Thinningのフィールドで “All compatible device variants”を選択 これでXcodeはサポートされる 全デバイス用のバリアントが エクスポートされます

次に生成したバリアントを含む レポートが Xcodeで作られます アプリケーション配備の 詳細を知りたい時に レポートで確認できます 基本的な質問もあると思います 生成したバリアントの数は？ そのサイズはどれくらい？ 特定のバリアントの最適化や 微調整をする余地は？

このGarageBandでは 生成された半分がエクスポートに 見てみましょう

この表をご覧ください

この表では― 各デバイス用のバリアントの サイズが比較できます

これは iOS 11以前の バージョンのバリアントです

GarageBandは膨大な数の画像を含み 容量が大きく バリアントのサイズは 90MBから100MB以上です

そしてこれがiOS 12の数字です

その差は一目瞭然でしょう 10％から20％程度も サイズが縮小されています

数字に見覚えがありますね これはすべて 先ほど話した 最適化と圧縮によるものです

以上が画像圧縮でした では次に同僚のパトリックが デザインと制作について話します (拍手) ウィル どうも

Xcodeのアセットカタログを使って 簡単にアセットを 改良する方法でした あと少し アセットカタログを活用して アセットを最適化するやり方を 説明しましょう まずはデザインと制作の話です これがすべての原点です

アセット用の様々なツールや ワークフローやソースがありますが 結局はすべて 人間が作っているのです そこで情報を整理して アセットが開発のワークフローに 入るプロセスを理解しましょう そうすればアプリケーションは 大きく改善されます

まずはカラーマネジメントの話です 見過ごされがちですが重要です

ディスク内の画像アセットは 色の無い状態では ただのバイトで 何の意味もありません ではどうやって 色が与えられるのでしょうか？ カラープロファイルが使われます それが測色値をタプルに与えて システムに どんな色を表示するのか教えます ソースアーティファクトで カラープロファイルを保管します そのメタデータを利用すれば デザイナーの意図を そのまま伝えられます これを余分なメタデータかと判断し プロファイルを 消去しないでください 大事なソースアーティファクトです 最適化はツールに任せましょう

色の管理がなぜ大事なのか？ それはデバイスによって ディスプレイが異なるからです そしてどのディスプレイにも 正しく色をマッチさせ 表示し再現する必要があります それが カラーマネジメントの仕事です 計算が必要なので CPUかGPUで処理されますが 少々手間です そこでアセットカタログの出番です コンパイルの間に カラーマッチングを行います つまりデバイス上での計算処理を 省略できます すぐにアセットをデバイスに ロードし表示できるのです この処理にはオマケがあります カラープロファイルのペイロードを 削除します さらに効率の良いことに 色空間とディスク上のピクセルの 注釈も付けられます

カラーマネジメントでした 次のトピックは ワーキングスペースです ワーキングスペースとは アセットが最初に作られる 環境のことです アートワークを作る デザイナーやエンジニアが デザインツールでコンテンツを 作ります ここで重要なのは すべてのデザインファイルに 一貫した カラー設定を使用することです これは良い習慣で 技術的な利点もあります なぜなら アプリケーション全体を きちんと管理することに つながるからです 作業用デザインファイルの作成時に 推奨されるフォーマットは ２種類あります 最もよく使われるのが sRGB 8ビットです 全デバイスとコンテンツに 幅広く適用されます しかし 斬新で 色鮮やかなデザインもありますね 例えばこのアイコンです これを幅広い色に対応可能な デバイスで生かすため 広い色域やカラーアセットを 使いたいでしょう その場合 Display P3が最適です デザインの損失を防ぐため 16ビット/チャンネルにします Xcodeや ランタイムプラットフォームで 広いカラーアセットを扱う方法は 多彩です ここでは詳細を省きますので ２年前の“Working with Wide Color”をご覧ください このトピックの詳細と背景が 分かります P3アセットの詳細は ホームページを参照ください developer.apple.comの iOS デザインリソースセクションです

では次の話に移りましょう

アートワークについて 皆さんが作る― UIは色々な表示やレイアウトに 対応する必要があり アートワークを 引き伸ばしたりして レイアウト変更に対処します どのように行うか？ 最も一般的な方法は 画像の伸縮部と非伸縮部の特定です 違いは？ スライドの例は ある画像だと想像してください 丸い角の美しい形状を どのサイズでも保持したい 青色の部分を 伸ばすことはできませんが 黄色の部分は可能です 通常これを行うには デザインツールを使って すべてをスライスします 次に各リージョンを 個別のアセットとして支給 それを３または９分割の APIを使って 最終デザインのサイズにします 長年 これが有効かつ 一般的な方法でした しかし短所があります 最後の画像の再構築は CPUの負荷が大きく 複雑で非効率とも言える作業です 現在のCore Animationのような 機能にも合っていません

より良い方法は？ それは単一の画像を使い そこに伸縮部分を特定する メタデータを提供することです それは最適な GPUアニメーションを可能にします

アセットカタログでは これが簡単にできます Show Slicingエディタです まずStart Slicingに進み 境界線を操作します この線で画像の 伸縮部と非伸縮部を設定します この例ではオレンジ色の両端と 中間のスライスが伸縮部です 見てのとおり 白く影のかかった 大きな部分がありますね これは何か？ 面白いことに アセットのこの部分は もう必要ありません 残りの３つで サイズを示せるからです これがなぜ重要か？ ビルドの際にXcodeが 必要な部分を認識し その他の部分はそのまま残します 不要な大部分を ディスク容量から減らせるので 便利です そして２次的な利点もあります 私はこれが気に入っています デザイナーはアセットを 自然なサイズで作ればいい 効率的に配置するため 最小サイズで最適化するなどは 気にしなくていい それより長期的には― ソースコードを 分かりやすくするほうが大事です 配置はツールに任せましょう

伸縮部は図で確認や設定を できますが Show Slicingインスペクタも あります 両端の微調整が可能で 中心部のビヘイビアを 伸縮かタイルに設定できます

その結果 伸縮のメタデータを アートワークに近付け 最終的に大きな利益を もたらすのです デザインに変更を加える際は すべてを一括で更新するだけです コードの位置を覚える必要は ありません １ヵ所にまとまっていますから

どうも (拍手) 次はベクターアセットです ディスプレイの解像度は 製品によって異なるので ターゲットに合わせ1x 2x 3xの アセットを作成します これでうまくいっています しかしデザインごとに アセットを２～３つも納品するのは 無駄とも言えます アセット１つで対応可能か？ アセットカタログのPDF用 ベクターアセットなら可能です Xcodeのアセットカタログは PDFを扱えます XcodeがPDFを必要な倍率に 自動で生成しラスタライズします これで異なるターゲットに 適用できます PDFのベクターアセットを レンダリングしなくて済むので デバイスのランタイム時に コストがかかりません 安心してベクターを使えます さてアセットには 最も自然なサイズがあります しかし場合によっては― 違う大きさで アセットを表示したい時もあります 昨年からiOS 11とXcode 9では ベクターデータを保存できます ですから その画像を自然なサイズより 大きな画像ビューに入れられます そして元のPDFベクターデータを 見つけます これは無関係なメタデータや プロファイルとは 切り離されてスリムな状態です サイズを変える場合のみ 再度ラスタライズします それ以外は最適化された ビットマップを使います アプリケーションは より柔軟に動的タイプに対応 UIImage Viewのサイズ変更時に 画像が 自動的によりハッキリします

ベクターアセットは以上です

次は2x用のデザインについて お話しします

2xとはRetinaディスプレイです 最もよく使われている表示密度で 皆さんもよくご存じでしょう すばらしいディスプレイで 大きな前進でした しかし まだ 使用するデザインによっては―

細かい線やエッジが ぼやける場合があります エッジがシャープかファジーか 分からない程度の解像度です アセットのデザインにおいて いまだに課題です

この問題の解決に役立つ技術は？

１つがベクターデザインツールの ポイントバウンダリスナッピングです １ポイント間隔でグリッドを設定し スナッピングをオンにします 形やコントロールポイントの調整は スナップだけで スナップ先の境界線は ピクセルの境界になります 便利ですね しかし次のような場合もあります なぜかエッジが ポイントの間にくるが

Retina 2xのデバイスのために― 表示密度に合うよう アセットを 最適化したい場合などです そんな時は2xのグリッドを使い アセットを２倍のサイズにします つまり２ポイントが １ピクセルグリッドで ２単位が Retinaの１ポイントになります 次にアセットを調整し ポイントスナッピングを使い 線やエッジをポイントに合わせます

では その後はどうするか？ 大きすぎて使えない？ 使えます アセットカタログのスケールビンの 2xに入れるだけです そうすればXcodeが 自動で処理します これは2xのアートワークで １ポイントは Retinaの２ピクセルではない その逆だと認識します すべて計算し ラスタライズされたビットマップを 他の倍率にレンダリングします デザイナーは2xグリッドだけ 使えばいいのです

自動のスケーリングが不十分で まだ問題がある場合 最終的に開発側で コントロールできます ビットマップを適切な倍率のビンに 入れてください ラスタライズされたPDFより それが優先されます

デザインと制作についての話は 以上です 次はカタログ化と Xcodeの構成について話します Xcodeのアセットカタログを 使ってみた方は できる事とオプションの数に 圧倒されたでしょう 私は意味があるものだけを 使うことをおすすめします 皆さんのプロジェクトや コンテンツに関わる項目だけです オプションは多くエンジンは強力で 多くの機能が備わっています ですが目的に沿って 簡単な操作から始めてみてください

これから役に立つ構成上の技法を ２つ説明していきます １つ目はバンドルです アセットに なぜバンドルが関係するか？ 理由は 大型プロジェクトに有効だからです 複数のフレームワークや 複数のチームが関わる 大型プロジェクトもあります 複数のアセットをすべてメインの バンドルに集め 管理するのは大変です そして該当箇所と うまくひも付くよう 名前を付ける必要があります 対処法の１つは複数のバンドルを 作成することです Xcodeは各バンドルに単一の アーティファクトを作るからです 例えばアートワークだけの バンドルを作る これは再利用のいい戦略です すべてのアートワークを 一貫したネームスペースで １つに整理して管理するのです アプリケーションの他の部分にも 画像を提供できます

どうやって取り出すか？ イメージコンストラクタの “UIImage.Name”“in: Bundle” などでバンドル引数を取得 macOSにはNSBundleの リソースがあります バンドルは 単一のネームスペースです つまりその中で 同じ名前にはできません ですが別のバンドルなら 命名規則も不要です

ネームスペースについて話しますが これも大型プロジェクトの課題です 次の例では大きい集まりの中に いくつかの構造が存在する場合です 例えばアプリケーション内に 50の部屋があり 各部屋にテーブルといす そのアセットがあります コードにテーブルといすを 入れたいが50個もある さてどうするか？ 選択肢の１つは ある命名規則を作り コードに入れますが これは理想的ではない そこで“Provides Namespace” オプションです アートワークをフォルダに整理し ここをチェックします そうすればアセットカタログ内の 各画像の先頭に 自動でフォルダ名を 追加するのです 後で簡単に取り出せます アセットの大きな集まりを うまく整理できます 以上 カタログ化について 話しました 次は配備について話しましょう この工程から楽しくなります

前述のApp Thinningに関する アセットカタログの活用法を 見てみましょう 概要としては全コンテンツの バリアントの作成です 各デバイスに合わせるための 作業です 最も一般的な方法は 製品群ごとに分けるやり方です iPad iPhone TV Watchなど もしくは3xと2xの解像度ごとに 分けます コンテンツ最適化のため バリアントを提供すると App Thinningが 正しいサブセットを選択 アプリケーションを使うデバイスに 合わせます

さてコンテンツの適応には もう１つの方法があります その別のアプローチは 性能のクラスです もしアプリケーションが すべての製品群を認識する際に 先ほど述べた特徴ではなく 性能別で分けるとしたら？ アセットカタログでは可能です デバイスごとにハードウェアの 性能は大きく異なります 例えばiOSでもiPhone 5と 最新のiPhone Xでは 性能の差は非常に大きい それを利用すればサポートする 最も低性能のデバイスに アプリケーションを 合わせる必要もなくなります それを両立させるのがゴールです 解決法はアダプティブリソースです これから説明します 性能で区別するための 主な方法は２つ １つ目はメモリのクラスで これは重要です １GBから４GBまで４段階あり 様々な製品のメモリに対応します これはそれが何かに関わらず すべての製品に当てはまります

２つ目はグラフィックスの クラスを使う方法です 実際には２つのものに対応します １つ目がMetalのバージョンです それはGPUのコンセプトと同じです またデバイスの 特定のプロセッサにも一致します Metal 1はA7に対応し Metal 4はA11に対応します 各グラフィックスのクラスに アセットを分類し割り当てられます

どちらかだけでも強力ですが 両方の特徴を組み合わせると 非常に興味深いのです 性能のマトリックスを作り アセットの適応先が どこになるか確認してみましょう

具体的にどう働くか？ 簡単な例を使って説明しましょう これが仕組みを理解し 利用するためのキーとなります この例のアセットは３つ “AnyとAny”は より低性能のデバイス用です あと２つは最適化されたアセットで ３GBのMetal 3用と ２GBのMetal 4用です 私はiPhone 8 Plusを基準として アセットを選んでいるとします つまり４GBのMetal 4です メモリ軸の４GBには何もありません 次に 他のものを探して 下がっていくと ３GBが見つかりました そしてアセットを見つけ― 選択します 私がどのアセットを選んだかが 重要です ３GBのMetal 3でした 実はGPUのクラスには 一致するものがありました しかし メモリを グラフィックスより先に探したため メモリから選択しました これは非常に重要です 性能を決めるのは メモリだと判断したのです それに従い マトリックスを進みました

この仕組みを生かしましょう メモリはデバイスの ヘッドルーム全体や 性能を最もよく示す指標です 大きくリッチなアセットを 使いたいと思います それにはレンダリング時など 大量のメモリが必要です 豊かなユーザ体験には メモリが要ります 高性能なグラフィックスは CPUとGPU両方の処理能力と 関連するため― 複雑なアセットに向きます 特定のGPUと機能でしかできない シェーダを使ったり 少し多めの処理が必要な アセットを含めたり ２つの例を挙げて どうなるかを見せます

NSDataAssetを用いて 説明します NSDataAssetはシンプルですが とても強力です アセットカタログに フレキシブルなコンテナを提供し 任意のファイル周辺に バリアントを格納 画像だけでなく何でもいいのです App Thinningでこれを使い 各データを各性能クラスへ 転送できます 例えば ゲームの カットシーン用の動画です 性能スペクトルの中レベルの動画を 使うかもしれません またはスペクトルの最高レベルの 高解像度の動画を 提供することも可能です もしくはローエンドな 静止画や簡単な連続イメージも 使えます 時間や過度なリソースを かけないので 使用時も反応が良いのです

もう１つのより面白い例は plistです なぜアセットカタログでplistを 使うのか？ NSDataAssetと共に使い アプリケーションを調整できます NSDataAsset内で plistを 収めた性能クラスに対応する― 設定パラメータを使うのです 例えば雲をレンダリングする アプリケーションで ハードウェアに合わせ 雲のサイズを設定できます 使われている 実際のデバイスに合わせ コードが自動で調整されます 以上が性能クラスの話でした

次はSprite Atlasの話です 数年前に発表された Sprite Atlasは SpriteKitゲームを サポートします

しかし SpriteKitゲームではなく 一般的なコンテキストで話します

これはAutomatic Image Packingと 同様の属性を持ち Sprite Atlas内に 関連する画像を１つにまとめます 画像は１度にロードされ アトラス内で参照される全画像は アトラス内では軽量化されます すばらしいです

重要なのはSpriteKitを 使わなくてもいい点です Sprite Atlasではグループを管理し 名前を付けられます そのように複数のものを 整理して管理できます またUIImageやNSImageのような APIか名前で 画像にアクセス可能です SpriteKit以外の アプリケーションにも SpriteKitを使えます SKTextureAtlas.preloadTexture AtlasesNamedです 多量の画像を すぐに読み込み使いたい時に このAPIが役立ちます それは事前に もしくはその場でロードし デコードし 非同期でメモリに読み込みます 完了ハンドラが名付けられた アトラスを処理します 使用の際は注意点もあります 無差別に使わないでください 指示内容を そのまま実行するからです つまり大量のI/Oとメモリを消費し すべての画像をロードする 可能性があります ですから すぐ使うべきか 正しく判断しないと 大変なことになります

Sprite Atlasの強みはまだあります Sprite Atlas内の全画像は アセットカタログの画像と 同じ機能が使えます 例えばカタログ化や圧縮の すべての設定と App Thinningなどです 画像を自動で分割し 順番に並べます 分割はピクセルやデバイスや 圧縮のタイプによります そしてすべてが適切に 読み込まれ最適化され すぐにデバイスに送られます

以上が配備の話でした さあ あと少しです では重要なポイントを おさらいしましょう 何よりもまず肝心なこと 画像リソースの管理には アセットカタログが最良の選択です 今年は新しい圧縮で10～20％も ディスクの容量を削減できます App Thinningの改良により iOS 12のユーザは 最適化された状態を楽しめます 配備ターゲットは関係ないのです アプリケーションのリソースを デバイスに適応させる― カタログ化機能も紹介しました

その他の情報は こちらのリンクをご覧ください それでは― 皆さん 良い１日を ありがとう (拍手)