Images.xcassetsは多くの素晴らしい機能を提供します。特に、スライシングと、デバイスの種類ごとに個別の画像を追加する機能が気に入っています。 したがって、考えずに新しいプロジェクトを開始し、Images.xcassetsを作成し、そこにアイコンとスプラッシュを追加してから、すべての新しいリソースもそこにスローします。 今日、私はxcassetsについていくつかの不愉快なことを学びました。それは私にそれを放棄させ、プロジェクトの作り直しに数時間費やしました。 最も楽しいと感謝の仕事ではありません。 他の人の過ちから学びたいなら、猫をお願いします。
少しの背景
愛好家のグループが、iPadで子供向けのおとぎ話を作成しました。 これはリッチではなく、私たちの目標はiOS 8のすべてのデバイスで動作する良いアプリケーションであることを事前に理解しています。また、痛みを伴う身近な状況を避けたいと思いました。 。 そのため、インストール後にアプリケーションを使用できるように、すぐに少なくとも1冊の本をアプリケーションに入れたいと思いました。 この本はjpeg形式の図であり、圧縮しない場合、最小の本の重量は82Mb、残りの100 + Mbです。 したがって、3gでダウンロードする機会を残したい場合は、アプリケーション用に18Mbが残っています。 これは子供向けのアプリケーションであり、多くの写真があり、それらのほとんどは装飾や模様が付いているため、絞ったりカットしたりすることができないため、これは不可能に思えます。 このような初期データを使用して、xcodeプロジェクトを作成しました。記憶のための最初の戦い
私がプロジェクトを始めたとき、私はテストデバイスからiPad Airだけを持っていました。 すべてが飛んでいますが、これはすでに隠すべき罪です-テストには悪い選択です。 そのため、プロジェクトの完了に近づいて、iPad mini 1 gen-RetinaなしでA5プロセッサを搭載したデバイスを購入しましたが、iOS 8、さらにiOS 9を搭載しています。アプリケーションのデバッグ中に、時々メモリ警告が表示されました。 注文しないでください。 [デバッグ]タブを開くと、アプリケーションが100 MBを食いつぶしていることがわかります。 そして、これは特別なことは何もせず、アプリケーションを開くだけで、ナビゲーションスタックに3つのコントローラーしかありませんでした。 プロファイラーを開くと、70Mbが写真で占められていることがわかります。 iPad miniの100 Mbは明らかに過剰です。 そのため、1xスケールで多数の写真を追加する必要がありました（iOSの場合はNeretina用に準備することを知っていたため、追加する前に追加しませんでした）。これは、理論的にはアプリケーションのサイズに大きな打撃ではありませんが、使用されるメモリの量を大幅に削減します。 その結果、47MBになりました。 私の意見では、それはまだ正当化されていませんが、メモリ警告は届きません。サイズのために戦う
そして昨日、アプリケーションの開発を終了しました。 もちろん、いくつかのTODOが残っていて、みんながそれをテストし、おそらく何かを見つけるでしょうが、最初のフェーズは終わりました。 喜びのために、私はチームの残りの部分にビルドを展開しましたが、同時に142 MBの重さを訴えました。これは、アプリケーションに縫い付けられた本を2倍に減らす必要があることを意味します。これは非常に不快で、目で見て品質が低下することに気づきます。 そのため、今日、アプリケーションのサイズに取り組み、品質がそれほど損なわれないように、フックまたは詐欺師によってアプリケーションのサイズを減らすことにしました。ステップ1-占有スペースが大きいものを確認する
build.ipaを取得し、その名前をbuild.zipに変更して解凍し、build.appの内容を確認します。 53 MBのファイルAssets.carを見つけました。 原則として、アプリケーションのサイズは説明可能です-80 + 53 +詳細。 そのように開くことは不可能であることを理解しているため、プロジェクトでImages.xcassetsを表示することにしました。 重量はわずか38Mbです。 それはどういうことですか？ 彼らはそこで16Mbに何かを置きましたが、どうやらそれを私に伝えるのを忘れていました。ステップ2-彼らはそこに何を追加しましたか？
ネットワークの広大さをすばやく検索すると、 Assets.carを表示するためのツールが提供されます。 指示に従ってすべてを実行します。プロジェクトを収集し、組み立てたcartoolを取り出してAssets.carで実行します。 結果として得られたものを見てください-合計サイズが41.5Mbの130ファイルで、3.5Mbがpngcrushに書き込める場合、11.5Mbはどこに行きましたか？ネットワーク上で大まかな検索を繰り返します。 たとえば、同様の問題があります 。 そして、私が支払っているのは約29％で、そこのサイズは一般に6倍になっています。 しかし、これは私の場合ではありません-ほとんどすべての画像が透明な背景の領域を持っているので、私はすべてのPNG画像を持っています。 この状況を是正する希望はもうありません。 Appleのドキュメントをもう一度確認しています。アプリケーションのダウンロードを高速化するためにバイナリファイルを作成しました。 私の場合、ダウンロード速度はサイズに依存します。 そこで、Images.xcassetsからすべての画像を削除し、昔ながらの方法でプロジェクトに追加することにしました。 私はいくつかの場所でコードをスライスする必要がありました
- (UIImage *)resizableImageWithCapInsets:(UIEdgeInsets)capInsets
このような詐欺により、アプリのサイズを142Mbから131Mbに減らすことができました。 私は間違いなくアプリケーションのリソースを最適化し続けますが、Images.xcassetsを放棄するための10Mbはすでに悪くはありません。
ステップ3-メモリはどうなりましたか？
iPad miniで起動-23Mb対47Mb。 iPad Air 66Mb対100Mb。おわりに
142Mbと131Mbの違いは小さいように見えるかもしれません。 しかし、これは写真やその他のトリックの品質を損なうことなく、非常に重要な指標です。 これは、100Mbのしきい値と3Gネットワーク上のアプリケーションの可用性に向けた重要なステップです。 はい、アプリケーションを使用する際のメモリ削減は非常に素晴らしいボーナスです。アプリケーションを起動したとき、私はあまり違いに気付きませんでした。 まったく逆です-ユーザーが私たちのロゴを長く賞賛できるように、すでに遅延を挿入しました。 そしてその後、アプリケーションには多くのゆったりとしたアニメーションがあり、パフォーマンスの低下に気付かないため、作業速度の問題は観察されませんでした。
PS
iOS 9ではすべてが変更され 、Appleはこのデバイスに必要なコンテンツのみを提供することを知っています。 しかし、1xイメージをすべて削除しても、ビルドサイズは135になりました。同時に、非網膜デバイスのメモリと画質を犠牲にしました。これは、いくつかのインターフェイス要素で肉眼で認識できます。Pss
ここでは記憶について話しているので、別の興味深い事実を共有したいと思います。 私はいつもで画像を作成します + (UIImage *)imageNamed:(NSString *)name;
副作用を伴う迅速かつ便利な方法。 ユーザーがアプリケーションをバックグラウンドに送信すると、システムはメモリから画像をイジェクトする可能性があります（iPad miniでは、この画像はバンドルから取得されたことが確実であり、おそらくまだ適切であるため）。 アプリケーションがフォアグラウンドに戻ると、システムは必要になるとすぐにそれらをロードします。 非常に論理的で適切に聞こえます。 ただし、バックグラウンドからアプリケーションを開くときに遅延が発生する可能性があります。これは、アプリケーションのコールドスタート中にも発生しませんでした。 私の場合、それはカルーセルであり、アプリケーションがバックグラウンドから呼び出されたときにのみ遅れました。
良い週末を過ごし、そのような不快な驚きを少なくしましょう。