毎年、Apple は新しい iPhone をリリースし、RAM とメイン メモリのサイズを徐々に増やし、チップの性能を高めています。現在、iPhone 15 では、すでに「バイオハザード 4」などのコンソール ゲームを実行できます。そして、アプリケーションのサイズを最適化する必要があるのか、それとももっと時間をかけてもいいのかという論理的な疑問が生じるかもしれません。 つまり、サイズを最適化する価値は依然としてあるということです。この記事では、そうすることが不可欠な理由をまとめ、便利な最適化方法をいくつか紹介しました。 問題と定義 それでは、「なぜサイズが重要なのか?」という質問に対する最も平凡な答えから始めましょう。 - App Storeの制限事項。 App Store Connect では、指定されたサイズ制限を超えるファイルのダウンロードは許可されません。 iOS および tvOS アプリの場合は、アプリがサポートされているオペレーティング システムの最大ファイル サイズを超えていないことを確認してください。アプリの非圧縮サイズの合計は 4GB 未満である必要があります。 Apple Watch アプリは 75MB 未満である必要があります。さらに、各 Mach-O 実行可能ファイル (例: app_name.app/app_name) は、これらの最大ファイル サイズを超えてはなりません。 リンク 参照している特定のファイルは少しわかりにくいかもしれません。これをよりよく理解するために、アプリケーションを App Store Connect に送信するプロセスを見てみましょう。 .xcarchive 最初のステップはアーカイブを作成することです。このアーカイブには、iOS、macOS、watchOS、または tvOS アプリのビルド アーティファクトと関連情報のコレクションが保存されます。 私たちはアーカイブに正確に何が、どのような形で含まれているかを調べる機会があります。 主要なファイルには次のものがあります。 アプリの製品フォルダー。 dSYM (「デバッグ シンボル」の略)、デバッグに必要な情報を含む Xcode によって生成される特別なファイル、つまりクラッシュ ログ。 情報.plist; ちなみに、アプリケーション ファイルは「パッケージの内容を表示」からも開くことができ、ファイルの中には実行可能ファイルとコード署名の結果である CodeResources が含まれています。さまざまなアプリケーション リソース (画像など) のデジタル署名を追跡します。 .ipa Xcode に戻ると、アーカイブを生成した後、 ボタンが使用できるようになります。この段階で、 に変わります。 Distribute App .xcarchive は .ipa ファイルは、「Payload」フォルダーを含む圧縮パッケージと考えることができます。この「Payload」フォルダー内には、必須の「YourApp.app」バンドルがあります。 「.app」バンドル内には、次のようなリソースを含む、アプリケーションの重要なコンポーネントがすべて含まれています。 .ipa 画像; plist ファイル; 圧縮された nib ファイル。 ; 実行可能ファイル さらに、アプリの整合性とセキュリティを確保するためのコード署名リソースも格納されています。 の内部を確認するには、配布後に をクリックし、タイプを から 抽出するだけです。 .ipa Export .ipa .zip に変換して、 要約すると、 ファイルはエンドユーザーが iOS デバイスにインストールするパッケージ化されたアプリケーションであり、 はアプリケーションのさまざまなアセットとビルド情報を含む開発者向けのアーカイブです。 .ipa .xcarchive 配布に使用され、 デバッグ、アーカイブ、およびさらなる開発の目的に使用されます。一方、実行可能ファイルはアプリの機能を実行する中心的なコードであり、 パッケージ内に含まれています。 .ipa は .xcarchive は .ipa したがって、AppStore の制限は次のように説明できます。 OSバージョン .ipa サイズ .ipa -> ペイロード -> アプリ -> exe サイズ iOS 9.0以降tvOS 9.0以降 4ギガバイト 500MB iOS 7.X ～ iOS 8.X 2GB 60MB ただし、最終的なアプリケーションのサイズ、つまり特定のユーザーがデバイスにインストールする必要があるバイト数を見積もるには、追加のアクション、つまりアプリ サイズ レポートの生成が必要になります。作成手順はドキュメントにしっかり記載されているので残しておきます。 ここ。 リンク アプリケーションのサイズについて考える次の理由は、再び AppStore ですが、ここではシステム制限についてではなく、 について話します。ここではすべてが明らかです - サイズが小さいほど、レートが高くなります。 ダウンロード速度 さらに、ユーザーがアプリをインストールするために Wi-Fi ネットワークに接続する必要がある 200 MB の制限があります。遅延はユーザーの意欲をそぎ、放棄率の上昇につながる可能性があります。 Apple の App Store の検索および検出アルゴリズムでは、ユーザーがダウンロードして試しやすい小型のアプリが好まれることがよくあります。アプリのサイズを小さくすると、検索結果やおすすめでのアプリの可視性が向上する可能性があります。 アプリがデバイス上に配置された後も、そのサイズが重要になります。小さいアプリほど起動が速くなり、ユーザー エクスペリエンスが向上します。アプリがストレージを最適化すると、バッテリー寿命の延長、アプリのフットプリントの削減、デバイスの良好な状態に貢献します。その結果、iPhone に満足する人が増えれば増えるほど、潜在的なユーザーの数も増えます。 ソリューション 開発中にアプリケーションのサイズが不必要に大きくならないようにするための簡単なヒントがいくつかあります。 1つ目は、イメージを使った意識的な作業です。 画像 まず、JPEG ではなく を選択します。 HEIC は、同等の画質を維持しながら、JPEG と比較して 50% 小さいファイルを提供します。これにより、デバイス上のストレージ容量が減少します。ファイルが小さいほど、ネットワーク間でのファイルの転送が容易になり、ディスクへの読み込みや保存も速くなります。 HEIC HEIC は、画像の透明性と、深度と視差情報を含む補足画像を保存する機能をサポートしています。可逆圧縮をサポートしており、単一のコンテナ内に複数の画像を保存できます。 次に、PDF や PNG の代わりに (2 次元のベクター グラフィックスを表示するために使用される XML ベースのベクター画像形式) を採用してみてください。ラスター イメージとは対照的に、ベクター グラフィックスは、個々のピクセルを保存するのではなく、形状と曲線を定義する数式によって特徴付けられるため、通常、ファイル サイズが小さくなります。 SVG 最初は、(ピクセル密度ごとに) プレフィックス付きの 3 つの画像を追加する必要がありました。その後、PNG サポート (= 指定されたサイズのベクター画像) が追加されましたが、それでも「プロジェクトを組み立てるときに PDF から 3 つの PNG を切り出す」というレベルで機能しました。 そしてそのとき初めて、SVG を使用し、アセット カタログに「ベクター日付を使用」チェックボックスを含めることが可能になりました。これにより、使用される画像のサイズが大幅に削減され、品質を損なうことなく無限のスケーリングの可能性が追加されました。 3 番目に、 の機能を最大限に活用します。アセット カタログは、同じ画像の複数の解像度に使いやすいストレージを提供します。さらに、カタログには、すべての画像アセットが個別のファイルではなく、メタデータを含む単一の最適化された形式で保存されます。 アセット カタログ これにより、App Store は特定のデバイスに必要なアセットのみを提供できるようになります。これはダウンロード速度の向上につながりますが、ユーザーが待つことを好まないことはすでにわかっています。 リソースに「オンデマンド」を設定することが可能です。つまり、リソースは必要な場合にのみデバイスにダウンロードされ、しばらく使用されないと削除されます。 リンク 「無料」画像の膨大なカタログがあることを忘れないでください - 。 Apple は常にキャラクターを増やし、色やアニメーションをカスタマイズする機能を追加することに取り組んでいます。 SF Symbols そのため、写真やその他のグラフィック リソースに関しては、すべてが明確であるように見えます。正しい形式を使用し、アセットを通じてカタログを追加しています。最終アセンブリに大規模なリソースを含めず、必要に応じてインターネットからアップロードするだけの機会が常にあります。ここで、コードとライブラリの使用について話しましょう。 フレームワーク管理 リンクについて簡単に思い出させてください。これには、静的と動的の 2 つのタイプがあります。 静的 動的 リンクが発生した場合 ビルド時間 ランタイム 依存関係が保存される場所 最終的な実行可能ファイル内 個別の動的ライブラリ内 依存関係がどのように共有されるか 同じコピーがアプリのすべてのインスタンスで使用されます アプリの各インスタンスには独自のコピーがあります 依存関係の更新がどのように処理されるか アプリを再構築する 動的ライブラリを更新する この記事のテーマによれば、依存関係のストレージは私たちにとって特に重要であり、動的リンクは私たちのお気に入りのようです。 動的ライブラリはクライアント アプリに静的にリンクされません。これらは実行可能ファイルの一部にはなりません。代わりに、アプリの起動時または実行時に、動的ライブラリをアプリにロード (およびリンク) できます。 リンク 簡単に言うと、静的ライブラリではなく を選択すると、アプリのファイル サイズが小さくなり、初期メモリ使用量が少なくなります。ただし、アプリの起動時にパフォーマンスの遅延が発生する可能性があるため、バランスを取り、動的ライブラリの過度の使用を避けることが重要です。 動的ライブラリ Apple は、アプリ内にモジュラー コード ベース ( ) を作成することも推奨しています。これは、他のターゲット (App Clipps など) とコードを共有するときに便利です。 SPM Swift Package Manager は、Swift プロジェクトの依存関係を管理するための合理化されたネイティブな方法を提供します。 過剰なファイル アプリのサイズを減らす最も効果的な方法の 1 つは、不要なファイルをすべて削除することです。これらの追加ファイルには、Read.me や残りの画像などがあります。実際、記事の冒頭で .ipa とは何かを理解したところで、AppStore に入るすべてのファイルを見つける方法をすでに学びました: .ipa -> .zip -> App -> show packageコンテンツ。 不要なリソースをすべて見つけて、アプリから 。 自由に削除してください 結論 要するにこれです。アプリのサイズに注意を払う必要がある重要な理由がまだいくつかあります。 App Store の制限。 ダウンロードと起動の速度。 デバイスのバッテリー寿命への影響。 アプリのサイズを減らす方法はいくつかあります。 画像の HEIC および SVG 形式。 資産カタログ。 動的リンク。 余分なファイルをフィルタリングします。 したがって、日常的な開発中にこのことを忘れないでください。毎日賢くなりましょう 🙃
