スレッド、またはメール内の文字のチェーンは、オタクや大勢の観客が極地の見方をしている機能の1つです。 オタクは積極的にそれらを使用します。 私たちの世論調査が示すように、普通のユーザーはかなり慎重です。 第一に、珍しく、第二に、人々はチェーンをナビゲートできないことを恐れます。 Mail.Ru MailのWebバージョンにスレッドを実装したとき、この課題を思い出しました-そして、私たちのように、オタクと上級ユーザーの両方に便利な、最も便利で直感的なグループ化アルゴリズムを見つけました。 モバイルスレッドの研究の基礎として、Big Mailが開発したシステムを採用しました。ユーザーを混乱させたり、別のロジックを実行したりする必要がないためです。 製品の観点からのタスクは、Webスレッドとモバイルスレッドの両方がユーザーに対して同じように機能することを保証することでした。 しかし、オフライン作業を考慮して多くのことをやり直す必要がありました。 ネットワーク障害が発生してもメールが失われないAndroidのMail.Ru Mailアプリケーションでどのように会話をしたかについて説明します（iOSアプリケーションで次のいずれかを行う方法で）投稿）。







モバイルアプリケーションでは、安定した中断のないオフライン作業に特に重点を置きました。 私たちの目標は、ユーザーがメッセージをオフラインで編集し、それらを移動し、タグを付け、メールを操作し、スレッド全体でアクションを実行できるようにすることでした-そして、ネットワークが表示されると、これらすべてのアクションに関する情報がサーバーに正しく送信されます。



メールアプリケーションにスレッドを実装するための最も一般的なオプションは、クライアント自体で文字をグループ化することです。文字はポンプで取り出され、チェーンで収集されます。 このオプションは、複雑なケースを除き、ほとんどの標準的な状況をカバーします。たとえば、オフラインで作業するときのスレッド内の文字の正しいグループ化などです。 ただし、すべてのユーザーに適切に機能することが保証されるソリューションが必要でした。 オフライン作業を犠牲にしたくありませんでした。製品の品質が明らかになるのは難しい状況だからです。 さらに、ユーザビリティテストを実施したとき、人々はスレッドを使用するのが便利でクールであることに気付きましたが、同時に、チェーンが直感的にグループ化された場合、メールボックスで文字が見つからなくなることを恐れていました。 そのため、アプリケーションのオフライン作業に特別な注意を払いました。すべての変更が個別に保存され、必要に応じて静かに同期されるようにする必要がありました。 ユーザーにとっては、これは次のようになります。変更を行うと、アプリケーション自体が、これをサーバーに送信する方法とタイミングを理解します。

同期の技術面

したがって、私たちが決定したアプローチで、実装を開始することができました。 チェーンで文字をグループ化するロジックは、大きなWebバージョンのMail用に開発されました。 そのため、車輪を再発明する必要はありませんでした。Androidアプリケーションでは、同じアルゴリズムを実装しただけです。 Habrには、どのように開発され、他のメールサービスが使用するアルゴリズムとどのように異なるかについての詳細な投稿がありますので、今日の記事では詳しく説明しません。



したがって、ロジックのフレームワーク内で文字を使用したすべての操作が正しく実行されることを確認することが重要でした。 たとえば、メッセージを移動または削除する場合、Webおよびアプリケーションのすべてのカウンターはスレッド内の正しい（更新された）文字数を表示し、すべてのフラグ「読み取り」、「未読み取り」を更新および同期し、特定のスレッドは一部のフォルダーで表示を停止する必要があります等。正しい同期に加えて、レターの操作が迅速に完了するようにすることが重要でした。 異なるスレッドとフォルダーにある200文字の配列で速度をテストしました。 最初のバージョンでは、20秒かかりました。この間、ユーザーは待つ必要がありました。 当然、これは許可できませんでした。



この遅さの理由を探し始めました。 最初は、文字の数に依存しているため、SQL操作が最も時間がかかると想定しました。それぞれの操作中に、スレッド、カウンター、フォルダー、文字自体などを更新する必要がありました。 ただし、実際には、ボトルネックは過度に複雑なインデックスのコピーであり、それによってメモリからデータを選択しました。 これらの20秒から70-80％の時間がかかりました。 これらのインデックスのコピーを削除し、各操作のインデックスを再構築し、トランザクションの最後に操作が完了した後にバッファリングと更新を行いました。 その結果、20秒ではなく、インデックスの再構築操作に20〜50ミリ秒しかかかりませんでした。 さらに、ビジネスロジックに従って変化しないデータをインデックスの再構築から削除しました。



たとえば、特定の値（フラグ付き、フラグなし、読み取り、未読み取り、フォルダーの値、アカウントごと）に対して、非常にシンプルで高速なインデックスがあります。 状態オプションの値が有限の場合、インデックスは迅速に再構築されます。 また、プレフィックスツリーに基づくテキストインデックスの再構築には時間がかかります。使用されるメモリ量の点で大きく、一般にこの構造はかなり面倒です。 これにより、検索プロセスを高速化できますが、非常に複雑であり、長期にわたって変化します。 これらは、さまざまな構造とデータ処理アルゴリズムの標準的な問題です。 検索で勝ちたい場合、このデータを変更することで自然に失われます。



