TamTam：新しいメッセンジャーのやり方

こんにちは、Habr！ 私の名前はYuri Buyanovです。私はTamTamメッセンジャーの開発者です。 今日は、それがどのように作成され、どのように内部から構築されるかについて少しお話ししたいと思います。 TamTamは、OKメッセージアプリケーションに基づいて開発されたMail.Ru Groupの新しいメッセンジャーです。 2016年には、ソーシャルネットワークで頻繁にやり取りする人や、別のアプリケーションを使用してこれを行うことを好む人のために、Odnoklassnikiで別のメッセンジャーを作成しました。

実験は成功したことが判明したため、今年の初めに、私たちは独自のTamTamブランドの下でソーシャルネットワークとは別のメッセンジャーとしてOKメッセージを開発することにしましたが、開始オーディエンスを募集しました。 ローンチ後の最初の数週間で、数万のチャンネルがTamTamに登場し、オーディエンスはOKメッセージのように積極的にコミュニケーションを続けました。 これは、アプリケーションの迅速な作業といくつかの技術的機能のおかげで可能になりました。 それらについて詳しく説明します。

アイデアを思いついた困難

困難から始めましょう。製品に後で実装され、最終的にアプリケーションの利点になったアイデアを私たちにもたらしたのは彼らでした。 それは主にメッセンジャーの高速で安定した仕事についてです。

TamTamの最初の視聴者は、モバイルネットワークの不規則なカバレッジ（および固定インターネットの完全な欠如を含む）を含む世界中からです。 大都市以外の一部のCIS諸国では、一般に2G接続が唯一のインターネットウィンドウです。

また、すべての潜在的なTamTamユーザーが、毎年サムスンから新しいiPhoneまたはHOT NOVELを購入するわけではないことも重要でした。 統計によると、ユーザーの間で最も人気のあるiOS用デバイスはiPhone 5sであり、Android用の安価なGalaxy 2014-2015リリースです。 同時に、TamTamの視聴者はかなり若いです。毎日の視聴者の28％は27〜34歳であり、ユーザーの半分（54％）は35歳未満です。

したがって、最初からメッセンジャーの開発における優先分野の1つは、 速度とネットワークの操作の両方の観点からアプリケーションを最適化することでした。 つまり、ユーザーがアプリケーションを任意の接続レベルで動作させることは感知できませんでした。 視聴者の増加も伴います。 TamTamの最初の数か月は良い数字を示しています。インストール数はすでに300万に近づいており、チャネル数はすでに50,000を超えています。

アプリケーションを高速化した方法

ユーザーの観点から見たパフォーマンスは、主に起動の速度です。 新しいコンテンツが表示される前に経過する時間（たとえば、プッシュ通知によって新しいメッセージでチャットを開くとき）。 作品全体の滑らかさ-特にスクロール。 iOSチームでは、iPhone 5およびiPhone 4Sのパフォーマンスをテストおよび測定しようとしています。 Androidチームは、1000ルーブルのGalaxy S3およびMegafonログインを自由に使用できます。 その結果、アプリケーションはより強力なデバイスで飛ぶだけです。

各テストアセンブリで、1秒あたりのフレームカウンターを有効にできます。また、ボトルネックでの操作の期間はログと統計システムに記録されます。

たとえば、このグラフは、プッシュで開くときのアプリケーションの起動から、ユーザーがこの特定のメッセージを画面に表示するまでの時間を示しています。 グラフ上の2つのドロップは、半分およびすべてのユーザーがプッシュするコンテンツを含めることに対応しています。

豊富なツールとメトリックにもかかわらず、主観的な感情はアプリケーションのパフォーマンスを評価するための主要なツールのままです。 メッセージ画面を開くときに許容されるミリ秒単位の遅延を正確に言うことはできませんが、ほとんどの人は、アプリケーションが「バカ」だと感じているかどうかを知ることができます。

どのように最適化するのですか？ まず、メインストリームから可能なすべてのものを削除します：データベースの操作（以下で詳しく説明します）、ネットワークの操作、データのシリアル化と逆シリアル化、画像の処理、および植字に関連する計算です。

アプリケーションを起動するとき、またはチャット画面を開くとき、バックグラウンドで重い操作を実行しても、目に見える遅延から私たちを救いません。 したがって、組版などの一部の操作は時間内に最適化する必要がありますが、他の操作はメッセージを受信して​​すぐに実行し、実行結果をデータベースにキャッシュするのが最適です。

ボトルネックのあるサードパーティのソリューションとライブラリを選択するとき、スピードとコンパクトさも考慮に入れようとしました。 特に、それがMessagePackを選択した理由であり（iOSでは具体的に異なる実装のベンチマークを作成しました）、データをオブジェクトにマッピングするライブラリをMantleからYYModelに変更し、トラフィックを圧縮するアルゴリズムとしてlz4で停止しました 。

