DIYチャット

この記事では、チャットを書くことの微妙な点について説明します。 十分な既製のソリューションがすでに発明されていることを理解しています。 果てしなく続く裏通りをさまよった後、「箱から出して」チャットを提供する適切なライブラリがいくつか見つかりました。 それらはこの記事にはリストされません。 したがって、既製のソリューションの見込みは魅力的であるように思われました。 しかし、今後のタスクの複雑さをもう一度考えて、ゼロから書くことにしました。



したがって、タスク：



カスタム（並行して開発された）XMPPサーバーに基づくバックエンド。 1つのチャットで複数のユーザーをサポートします。 セル-通常のテキストブロックで始まり、多くのテキストフィールド、ボタン、アニメーション、およびイベントの高さの変化を伴う画像とメッセージの送信で終わります。 メッセージのステータス（配信済み、既読など）。 特定のユーザーからの一連のメッセージを開始するセルにアバターを表示します。 エラーが発生した場合にすべてをキャッシュし、メッセージを再送信します。 もちろん、ローエンドデバイスでのスムーズな読み込み。









タスクはあまり一般的ではなく、プロジェクトの要件は完全には定義されていません。 以前は使用されていなかったライブラリに移動するのは危険です。 もちろん、これを使用することに決めたRxDataSourcesのようなバトルテスト済みのライブラリについては言えません。 何かが発生した場合、開発のどの時点でも、セルを操作するための手動で規定されたロジックに簡単に置き換えられます。 また、RxSwift、Realm、Alamofire、Kingfisherという緊急の「紳士向けiOS開発者セット」がありました。 また、それらをプロジェクトに接続しました。



メッセージリストは、3つの柔軟性を備えているため、UICollectionViewを介して実装されました。 UIKitのコレクションは、テーブルよりも美しくアニメーション化されます。 このアニメーションでは制御できます。 チャットの一部としてストーリーボードをすぐに放棄しました。自動レイアウトとパフォーマンスは別の銀河からのものではないにしても、少なくともお互いのことを知らないからです。



セルの内部アーキテクチャについて考える時が来ました。 一見、すべてがシンプルに思えます。メッセージは自分のものでも見知らぬ人でもかまいません。 さらに、アバターを表示するロジックをペイントし、コンテンツに応じて高さを計算することは価値があります。レイアウト上では、セルと他のセルの間の距離が異なるため、ロジックをペイントする必要があります。 また、セルの隅にあるメッセージの日付は、触れた場合にメインテキストを新しい行にプッシュする必要があり、iPhone 6までのデバイスでは、通常、レイアウトとサイズが別々になります。 数か月後、アプリケーションのデザインが変更され、インデントとフォントを簡単に変更する必要があります。



これはすべて、メッセージアーキテクチャを特に徹底的に設計する必要があることを示唆しています。



試行錯誤、複数のコードの再編成により、次の構造が生まれました。セルには3つの要素（アバター、送信者の名前、特定の種類のメッセージのビューが配置されるコンテンツを含むビュー）が含まれます。



Sellは、次の3つの方法でのみ構成できます（アバターと名前を使用し、送信者に関する情報を使用せず、コンテンツの上部にアバターを配置します）。









コンテンツは、「友だちか敵か」というメッセージの種類に応じて、画面の特定の端の近くに配置されます。 高さは、上記の構成に応じてテンプレートセルを使用して標準的に計算されます。 ここでは、セル間の距離が計算されます。 CollectionViewLayoutでは、ゼロに等しく、セルの高さに距離が単純に加算されるため、ロジックがオブジェクト全体に広がることはありません。



セルに配置されたビューのクラスをより詳細に検討する価値があります。 画面全体のレイアウトの大部分を共有します。 プロセスは単純ですが、時間がかかり、日常的な作業です。 ここでの主な困難は、基本クラスを正しく構成することです。 テンプレートメソッドパターンを適用して、コンテンツでビュー初期化アルゴリズムをカプセル化するクラスを作成し（サイズの計算、イベントへのサブスクライブ、サブビューの初期化と追加）、メソッド自体を再定義のために開いたままにします。



