wx_chat_yj
私はしばらくの間IMで働いてきましたが、今回は以前に遭遇したいくつかの落とし穴を記録しました。後でチャット部分を共有します。私はそれが誰にでも役立つことを願っています。私が以前にオンラインで見てきたプロジェクトの中で、開発プロセス中に落とし穴に遭遇することについて話すことはめったにありませんでした。初めてチャットを書くと、より多くの問題が発生する可能性があります。ここで、私が遭遇した落とし穴について主に話します。誰もが写真を撮ることができます。別の意見を教えてください、ありがとう。誰もが一緒に進歩します！
それがあなたに役立つなら、星を覚えておいてください！
基本的な関数には含まれます
1。フレームワークから始めます
プロジェクト操作スクリーンショット
基本的なプロジェクト構造
2.データベースは、SQLステートメントを記述せずにWECHATオープンソースWCDBを使用します。
3.次の落とし穴のいくつかに遭遇しました
1。インターフェイスラグ
- インターフェイスレイアウトを使用する場合、uitableview+...セルのサードパーティの自動高さ計算が使用されます。多くのプロジェクトチャットスタイルがあるため、XIBレイアウトを使用すると左右のスタイルのみがレイアウトされ、スタイルは隠れて表示することで制御されます。開発のために、私はテストするためにあまりにも多くのデータを使用しませんでした。そのため、データが多すぎると非常にst音が出ました。ボスはカカカについて話していました。カカカは、壊れた車を引っ張る古い牛よりもさらにutter音でした。この種のst音は、ページをスライドさせるときにはっきりと感じられました。
問題の原因を見つけた後、次の解決策：
2。データ遅れ
- 最初は、メッセージごとに未読の人の数の処理に関与していたため、サーバーの領収書の未読番号を通じて現在のチャットメッセージモデルを置き換えました。おしゃべりの数が一定のレベルに達すると、より多くの人々がニュースを読むでしょう。現時点では領収書が頻繁に発生します。領収書が戻って特定のデータを更新すると、インターフェイスが再び登場します。このプロセス中、未読は処理されます。クライアントにはいくつかの問題があります。ページをスライドするときは、現在未読メッセージをサーバーに送信します。サーバーは、それが読み取られたことを示すために正常にそれを返します。サーバーメッセージがキューに登録され、サーバーに頻繁に受信されます。サーバーは頻繁にクライアントにプッシュされます。これにより、ページの更新が頻繁になりすぎます。それは私たちのクライアント側に立ち往生します。 （現時点でのメッセージの交換に関する問題は、現在のメッセージトラバーサル中に置き換えるデータを見つけることです）
問題の根本原因を見つけた後、次の方法を使用してそれを解決しました。
- 送信するメッセージを個別に保存し、現在送信されているものを交換するためにのみ読み取られていない番号を交換する必要があります。
- また、高さを決定するとき（heightForRowAtIndexpath）は、各モデルに現在のメッセージ位置を置きます。メッセージを置き換えると、必要に応じて置き換えるメッセージをすばやく読み取り、見つけることができます。場所を決定するために、ここにcellforrowatindexpathを記述しないでください。そうでなければ、それは再び詐欺になります。
上記の方法の流encyさは基本的に要件を満たしています。送信したメッセージから置き換えるデータのみを見つけると、場所が決定されています。直接交換してください。
3.データベース読み取りメッセージラグ
- 最初はFMDBを使用しました。
- データを保存すると、モデルデータは直接保存され、多くのデータがある場合、再びutter音がすることがわかります。 （私たちはそれをうまく使用しませんでした）私は保存するときより速く感じますが、それを読むと、私はあまりにも多くのデータを得ると立ち往生します。ここには別のものがあります。これは写真をデータに転送して保存することです。最初にページに入力したら、数十枚の写真が連続している場合は、外からクリックするとしばらく待つ必要があります。メインスレッドは立ち往生しています。
問題を見つけたら、問題を解決します。
- データベースにWeChatオープンソースWCDBを使用します。これは、あらゆる面でより楽しいものです。 SQLステートメントに感謝する必要はありません。
モデルを保存すると、遅れなくモデルも取得できます。
- 画像処理には、画像を使用してデータをデータに保存し、画像アドレスのキーフィールドとメッセージを使用してキーとしてサンドボックスを保存します。現時点では、データベースはアドレスを保存するだけです。このアドレスとしてキーに基づいて、写真を見つけます。数十枚の写真をテストした後、私はそれを感じませんでした。ここでは、投稿した写真のみをキャッシュします。相手のイメージsdwebimageviewはキャッシュされています。独自の画像をキャッシュした目的は、処理に使用するように送信することです。ここでは、nscacheキャッシュを使用してコードのコードを処理します...
4。ページに式がいっぱいになったら、それは立ち往生しています
- 上記の治療後、流encyさはすでに受け入れられます。
しかし、ある日、同僚がページ全体を投稿しました。これにはシステムキーボード上の表現がたくさんあり、私は行って再び立ち往生しました。また、他の同僚は、誰もが理解できるカカカであると投稿しました（さらに、私たちの会社にはテスト状況があります。つまり、毎日月曜日から金曜日まで、毎週30分、毎週30分をテストします。上司とすべての従業員がいます）。処理なしで通常のUILableを使用するからです。
これは、私がYylableの非同期レンダリングを思い出し、インターフェイスをよりスムーズでスムーズにすることです。交換後、滑らかさは大幅に増加しました。
5.真剣にニュースを逃した
- チャットの最初のバージョンが発表された後、複数の人が一緒にテストしました。漏れは非常に深刻であることがわかりました。調査後、私たちがニュースを保存しているときに重要な問題が発生しました。
- 現在の解決策：
- ソケットによってプッシュされたメッセージによると、ソケットが接続されている限り、保存されます。
- メッセージを受信した後、サーバーに返されます（サーバーは、間隔が非常に短い瞬間に最大のメッセージを受信します）。領収書がない場合、サーバーはメッセージを送信するときに複数のメッセージをプッシュし、自分で重い負荷をアレンジする必要があります。
- さらに、ネットワークがソケットを切断して再接続すると、メッセージをプルすると、データが効果的に保証されます
6。複数のアバターの遅れについて話してください
ここでは、DingtalkやWechatのような9人のアバターを作りたいと思っています。アバターがない場合、名前の最後の単語をアバターの場所に表示する必要があります。
ここでは、写真やテキストに使用できる9つのボタンを使用しました。書いたときに多くのデータがあったときに立ち往生すると思いましたが、その結果、アバターの実際の数に基づいてフレーム調整位置を計算し、不要なボタンを隠しました。結果が書かれた後。効果はかなり良いです。流ency性は要件を満たすことができます。このアバターは3人によって書かれたと言ってください。ちょっとハイ。
7.コンテンツはまだ改善されています...