さらに、 スムーズなインターフェイスを実現するために、レンダリングを症候的に最適化します。

• プロセッサをロードするオフスクリーンレンダリングを避けます。
• メインストリームで動作する標準のUIViewContentModeを使用する代わりに、バックグラウンドで事前に画像のサイズを変更します。
• UI階層をより「フラット」かつシンプルにします。
• 作成コストが高すぎるオブジェクトとデータをキャッシュします。 テキストを含むセルの高さから始まり、YYTextLayout（ YYTextライブラリ内のテキストの表示に関する情報を格納するオブジェクト）、NSAttributedStrings、さらにはUIView自体で終わる。

すべてのリストには、自動レイアウトのない手動レイアウトがあります。 自動レイアウトも大好きで、コードでMasonryを使用した宣言型レイアウトを使用していますが、適切な場合にのみ使用します。

オフラインで悪いインターネットで作業する

ネットワークを使用する場合、高速でコンパクトなプロトコルとアグレッシブなキャッシュを選択することにより、トラフィックと遅延を最小限に抑えようとします。

サーバーと通信する方法として、TCPソケットとバイナリプロトコルのみを使用します。 これにより、サーバーから更新をリアルタイムで受信することと、より使い慣れた「要求/応答」モードで作業することができます。

API自体、つまり低レベルプロトコルの上にある一連のコマンドは、将来、別のトランスポートの上、たとえばWebソケットに実装できます。 これらすべてにより、アプリケーションの上位レベルのロジックに触れる必要はありません。

パッケージ自体は、サービスコード（コマンドコード、プロトコルバージョン、ペイロード長）を含む固定長ヘッダーで構成されています。 要求への応答は異なる順序で送られ、サーバーコマンドと混合される可能性があるため、ヘッダーに要求と応答をリンクできるシーケンス番号があります。

ペイロードの形式として、メッセージパックを試すことにしました。 回路の難しいタスクを必要とせず、非常にコンパクトで、多くのプラットフォーム用の非常に気の利いたシリアル化ライブラリを備えています。 実際、これはJSONの効果的なバイナリアナログです。 トラフィックの消費をさらに削減するために、lz4アルゴリズムでペイロードを圧縮します。 また、その速度とCPUおよびバッテリーの軽負荷のために選択しました。

不良ネットワークでのアプリケーションの正常な動作を保証する主な方法の1つは、 オフラインサポートを最大化することです。 アプリケーションは最大データをキャッシュし、同期に費やす時間とトラフィックを減らし、接続が表示されるまでコマンドの送信を遅らせることができる必要があります。 さらに、次にアプリケーションを起動したときにも接続が返される場合があります。つまり、送信中のすべての保留中のタスクはデータベースに保存できるはずです。

接続後、クライアントは認証を行うと同時に、重要なデータ（設定、連絡先のリスト、最新のメッセージとのチャット）を要求します。 最後の更新のタイムスタンプを（サーバーの時間枠に）保存し、それをリクエストに渡し、実際に変更されたもののみを取得します。 接続が確立されると、新しいメッセージや連絡先データの変更など、リアルタイムの更新を受信できます。

チャット履歴はもう少し複雑です。 すべてのチャットの履歴全体を事前にアップロードするのは無意味ですが、一度得たのはキャッシュして、もう聞かないようにすることです。 チャット履歴のどのセクションがキャッシュされているかを見ると、履歴に「ギャップ」があることがわかります。 たとえば、ログイン後にチャットリストを更新すると、チャットの最後のメッセージが変更されたことがわかりました。 同時に、前のセッションでキャッシュされたチャット履歴のセクション（またはいくつかのセクション）がデータベースにあります。 さらに、最後のチャットメッセージと以前にキャッシュされたメッセージの間にサーバー上にあるメッセージの数がわからないため、複雑さが増します。

したがって、メッセージ自体に加えて、連続した履歴に関するメタデータ（キャッシュしたチャンク）を保存します。 チャットをスクロールするとき、この情報を使用します。データベースから次のページをロードするか、サーバーにリクエストを送信するかを決定するのに役立ちます。 または多分両方を行います。 サーバーから履歴の新しいセクションを受信すると、これらのチャンクはサイズを変更して互いにマージします（受信した履歴のセクションがデータベースで使用可能な2つの異なるチャンクを接続していることをクライアントが理解している場合）。

多くの操作をオフラインで実行できるため、タスクを保存するメカニズムを開発しました。 彼は、タスクを実行する方法、タスクの完了を待つ方法、データベースにステータスを保存する方法、またはアプリケーションの起動時にロードして実行する方法を知っています。

