UberがSwiftでiOSアプリを書き直した方法

それで、友達、輪になって座って、私が参加した最大の工学災害の話を聞いてください。これは、政治、建築、および沈没コストの論理的誤りについての話です（申し訳ありませんが、私は今、Aberlour Cask Strength Single Malt Scotchを飲んでいます）。





2016年でした。トランプはまだ大統領に選出されていないため、＃DeleteUber運動 はまだ始まっていません。トラビス・カラニックはジェンダーのままでした。私たちは他の国に支店を開設することで過激な成長の段階を経験していました。世論は概して前向きで、誰もが幸せで、ユーバーは最高です。



しかし、過成長には問題がないわけではなく、アプリケーション自体が誤動作し始めました。それ以前は、開発者の数はほぼ毎年2倍になり、その速さで成長すると、信じられないほど幅広いスキルを身に付けることができます。 「ビルダーズビルド」と呼ばれるハッカーの考え方と相まって、これは複雑で壊れやすいアプリケーションアーキテクチャを意味しました。当時、Uberアプリのロジックは非常に重いため、クラッシュすることがよくありました。私たちは常にホットフィックス、パッチ、計画外のリリースなどをリリースしていました。また、アーキテクチャはうまく拡張できませんでした。



これらすべての問題の結果として、「アプリケーションを最初から書き直す」という考えを中心に結集した組織のすべてのレベルで成長する動きが始まりました。新しいアプリケーション用の新しいモバイルアーキテクチャを作成するためにチームが結成されました。アイデアは、「今後5年間でUberのモバイル開発をサポートする」アーキテクチャを作成することでした。両方のプラットフォーム用に同時に開発しました。開発サイクル全体が最初からやり直しました。



iOS部門は、この機会を利用してSwift（当時はバージョン2.x）を実装しました。 Uberは過去にSwiftを試したことがありますが、テクノロジー開発の初期段階で他の多くの人と同様に、多くの問題が発生し、実装が遅れました。



ただし、当時のSwiftの問題のほとんどは、Objective-Cとの相互運用性が低いことが原因であると一般的に感じられていました。そして、純粋なSwiftアプリケーションを作成すれば、主な問題を回避できます。



AndroidとiOSの両方で同じ基本的なアーキテクチャパターンを使用するというアイデアもありました。当時、Android開発者はRxJavaの大ファンでした。対応するRxSwiftライブラリは、Swiftの機能プログラミングパラダイムを利用しました。すべてが単純に見えた。



そのため、小規模な開発チーム（設計、製品、およびアーキテクチャ）は、数か月間、新しい機能/リアクティブパターン、新しい言語、および新しいアプリケーションに真っ向から取り組みました。すべてが順調でした。このアーキテクチャは、Swiftの高度な言語機能に大きく依存していました。



UIは多数のUberアプリに拡張でき、機能プログラミングパラダイムは強力に見え（習得は少し難しいですが）、アーキテクチャは新しいリアルタイムストリーミングネットワークプロトコルに基づいていました（この部分を作成しました）。



数ヶ月といくつかの印象的なデモの後、運動は勢いを増しました。プロジェクトは成功したように見えました。少数のエンジニアで、短時間で優れた機能を開発することができました。製品のほとんどは準備ができています。マニュアルはきれいです。



その後、全社への展開が始まりました。さまざまなチームが、新しいアプリケーションに独自の機能を追加し始めています。最初は、新しいものの興奮がモチベーションと生産性の急増を生み出しました。機能の分離を提供するアーキテクチャにより、迅速な進歩が可能になりました。



しかし、10人以上のエンジニアがSwiftを習得するとすぐに、適切に調整されたメカニズムが崩壊し始めました。 Swiftコンパイラは、現在でもObjective-Cよりも大幅に低速ですが、実際には使用できませんでした。組み立て時間はスケールから外れました。デバッグが完全に停止しました。



