6/24/2017

iOSアプリのサイズを減らすこと

Halideのブログより。iOSアプリのサイズを減らすことよりも、プライバシーに配慮した開発が気に入った(アプリの品質を高めるという名の下、プライバシーデータが如何に勝手に送信されていることか)。

人気のソーシャルネットワーク・アプリ(SNSアプリ)は400MBを超えている。毎週リリースされると、1年であなたは20GBのデータをダウンロードする事になるだろう。

Halideをローンチして以来、我々が聞いた最も予期しなかった褒め言葉はサイズに関するものだった。11MBで1年分のデータは、1度のSNSアプリのアップデートよりも少ない。

「あなたはSwiftを使っていないよね」友人に尋ねた。やはり、Swiftは標準ライブラリをアプリの中にバンドルして、そのサイズを膨らませる。しかし、Halideはほとんど全体がSwiftである。

我々はどのようにしているか? 技術的な部分から始めてみよう。このほとんどはQA1795の見直しになるが、重要である。

測定し、推測しない

Xcodeからビルドをエクスポートする。その時、"Save for Ad Hoc deployment"を選択する。アプリがApp Thinnngをサポートする(この時点ですべきである)と仮定すれば、"Export for Specific Devices"を選択する。"Rebuild from bitcode"がチェックされているか確認する。

パッケージサイズの最終表示を得るだけでなく、App Thinningのレポートも取得する。最大の犯人を見付けるためにアプリパッケージを調査する。

アセットカタログの利用

アセットカタログの中のアセットを保管する。アプリをアップロードする時、Appleはデバイス固有のバージョンの中にスライスするので、2倍の画面を持つデバイスは3倍のセットを取得しない。その逆も。

PNGクラッシュを実行

カタログの中にアセットを置く前に、pngcrushを実行する。QA1681によれば、Xcodeは自動的にアセットカタログ外のPNGのアセットを圧縮する。

写真にJPEGを試す

UIアセットや同様の細かな線画をPNGに制限する。これはおそらくアプリのアセットの大部分を占めているが、写真がある場合はJPEGを試みる。少しの圧縮でも効果がある。

難しい話し合いをしている場合ではない

やはり努力を重ねても、数百メガバイトの巨大な巨獣を数メガバイト削るだけだ。私はあなたにこれを伝える方法は分からないが、コードは少なくする必要がある。

正しい戦いを選別する

Halideは約15000行のSwiftで構成される。これにはリアルタイム・ビデオ・プロセッサ、大量のカスタム制御、AVFoundationを制御するプラットフォームを含んでいる。興味深い事に私が書いていないコードである。

私はAuto Layoutを活用する事で何千行もの雛形を削った。多くの開発者は依然として手動レイアウトを強く主張している。彼らはAuto Layoutを理解していないのかも知れない、あるいはAuto Layoutがどんなに襲いかを友人の友人から話を聞いたのかも知れない。(そうではない)

私は社内のレイアウト・エンジンを作る多くの開発者を特に大企業で見てきた。それは単なるナッツだ。AppleがOSに精巧なレイアウト・エンジンをバンドルしているのに、アプリケーションを特注のフレームワークで膨らませる必要はない。

我々はInterface Builderを削除する事で、更に100kを減らすことができた。ユーザマニュアルと設定は、ほぼ完全にIBであり、制約がある。Camera UIのハイレベルな配置は同様に管理される。しかし、生産性は短期的にはサイズに価値があると判断した。

ライブラリ・ブロートを避ける

多くの大規模なアプリケーションのパッケージを調査すると、100kから数メガバイトある数十のサードパーティ製フレームワークをどこかに発見するだろう。

私はサードパーティ製ライブラリは使わない。少し極端だが、我々は少し独特の状況にある。

我々が必要とするサードパーティ製ライブラリが単に無いだけだ。iOSの開発コミュニティには多数のJSONマッパーがあるが、DNGファイルの低レベルの操作は何もできない。

しかし、先ほど触れたビデオ処理はどうだろうか? 私はあなたの叫びが聞こえる。「GPUImageは拡張可能だ! 自分自身でできる事に夢中だ!」

