Wx_chat_yj
Saya telah bekerja di IM untuk sementara waktu, dan kali ini saya merekam beberapa jebakan yang saya temui sebelumnya. Saya akan membagikan bagian obrolan nanti. Saya harap ini akan membantu semua orang. Di antara proyek yang telah saya tonton sebelumnya secara online, saya jarang berbicara tentang bertemu jebakan selama proses pengembangan. Jika Anda menulis obrolan untuk pertama kalinya, Anda mungkin menghadapi lebih banyak masalah. Di sini saya terutama akan berbicara tentang jebakan yang saya temui. Semua orang dipersilakan untuk mengambil gambar. Tolong beri saya pendapat yang berbeda, terima kasih. Semua orang membuat kemajuan bersama!
Jika berguna bagi Anda, ingatlah bintang -bintang!
Fungsi dasar meliputi
Pencabutan, penghapusan, menyalin pesan
Suara, teks, gambar
Jumlah orang yang belum dibaca
Gaya Pesan Lainnya Disesuaikan dalam Proyek
Dalam proyek yang sebenarnya, ada disk cloud, pemutaran video, dan lingkaran teman ...
1. Mulailah dengan kerangka kerja
2. Basis data menggunakan WCDB open source WeChat tanpa menulis pernyataan SQL.
3. Saya menemukan beberapa jebakan berikut
1. Antarmuka lag
- Saat menggunakan tata letak antarmuka, UITableView+... Perhitungan tinggi otomatis pihak ketiga Cell digunakan. Karena ada banyak gaya obrolan proyek, hanya gaya kiri dan kanan yang diletakkan saat menggunakan tata letak XIB, dan gayanya dikendalikan dengan menyembunyikan dan menampilkan. Karena perkembangannya, saya tidak menggunakan terlalu banyak data untuk diuji, yang menyebabkan saya sangat tergagap ketika ada terlalu banyak data. Bos itu berbicara tentang Kakaka, yang bahkan lebih gagap daripada sapi tua yang menarik mobil yang rusak. Gagap semacam ini jelas terasa saat menggeser halaman.
Setelah menemukan penyebab masalah, solusi berikut:
Pertama, menghitung ketinggian secara manual dan menyelesaikan konflik dalam tata letak XIB. Kelancaran halaman geser dapat diterima. Tentu saja, mungkin lebih baik untuk mencapai tata letak bingkai yang lebih halus.
Pada saat yang sama, ketika XIB menggunakan tata letak XIB, cobalah memiliki tingkat sesedikit mungkin. Lebih banyak level akan mempengaruhi kelancaran.
2. Lag data
- Pada awalnya, karena kami terlibat dalam pemrosesan jumlah orang yang belum dibaca per pesan, kami mengganti model pesan obrolan saat ini melalui nomor tanda terima server yang belum dibaca. Ketika jumlah obrolan mencapai tingkat tertentu, lebih banyak orang akan membaca berita. Tanda terima sering kali saat ini. Ketika tanda terima kembali untuk menyegarkan data tertentu, antarmuka datang lagi. Selama proses ini, Unreads diproses. Ada beberapa masalah dengan klien. Saat menggeser halaman, kirim pesan yang saat ini belum dibaca ke server. Server berhasil mengembalikannya untuk menunjukkan bahwa itu telah dibaca. Pesan server antri dan sering diterima ke server. Server sering didorong ke klien. Ini menyebabkan refresh halaman terlalu sering terjadi. Itu macet di sisi klien kami. (Masalah dengan mengganti pesan saat ini adalah menemukan data yang akan diganti selama traversal pesan saat ini)
Setelah menemukan akar penyebab masalah, metode berikut digunakan untuk menyelesaikannya:
- Simpan pesan yang Anda kirim secara terpisah, dan ganti nomor yang tidak diangkut hanya perlu mengganti yang saat ini dikirim.
- Dan ketika menentukan ketinggian (HeightforrowAndExpath) menempatkan posisi pesan saat ini di setiap model. Saat mengganti pesan, Anda dapat dengan cepat membaca dan menemukan pesan yang akan diganti sesuai kebutuhan. Jangan pernah menulis di sini cellforrowAndexpath untuk menentukan lokasi. Kalau tidak, itu akan menjadi penipuan lagi.
Kelancaran metode di atas pada dasarnya memenuhi persyaratan. Hanya temukan data yang akan diganti dari pesan yang Anda kirim, dan lokasi telah ditentukan. Ganti saja secara langsung.
3. Pesan membaca database lag
- Pada awalnya, kami menggunakan FMDB.
- Saat menyimpan data, data model disimpan secara langsung, dan ditemukan bahwa ketika ada banyak data, itu gagap lagi. (Kami tidak menggunakannya dengan baik) Saya merasa lebih cepat saat menabung, tetapi ketika saya membacanya, saya terjebak ketika saya mendapatkan terlalu banyak data. Ada yang lain di sini, yaitu mentransfer gambar ke data dan menyimpannya. Ketika Anda pertama kali memasukkan halaman, jika Anda memiliki lusinan gambar secara berturut -turut, Anda harus menunggu sebentar ketika Anda mengklik dari luar. Benang utama macet.
Kami akan menyelesaikan masalah saat kami menemukannya:
- Kami menggunakan WECAT Open Source WCDB untuk database, yang lebih menyenangkan dalam semua aspek. Tidak perlu berterima kasih kepada pernyataan SQL.
Jika Anda menyimpan model, Anda juga akan mendapatkan model, tanpa lag.
- Untuk pemrosesan gambar, kami menggunakan gambar ke data untuk menyimpan kotak pasir, dan menggunakan bidang kunci dalam alamat gambar dan pesan sebagai kunci untuk menyimpan kotak pasir. Pada saat ini, database hanya perlu menyimpan alamat. Berdasarkan kunci sebagai alamat ini, temukan gambarnya. Setelah puluhan gambar diuji, saya tidak merasakannya. Di sini kami hanya menyimpan gambar yang kami posting. Gambar pihak lain SdwebimageView di -cache. Tujuan dari cache gambar Anda sendiri adalah untuk mengirimkannya untuk digunakan untuk diproses. Di sini kami menggunakan Nscache Cache untuk memproses kode dalam kode ...
4. Saat halaman penuh dengan ekspresi, itu macet
- Setelah perawatan di atas, kelancaran sudah dapat diterima.
Tetapi suatu hari, seorang kolega memposting seluruh halaman, yang penuh dengan ekspresi pada keyboard sistem, dan saya pergi dan terjebak lagi. Dan kolega lain juga memposting bahwa itu adalah Kakaka, yang dapat dipahami semua orang (dan di samping itu, ada situasi uji di perusahaan kami, yaitu semua orang menguji setengah jam setiap hari dari Senin hingga Jumat, dan setengah jam setiap malam akhir pekan. Bos dan semua karyawan ada di sana). Karena kami menggunakan Uilable biasa tanpa pemrosesan.
Inilah yang saya ingat dari Yylable, rendering asinkron, membuat antarmuka lebih halus dan lebih halus. Setelah penggantian, kehalusan meningkat banyak.
5. Berita yang sangat terlewatkan
- Setelah versi pertama obrolan keluar, banyak orang mengujinya bersama. Kebocoran itu ditemukan sangat serius. Setelah diselidiki, masalah penting muncul ketika kami menyimpan berita.
- Solusi Saat Ini:
- Menurut pesan yang didorong oleh soket, selama soket terhubung, itu akan disimpan.
- Dan setelah menerima pesan, dikembalikan ke server (server menerima pesan terbesar pada saat interval sangat singkat). Jika tidak ada tanda terima, server akan mendorong banyak pesan saat mengirim pesan, dan Anda harus mengatur beban berat sendiri.
- Selain itu, ketika jaringan melepaskan soket dan terhubung kembali, itu juga akan menarik pesan, secara efektif memastikan data
6. Bicara tentang jeda beberapa avatar
Di sini kami ingin membuat avatar dari 9 orang seperti Dingtalk dan WeChat. Dan ketika tidak ada avatar, kata terakhir dari nama harus ditampilkan di lokasi avatar.
Di sini saya telah menggunakan 9 tombol, yang dapat digunakan untuk gambar dan teks. Saya pikir itu akan macet ketika ada banyak data ketika saya menulisnya, tetapi sebagai hasilnya, saya menghitung posisi penyesuaian bingkai berdasarkan jumlah aktual avatar, dan menyembunyikan tombol yang tidak diperlukan. Setelah hasilnya ditulis. Efeknya cukup bagus. Kelancaran dapat memenuhi persyaratan. Katakan saja avatar ini telah ditulis oleh tiga orang. hey-hey.
7. Konten masih ditingkatkan ...