技術的な問題は、ページの読み込みに現れました。 iPhone 6に1ダースのメッセージが0.5秒読み込まれました-非常に弱い結果です。 実際、驚くべきことではありません。セルは重く、セルを作成して入力するプロセス全体がcellForRowで行われました。 このことから、主流は苦しんでいました。 バックグラウンドストリームでメッセージを受信した直後に、コンテンツを含むビューを作成するというアイデアがすぐに生まれました。 これは不可能だと言う人もいるでしょうし、彼らは正しいでしょう。 バックグラウンドでUILabelを作成して失敗すると、アプリケーションがクラッシュするだけです。 残りのUIViewプリミティブを使用すると、静かにバックグラウンドで自分自身を作成できます。具体的には、公式ドキュメントを使用して、UIViewクラスをバックグラウンドで作成できます。



練習では、オブジェクトのフレームも背景から設定できることが示されています。 これは、メッセージでセルの作成を汚し、バックグラウンドでセルのサイズを計算するためのロジックを出すのに十分でした。 また、willDisplayCellの時点でセルへのすべてのサブビューの追加をシフトすることにより、読み込みの滑らかさを著しく向上させたことは注目に値します。 そして、このメソッドでは、コンテンツビューに対してメインストリームに最終的に到達したことを明確にします。つまり、ここですべてのアウトレットを構成し（UILabelsを作成）、それらのコンテンツを置き換えることができます。 実際、メッセージを受信するとすぐに、バックグラウンドでセルサイズが形成され、次にこのサイズで生成され、最後の瞬間にすべてのコンテンツのレンダリングが表示されます。









セルには最小限の透明度が必要です。 デバイスの鉄が混合層を消化することは困難であるため、半透明のビューはパフォーマンスの惨劇であり、すべての複雑なコンポーネントを節約する必要があります。 ビューの角を丸くしても、半透明になります。 わかりやすくするために、デバイスシミュレーターの[ブレンドレイヤーの色]チェックボックスをオンにすると、赤で描画されます。 行うべきことは何もありません。少なくとも短時間で考えつくことはできません。



適用されるアプローチの唯一のマイナス点は、コンテンツを含むビューへのリンクの保存です。



一度作成すると、画面を終了した後を除いて、ビューの割り当てが解除されることはありません。 この決定は意識的になされました。 これにより、パフォーマンスの問題から解放されました。 小売ビューでは、サイズを計算し、一度だけバックグラウンドで作成できました。 これはほとんどメモリに影響を与えませんでした。主な原則は、写真を一緒にドラッグしないことです。 UIImageViewの画像フィールドは、didEndDisplayingCellで必ずゼロに設定し、セルが再び表示されるときにのみ値を取り戻す必要があります。



出来上がり、すべてがスムーズです！ 冗談。 Telegramでシームレスに。 しかし、私たちの条件では、非常に良いパフォーマンスです。 最低限サポートされているデバイスでも、ロードはほとんど目立ちませんが、最新のデバイスではまったく表示されません。 メッセージタイプへの追加は、ロードパフォーマンスに影響しませんでした。



そして、突然CollectionViewLayoutが破損したとき、何も悪いことはありません。 さて、あなたはこれが通常どのように起こるかを理解しています：コンテンツがうまくいかない、セルが見えなくなるなど、そしてこの場合のreloadData（）は保存されません...すべてが故障しました¯\ _（ツ）_ /¯。 これは、チャットをスクロールしているときに、未確定の時点で発生しました。 単一セルの挿入をコレクションの完全なリロードに変更し、RxDataSourcesを削除し、ビューの作成をメインスレッドに転送しようとしましたが、まったく役に立ちませんでした。 これは大規模なブランチのマージ後に発生したため、何がブレークの原因となったのかを正確に把握することはできませんでした。 ケースは好奇心が強く、真実を知りたいと思いました。 顧客はアセンブリを望んでいました。



「TableView、男、私たちはあなたをとても恋しく思いました！...裏切り者の意味で？」