デモの1つからのビデオがあり、UberエンジニアがXcodeで1行の演算子を入力し、45秒待ってから文字が1つずつゆっくりとエディターに表示されます。



次に、動的リンカーで壁にぶつかります。当時、Swiftライブラリは動的にしかリンクできませんでした。残念ながら、リンカーは多項式時間で実行されたため、1つのバイナリでAppleが推奨するライブラリの最大数は6でした。92があり、その数は増え続けました...



その結果、アプリケーションアイコンをクリックしてから、mainを呼び出すまでに8〜12秒かかりました。私たちの光沢のある新しいアプリは、古い厄介なアプリよりも遅いことが判明しました。次に、バイナリのサイズの問題がありました。



残念ながら、問題が深刻に現れ始めたとき、私たちはすでに戻ってこない点を過ぎていました。これは、沈没したコストの誤りの論理的な誤りです。その時点で、会社全体がすべてのエネルギーを新しいアプリケーションに投入していました。



さまざまな方向からの何千人もの人々、数百万ドル、数百万ドル（実際の数はわかりませんが、1つ以上です）。すべての経営陣は、プロジェクトを支援する上で全会一致です。私は上司と立ち止まる必要性について個人的な会話をしました。



彼は、このプロジェクトが失敗した場合、彼は荷造りしなければならないと言った。上司から副社長まで同じことが言えました。出口はありませんでした。



そこで、私たちは袖をまくり上げて、それぞれの問題に取り組むための最高の開発者を獲得し、重要な問題（動的リンク、バイナリサイズ）に優先順位を付けました。動的リンクとバイナリのサイズの両方がこの順序で割り当てられました。



アプリケーションの起動時のリンクの問題は、すべてのコードをメインの実行可能ファイルに配置することで解決できることがすぐにわかりました。しかし、ご存知のとおり、Swiftは名前空間とフレームワークを組み合わせています。したがって、無数の名前名チェックを含む、大幅なコード変更が必要になります。



その後、優秀なリチャード・ハウエルがXcodeのビルド出力を調べ、ビルドが完了した後、カスタムスクリプトを使用して、すべての中間オブジェクトファイルを取得し、それらをメインバイナリに再リンクできることを発見しました。



Swiftはコンパイル中にオブジェクトの名前を歪めるため、Swiftを操作できることを意味します。これにより、ライブラリを効率的に静的にリンクし、mainの起動時間を10秒からほぼゼロに短縮することができました。



次の問題はサイズです。当時、セーフティネットとして、新しいアプリケーションを古いアプリケーションと一緒にパッケージ化し、実行時に慎重に展開することを計画していました。サイズを小さくするために、最初に行ったのは古いアプリをアンインストールすることでした。この戦略を「Yolo」と呼びました。トラビスは個人的にゴーサインを出しました。



また、すべてのSwift構造をクラスに置き換えました 。値タイプは通常、オブジェクトの配置と、コピー動作、自動初期化などに必要な追加のマシンコードのために、多くのオーバーヘッドをもたらします。これにより、スペースが節約されました。



しかし、アプリは成長を続けました。間もなく、iOS 8以前のバイナリのダウンロード制限（100 MB）に達しました。これは、かなりの数のインストールの損失に相当します（多くのiOSユーザーがまだ更新されていないため、1,000万ドル以上の収益が失われています）。



この時点で、一般公開までに数週間かかりました。 Objective-Cに戻るか、iOS 8のサポートを終了する必要がありました。iOS9ではアーキテクチャを分割する機能が導入されたため、このバージョンは実際には半分のサイズ（ギブまたはテイク）でした。残り1週間で、数千万ドルを捨て、iOS 8



のサポートをやめる ことにしました。サイズが半分になると、操作の余地が大きくなり、サイズの問題は将来解決できると一般的に考えられていました。残りをかき集めるとき。残念ながら、私たちは非常に間違っていました。