タスクはデータベースに保存でき、実行ロジック全体をカプセル化します。 他のタスクやアプリケーションの状態への依存関係は非常に複雑になる可能性があるため、それらの追跡もタスク自体に実装されます。 たとえば、写真付きのメッセージを送信するタスクは、写真が処理され、CDNにアップロードされていることを確認し（このため、個別のタスクが責任を負います）、ネットワーク接続を待機し（必要な場合）、メッセージのみを直接送信しようとします。

スムーズなアプリケーション操作のための2つのトリック

使いやすくスムーズなインターフェイスを作成できないシステムの制限を回避するために使用したいくつかのトリックについて少しお話します。 iOSアプリケーションの例。

開発の難しさの1つは、チャット内での無限スクロール、つまり、チャットを上にスクロールするときにユーザーに表示されないメッセージ履歴をロードすることでした。 99％の場合、ユーザーはチャットの最下部に位置しており、古いメッセージを読むためにスクロールアップしたいと考えています。 ここで、2つの問題に直面しています。

まず、メッセージリストの一番上に常にぶつかり、数画面ごとにダウンロードを待つのは面倒です。 この問題を解決するのはそれほど難しくありませんでした。ユーザーが一番上までスクロールして「ねじれ」が見えるまで待たなかったのですが、スクロール中であっても事前にストーリーの前のページをリクエストしようとしました：ローカルキャッシュとサーバーの両方から。 キャッシュまたはクイック接続にメッセージがある場合、ユーザーは新しいメッセージパックを表示できるまでに最上部までスクロールする時間がありません。

2番目の問題はより深刻であることが判明しました。メッセージリストの先頭にそのようなページを挿入した後（UITableViewに基づいて作成）、既にロードされたセクションのcontentOffsetがシフトし、スクロールが「ジャンプ」します。 もちろん、挿入されたページのサイズを計算してcontentOffsetを元に戻すこともできますが、これはスクロールアニメーションの急激な停止につながり、ユーザーにとってtheくて思いがけないものになります。 たとえば、KVOを介してcontentSizeテーブルを追跡するなど、さまざまな方法でこれを実行しようとしましたが、常に失敗しました。UITableViewは、リストの最上部に項目を追加できないだけです。

その結果、一連の試行の後、一種の「ハック」を適用することでこの問題を解決することができました。.transformを使用してリストを上下逆にし、各セルを反対方向に回転します。 ユーザーは何も気づきませんが、contentOffsetは下からカウントされるようになり、古いメッセージを読み込んでも何の影響もありません。

このソリューションにはいくつかの落とし穴がありますが、それらを回避することもできました。 まず、逆セルインデックスをデータモデルのインデックスに変換する必要があります。逆も同様です。 セクションが複数ある場合、計算は非常に複雑になるため、1つに制限することをお勧めします。 もちろん、これによりフローティングセクションヘッダーを使用することはできません。これは、チャット画面で、たとえば履歴の日付ごとに区切り文字を表示するのに役立ちます。 しかし、最終的にフローティングセパレーターを手動で行うのはそれほど難しくないことが判明しました。

第二に、まれに、ジェスチャを操作するときなど、セル内の座標を計算するのが難しい場合がありますが、すべてを解決することもできます。 第三に、データをロードするときに問題が戻りますが、スクロールダウンするときにロードすることは非常にまれであるため、私たちにとってそれほど大きな問題ではありません。 この場合、スクロール中にプリロードは行いませんが、ユーザーがテーブルの一番下までスクロールしてからロードインジケーターを表示し、テーブルを更新してcontentOffsetを変更するのを待ちます。

2つ目の問題は、アニメーション化された非同期のリスト更新です。 複数の独立した更新がほぼ同時に発生する場合（たとえば、履歴ページがチャットの上部にロードされ、新しいメッセージが下部に到着する場合）、tableViewデリゲートによって使用されるデータは、前の更新のアニメーションが終了していなくても変更できます。

これにより、UITableViewが間違ったセルをレンダリングしたり、完全にクラッシュしたりする可能性があります。これは、以前のハックを使用した場合に発生する可能性がさらに高くなります。 もちろん、UITableViewで同期するreloadDataメソッドを参照することもできますが、これは点滅、スクロールの停止、その他のユーザーの迷惑につながります。

特にそのような場合には、そのような更新の順次処理のために別のキューを作成しました。 すべてのモデル変更とUIでのマッピングは、キューに入れられたブロック内で行われます。 この場合、ブロックはアニメーションまたはその他の非同期操作の開始時にキューをロックし、終了時にロックを解除できます。 したがって、テーブルに対するすべての作業は順番に行われ、データは前のアニメーションが完了するまで変更されません。

持続性

iOSクライアントでデータをキャッシュするには、YapDatabaseライブラリを使用します 。