コレクションがテーブルに完全に置き換えられるまで、文字通り数時間かかりました。 これが問題を解決するという絶対的な確実性はありませんでした。 しかし、TableViewは完全に機能しました。 彼はコレクションよりも少し速く働いたようです。 しかし、セルを挿入するアニメーションには、多くの要望があります。 チャットではまったく受け入れられないように見えるため、reloadData（）を使用してリストを更新することにしました。 しかし、CollectionViewの失敗は謎のままでした。UIKitの最も複雑な要素の1つであり、週末にはうまくいきませんでした。 主なことは、タスクが完了することです-チャットベースは適切なレベルで実装されます。



パフォーマンスは、深く興味深いトピックです。 しかし、私たちが遭遇した唯一のものではありません。 まだ奇妙なニュアンスがありました。 同じ反転テーブル。



誰もが知っているように、チャットメッセージは一番下から始まり、コレクションやテーブルにはこのようなセルを表示するための適切な機能がありません。 ここではCGAffineTransformを使用しました。テーブルを裏返し、セルを再び裏返しました。すべてが完璧であり、バグやパフォーマンスの問題は発生していません。



テキストによる日付のプッシュは、日付ラベルの長さよりわずかに長いメッセージのテキストに不可解なスペースを追加することで実現しました。 スペースがメッセージの端に達した場合、元のテキストも日付に触れたことを意味します。この場合、テキストは次の行に転送され、セルの高さが増加し、セルが日付マークを引きました。 このチップでは、メッセージはよりコンパクトに見えます。









AutoresizingMaskについて少し説明する価値があります。 一部の人々はその重要性を過小評価しており、コードからレイアウトする間、このテクノロジーがどのように機能するかを理解することは有用です。 私たちの場合、イベントによって引き伸ばされ圧縮されたセルがありました。 また、毎回フレームを復元しないように、マスクは、親のサイズに応じてビューのサイズが変更されるように設定されました。 単一の定数とコード行なし-純粋な魔法。 以下はその使用例です。最初にセルを作成してから、高さを増やし（マスクを使用しない場合、コンテンツはこの位置のままになります）、その後、日付が右下隅にプルされ、残りのコンテンツが引き伸ばされます。









次のニュアンス：キーボードが表示されると、その下に残ったメッセージを見ることができるように、テーブルはインターネットを下げるように設定されました。 また、インターネットの欠如についてプレートがポップアップした場合に備えて上部に展示し、下部では、メッセージを入力するフィールドの高さが変わったときにデフォルトで上部と下部のインターネットを別にして展示しました。 各場所に必要な定数を取り除いて追加するのはかなり脆弱なソリューションであり、少なくとも1つのメソッドがもう一度呼び出されると壊れます。 解決策として、UITableViewのラッパーは、各理由のインセットを持つ構造体の配列を含むように作成されました。 その理由は列挙に記載されており、配列が変更されるたびに、すべてのインデントが追加されてテーブルに割り当てられました。 したがって、残りを壊さずに各インセットを制御することが可能になりました。 言及する価値があります：私たちの場合、すべてのインデントは、以前に適用された変換のためにテーブルと一緒に上下逆さまになったため、上のインセットは下に、逆もまた同じでした。



言うまでもなく、開発中にはたくさんの興味深い瞬間や発見がありました。 繰り返しますが、無限の時間を投資して、アプリケーションをよりスムーズ、高速、柔軟にすることができます。 しかし、これは視覚的な部分とともに、最初の段階であり、チャットを正常に適用するために最低限必要なものです。 次のステップは、その使用経験の独自性です。 どこまで行けば、iMessageのネイティブiosメッセンジャーを利用できます。 応答性に加えて、メッセンジャーには多くの「ファッションチップ」があり、そのほとんどはどこにもありません。 コミュニケーションに関しては、それらはそれほど重要ではありませんが、チャットを別のエンティティと見なすと、そのような「チップ」の所有者は、他の人の背景に対してより完璧に見えます。 このような機能の実装段階は、まれに、アプリケーションの最初のバージョンに起因する場合があります。 したがって、チャットの最初のバージョンをリリースしたので、今後も作業を継続し、チャットに独自の機能を追加したいと考えています。