アプリのリリース後、私たちは大規模なパーティーを開きました。このアプリは、ユーザーやマスコミから好評を博しました。明るく新しいデザインで、高速でした。



多くの人が昇進しました。私たちは皆、安堵のため息をついた。 90週間の連続作業の後、彼らはついに休憩を取りました。



しかし、その後、世論は変化し始めました。新しいアプリは、特定のルートの旅行の正確な価格を計算することに焦点を当てていました（昔は、運賃と現在の乗数を見ただけでした）。価格を計算するには、現在地を入力する必要がありました。



ユーザーの便宜のために、自動位置決定もインストールされており、バックグラウンドで位置データを収集できるため、ドライバーは現時点で乗客を迎えに行く場所を正確に確認できます。人々は夢中になり始めました。 Twitterの以前の同僚の何人かは、このような人々を追跡している邪悪な会社を辞めるように私に促しました。



この不安の結果として、人々はiOSで位置情報の許可を無効にし始めました。しかし、新しいアプリケーションはこのユースケースを提供しませんでした。



そこで、標準バージョンを返すように最善を尽くしました。バックグラウンドの位置追跡をオフにすることは可能ですが、タクシーに乗る前に再び使いやすさが損なわれることを説明しました。



その後、トランプが権力を握り（これは新しいアプリのリリースから約3か月後に発生しました）、それが連鎖反応を引き起こし、＃DeleteUberの動きにつながりました 。



この間ずっと、Swiftコードベースは急速に成長しました。進行中の問題と遅いIDEにより、iOS開発者の間で2つの対立する派閥が生まれました。私はそれらをSwift狂信者とObjective-Cオタクと呼びます。



外圧と内圧の合計が張力を最大にしました。狂信者はスウィフトの問題を否定した。退屈な人たちは、特別な解決策を提供することなく、考えられるすべてのことについて不平を言っています。



この頃、バイナリのサイズに問題が発生しました。チームがリリースで問題を抱えていたとき、私は電話に出ていました。動的リンクの問題に対する優れたソリューションにより、一部のアーキテクチャには大きすぎる実行可能ファイルが作成されたことが判明しました。



これらのアーキテクチャの問題を解決したので、同僚の @aqua_geekと私は少し掘り下げてみると、コンパイルされたコードのサイズが1週間あたり1.3MBの割合で増加していることがわかりました。私は警報を発した。何もしなければ、そのような速度で、3週間以内にセルラーネットワークを介したダウンロード制限に遭遇します。



しかし、内部の緊張は狂信者がすべてを否定するような段階に達しました。 Swiftキャンプの技術リーダーの1人が、携帯電話のダウンロード制限がどのように問題にならないかについて2ページの記事を書きました（結局のところ、Facebookはずっと前にそれを超えていました）。私たち自身は火を消すのにうんざりしています。



そこで、データサイエンティストの1人が、建築レイヤーの1つを人為的に制限外に移動するテストを開発し、ビジネスパフォーマンスへの影響を測定しました。翌週、このレイヤーを元に戻し、別のレイヤーを制限から外しました（アーキテクチャを制御するため）。



その影響は悲惨だった。ビジネスへの悪影響は、毎年のSwift実装のすべてのコストよりも数桁大きいことが判明しました。 Uberアプリを初めてダウンロードしたとき、多くの人がWiFiの範囲外にいることがわかりました（誰が考えたでしょうか？）



そこで、別のストライキグループを結成しました。オブジェクトファイルの逆コンパイルを開始し、1行ずつ調べて、Swiftコードが非常に大きくなった理由を特定しました。未使用の機能を削除しました。タイラーはwatchOSアプリをobjcに書き直す必要がありました。



（ウォッチアプリの長さはわずか4400行でしたが、プロセッサアーキテクチャが異なり、ABIとの互換性がないため、Swiftランタイム全体をアプリに含める必要がありました。）