最初は、テキストインデックスのさまざまな実装を試みました。 目立った違いに気付かず、測定により高速なものを選択しました。 しかし、私たちはまだ希望の時間指標に達しませんでした。 それから反対側に行くことにしました。 件名、送信者などのデータ 文字で操作中に変更されません。 そのため、単純に複雑なインデックスの再構築を拒否し、フラグ付き、フラグなしなどのパラメータを担当するインデックス、つまり高速に制限することができます。 不要な操作をすべて放棄し、放棄できないものを最適化し、すぐに50〜60％同期しました。



しかし、オペレーションをグループ化できるため、私たちもそれに留まりませんでした。 普遍的なアルゴリズムを作成しようとせず、有限バリアントに分解し、操作の種類ごとに入力データをグループ化する場合、データベースでの条件や不要な操作なしで実行できます。 フラグ、移動文字などを使用して操作を個別に最適化し、転送されるデータの量に依存しなくなりました。



その結果、ユーザーは、実行した操作の種類やデータに関係なく、迅速な応答を確認できます。 最初は100ミリ秒に設定しましたが、Android自体の制限にぶつかりました。トランザクションメカニズムはかなり遅く、使用しない場合は中間状態エラーが発生します。 要件を調整する必要がありました。 ユーザーの観点から、操作にかかる時間は200〜500ミリ秒以内になるように計画しました。 ほとんどの場合、Androidの次のバージョンでは、ユーザーの操作がほぼ瞬時に実行されるようにします。

インターフェース

既に述べたように、Mail Androidアプリケーションは、Webバージョンからスレッドを表示するロジックを継承しました。 ただし、インターフェイスの実装にはもちろん違いがあります。スマートフォンとタブレットの画面はデスクトップの画面よりもはるかに小さいため、スレッドの表示方法を決定する必要がありました。







最初に、2つのオプションから選択しました。 1つは、2レベルの表示（スレッドのリストと、文字の読み取りを組み合わせたスレッドビュー）です。 最初は、彼は私たちにとって論理的で望ましいと思われました。 しかし、この実装を他のアプリケーションでテストした結果、がっかりしました。すべてのケースで2つの画面にスレッドを表示するのは非常に不便でした。 そのため、3つのレベル（スレッドのリスト、このスレッド内の文字の表示、文字のオープンと読み取り）のオプションを選択しました。 この場合、ユーザーはヘッダーを見て、開きたい文字を選択できます。



メッセージはスレッド内で同じトピックを持っているという事実のため、グループ化され、より詳細なスニペットを表示する画面上の場所があります。 一般に、これはより便利であることが判明しました。長い通信で議論された内容を覚えておく必要がある場合は、文字のスニペットを使用してメモリ内で更新するか、目的の文字まですばやくスクロールして、重要なものがある場所から通信を読み始めることができます。



ビッグウェブとアプリケーションのもう1つの違いは、スレッド内の新しい文字の位置に関するものです。 Webバージョンでは、この情報を配置する場所がブラウザーにあるため、これは2つの画面で行われます。 Webは常にスレッドを表示し、このフォルダーの最後の未読レターまたはトップレターを開きます。その後、1つの画面で任意のレターを折りたたんだり展開したりできます。 Androidアプリケーションでは、ユーザーは現在、スレッドまたはレターの読み取り（会話に1文字しか含まれていない場合）で常に「失敗」します。 スレッド内の文字の間で、左または右にスワイプして移動できます。



それとは別に、スレッド全体に関連するツールバーについて話す価値があります。 ここで、AndroidメールにはWebバージョンとのより多くの不一致があります。 後者では、ツールバーはフォルダ内のスレッドの大文字で操作を実行できる大きなパネルです。 Mail.Ru Mail Androidアプリケーションでは、チェーン全体またはユーザーが選択した特定の文字を使用して作業が実行されます。 唯一の例外があります：スレッドでの作業が進行中の場合、このチェーンの最後の文字に答える機会があります。 これは非常に頻繁で重要なケースの1つであるため、このボタンをレターの読み取りから削除し、スレッドを操作するためのツールに含めました。 スレッドのメインアクションボタンと呼ばれる「返信」および「進む」ボタンは、チェーンの最後の文字に正確に適用されます。

Android WearおよびAndroid Autoとの相互作用

最初にAndroid WearとAndroid Autoのサポートを実装したため、時計とラジオを使ってAndroid Mailとやり取りするために特別なことをする必要はありませんでした。 ユーザーがメール設定で文字のグループ化を有効にしている場合、時計の通知もスレッドごとにグループ化されます。 文字のグループ化が無効になっている場合、すべてが以前と同様に機能し、通知はグループ化されません。 Android Autoラジオでは、通知もスレッドごとにグループ化されます。



私たちの意見では、タスクに対処しました。 しかし、いつものように、私たちはあなたからのフィードバックを本当に期待しています。 Androidでスレッドをテストして教えてください-あなたにとって便利ですか？