Periscopeのスタックでの私の経験から、GPUImageから社内ソリューションへの移行で大きな進歩が見られた。リアルタイム画像処理が重要でないなら、GPUImageは素晴らしい。しかし、Halideの長期ビジョンとリアルタイムなレンダリングの役割を考えると、このコンポーネントを自身で所有することは重要である。

私はファイルサイズが理由でGPUImageを見送ったわけではない。しかし、自作した結果、アプリに125の使わないフィルタをバンドルするのを回避できた。

PSPDFKitはやり過ぎの大きなフレームワークを置き換えて同じように成功した。

我々はiOS向けのPSPDFKit 6.8では検出、検証、より良いエラー報告に改善するため、デジタル署名の実装のコア部分を書き直したことをあなたに伝えられる事に興奮している。その結果、OpenSSLへの依存度を完全に下げ、プロセスのバイナリサイズを縮小した。

NIH症候群に感染してはいけないが、ライブラリを避けるには正当な理由がある。

分析やA/Bテストのリソースは無駄

サードパーティ製の分析やクラッシュレポートサービスを使っていない。まず第一に、ユーザデータを広告会社に送信するのは心地よく無い。しかし、暫くは理想を脇に置こう。

データは無料では無い。大きなアプリでは、全てのアクションを分析イベントに記録する。大きなアプリには、ユーザを一意に識別する機能、リクエストの重複排除、ログのバッファ、障害時のリトライなどのロギング・インフラが必要である。それで辻褄が合う。

A/Bテストは更に悪化させる。典型的なソーシャルネットワーク・アプリは誰もクリーンアップに戻らないA/Bテストの死骸で一杯である。

我々はコードが肥大化するため、分析やA/Bテストを意図的に避けたわけではない。それは単に製品への我々の哲学である。あまりにも多くのデータを知ることは、顧客の気持ちを歪める。実際に目立った変化をもたらす大きな賭けをするのではなく、極大に向け自身の最適を見付ける事だ。

そのため、我々はAppleの分析機能を使用している。コードを変更せずに動作する。無料で、オプトインを要求し、ユーザのプライバシを尊重する。我々のオプトイン率は32%で、我々のニーズに丁度合っている。

分析には時間と場所が必要である。最適な価格ポイントについて分からないので、試してみるしかない。しかし、我々のビジネス主導の分析と製品開発の間の壁を守っている。

ゴールを調整する必要

我々は二人のチームである。我々は製品を売ることでお金を稼いでいる。我々の成長は完全に有機的である。ユーザが幸せになれば、友人に我々について伝えてくれる。小さなアプリは我々を幸せにし、ユーザを幸せにすると思う。

我々のアドバイスは膨らんだアプリには役立たない。ソーシャルネットワークは広告主から収益を得ており、広告主は広告ターゲティングの詳細な分析を必要としている。

大きなアプリは何百人もの開発者がいて、それぞれが独立した四半期目標を持つ数十のチームを構成している。速く走るほど、目標や昇格は大きくなる。

考えるのも無理はない。「このライブラリで一週間稼げるが、アプリは1メガ増える。既に数百メガバイトなので、やらない理由はあるのか?」

大規模な組織は意図しない結果を伴う中庸なアイデアで一杯である。

エンジニアがハイテクのはしごを昇りたがっているとする。配送機能ではあなたは昇進できない。そこで、新しいレイアウト・エンジンを構築する事にする。会社はエンジニアリング・ブログにリクルート用の餌で更に釣ろうとする。

唯一の解決策は、「我々はアプリのスリム化を進める」と宣言する経験豊富なリーダーシップである。残念な事に、ハイテク業界のCEOは8GBストレージのiPhoneを使用していないし、通信速度が遅い場所に住んでいない。

これは報われない努力ではない。Halideを出荷してから、我々は世界各地の人々から小さく保つ努力に感謝するというたくさんのメッセージを受け取った。

サイズを小さくする素晴らしい技術は本当にある: それは顧客に焦点を当てる事だ。

Darling FireballHacker News