私たちは限界に達した。すごく疲れた。しかし、彼らは集まった。その時、本当に優秀なエンジニアが現れました。アムステルダムの開発者の1人は、コンパイラ最適化パスを再配置する方法を考え出しました。コンパイラの専門家でない方のために説明します。



最新のコンパイラは大量のパスを作成します。たとえば、関数をインライン化できます。もう1つは、定数式をそれらの値に置き換えることです。実行の順序に応じて、マシンコードは小さくなったり大きくなったりする場合があります。



インライン関数が値を渡すと、コンパイラはこれを認識してブロック全体を置き換えることができます。例えば：

int x = 3
func(x) {
X + 4
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

コンパイラが最初にインライン関数を通過する場合は、定数7になります（つまり、コードが大幅に少なくなります）。



このコンパイラパスが2番目の場合、そのような関数を認識しない可能性があり、より多くのコードを取得できます。もちろん、これはすべて特定のコードの外観に完全に依存するため、一般にパスの順序を最適化することは困難です。



そのため、リリースビルドにアルゴリズムを組み込んで最適化パスを並べ替え、サイズを最小化したアムステルダムの優秀なエンジニアは言いました。これにより、マシンコードの合計サイズがなんと11MB削減され、開発を続けるための時間が少し与えられました。



しかし、このアプローチはSwiftコンパイラの専門家を怖がらせ、検証されていないコンパイラパスがテストされていないバグを明らかにすることを恐れていました（各パスは本質的に安全であるはずですが、パスの可能な組み合わせについて推論することは困難です）。しかし、大きな問題は発生していません。



また、他の多くのソリューションを適用しました（特に高価なコードテンプレートに対応しています）。それぞれの開発週数を測定しました。しかし、本当の問題は成長曲線でした。結局、すべての賞金は常に食べ尽くされました。



結局、Appleの動きを待つのに十分な時間があり、セルラー通信のダウンロード制限が150MBに引き上げられました。また、サイズの最適化（-Osize）に役立つ多数のコンパイラ関数も追加しました。彼ら自身の承認により、Swiftはコンパイル後にObjective-Cほど小さくなることはありません。



しかし、今年の時点で、SwiftをObjective-Cマシンコードの1.5倍のサイズに最適化し、最終的にAppleはオプションの制限を再び200MBに引き上げました。それは私たちをさらに数年間続けるのに十分です。



しかし、私たちはほとんど失敗しました。 Appleが制限を引き上げていなかったとしたら、UberアプリをObjCに書き直す必要がありました。結局、他の問題も解決することができました。シャイニー @alanzeino彼のチームは、SwiftサポートをBuckビルドツールに含めることを可能にしました。これにより、ビルド時間が大幅に短縮されました。



途中で燃え尽きた人をたくさん失いました。たくさんのお金を使い、難しい教訓を学びました。驚いたことに、今日まで、ほとんどの人は書き直しはそれだけの価値があると主張しています。アーキテクチャの一貫性は、会社に来る新しいエンジニアに人気があります。彼らはそれを達成するのにどれだけの苦痛がかかったかさえ知りません。



コミュニティは私たちの知識から恩恵を受けています。 @ ellsk1は素晴らしいプレゼンテーションをまとめ、彼の知識を共有するためにレクチャーツアーに参加しました。私もこの経験を活用して、新しい企業や開発チームがより良い決定を下せるように支援することができました。



だからここにヒントがあります。プログラミングのすべては妥協についてです。普遍的に優れた言語はありません。何をするにしても、妥協点とは何か、なぜそれを作っているのかを理解してください。社内の頑固な派閥間の政治的戦争を避けてください。



失敗のポイントで努力してください。トレードオフを特定し、ポイントに到達して間違いに気付いた場合に撤退を残す方法を理解します。多くの努力にはコストがかかりますが、後で間違った妥協に気付くほど、コストは高くなります。



不平を言うだけで貢献しない退屈にならないでください。誰にとっても大きな問題を引き起こす狂信者にならないでください。最高のエンジニアは、これらの罠にはまりません。