YapDatabaseは、非常に多くの機能セットを備えたSQLite上のKey-Valueリポジトリです。 このライブラリは、CoreDataよりもはるかにシンプルで柔軟性があります。 ここでは、データベース内のオブジェクトをシリアル化するメカニズムを選択できます。デフォルトではNSCodingであり、同じMessagePackを使用します。

YapDatabaseは、基本クラスからのオブジェクトの継承やプロトコルの実装を必要とせず、オブジェクトをコンテキストにバインドしません。 読み取りおよび書き込みは、同期トランザクションまたは非同期トランザクションを使用して実行されます。

また、拡張システムの助けを借りて、「実際の」データベースと同じすべての機能を使用できます。任意のSQLクエリといくつかのフィールドのインデックス作成、フルテキスト検索、変更へのサブスクリプション（NSFetchedResultsControllerなど）、プラグイン暗号化、CloudKitでの作業などHello-worldここでデータベースを操作する例は示しません。それらはgithubのwikiにあります 。

私の好みでは、YapDatabaseはコードの生産性とわかりやすさを向上させますが、私の同僚の何人かはそれをあまり好きではありません。 そして、それらを理解することができます。CoreDataを長時間使用した後、YapDatabaseに切り替えるには、脳を少し回転させる必要があります。

さらに、複数の接続を介してデータベースを非同期で操作する場合、データベースが1つまたは異なる接続を介して並列読み取りおよび書き込み要求を処理する方法を理解する必要があります。 また、オブジェクトはデータベース全体で更新されることも忘れないでください。 少し前に読んで変更したインスタンスを保存することはできません。 データベースからオブジェクトを読み取り、必要に応じて変更し、単一のトランザクションで書き戻す必要があります。 そうしないと、誤って古いデータをデータベースに書き込む可能性があります。

一般に、データベースの操作は、コードを記述するリアクティブスタイルに非常に便利に統合されています。 非同期トランザクションテンプレート（個々のオブジェクトの読み取り/書き込み/変更）は、たとえばReactiveCocoaシグナルでラップするのが非常に簡単で、ネットワーク要求を送信および処理する1つのチェーンでデータベースと作業を統合します。

アプリケーションアーキテクチャ

アーキテクチャについてはあまり触れませんが、そのジャンルの法則については触れません。 MVVMに関する多くのレポートと記事が既にあります（たとえば、Objective-C b RACのバージョンの古典的なチュートリアル： パート1 、 パート2 、またはSwiftのこのパターンの実装に関する記事 ）。

ViewModelsレイヤーの下には、ビジネスロジック、プロトコルロジック、およびキャッシングを実装する（および可能であればカプセル化する）サービスのセットがあります。 アプリケーション内のナビゲーションは、いわゆるルーター、つまり画面を開くために必要なコードをカプセル化するオブジェクトを使用して実行されます。 実際、ルーターは非常に太ったゴッドオブジェクトになる傾向があるため、プロセスには複数のルーターがありました。 したがって、可能な限り、それを分解しようとします。 たとえば、個別のルーターがユーザー登録/認証プロセス全体を担当します。

以前のプロジェクトの経験から、依存性注入はアプリケーションの構造を大幅に簡素化し、アーキテクチャの変更を大幅に促進することがわかっています。 最初はDIにTyphoonフレームワークを使用しましたが、アプリケーションの起動時間の最適化中に、依存関係の解決にはアプリケーションの起動に許容できないほど長い時間がかかることがわかりました（弱いデバイスでは数秒単位）。 したがって、プロパティベースの注入を介して手動DIに切り替えました。 これ以上のコードがあるとは言いません。アプリケーションのサービスのレベルは通常1つのクラスで構成され、サービスの構成全体が読みやすいです。 もちろん、共有拡張機能とimessage拡張機能の場合、サービスは個別に設定されます。この場合、必要なサービスははるかに少ないためです。

したがって、コードの一貫性は当初それほど大きくなく、開発の開始からかなり長い時間が経過した後でも、メッセンジャーの内部ロジックのほとんどを実装する別のライブラリ（より正確には、ライブラリのセット）に一部のサービスとサービスコードを簡単に転送できました。プロトコルの処理とキャッシュを含み、他のアプリケーションに組み込むことができます。

おわりに

アプリケーションのパフォーマンスまたはオフラインでの作業-私たちにとって、これはトレンドになりたいという願望ではなく、特定のユーザーにコミュニケーションをとるための便利な機会を提供する実際の方法です。 高価なモバイルトラフィックまたは単に悪いインターネットを持っている人。 そして、これはうまくいくためのかなり深刻な動機です。 結果として、評価するのはユーザー次第です。メッセンジャーをインストールし、コメントでフィードバックを共有することをお勧めします。 私は質問に答えてうれしいです。