WX_Chat_YJ
I have been working in IM for a while, and this time I recorded some pitfalls I encountered before. I will share the chat part later. I hope it will be helpful to everyone. Among the projects I have been watching online before, I rarely talked about encountering pitfalls during the development process. If you write a chat for the first time, you may encounter more problems. Here I will mainly talk about the pitfalls I encountered. Everyone is welcome to take pictures. Please give me different opinions, thank you. Everyone makes progress together!
If it is useful to you, remember the stars!
Basic functions include
Retraction, deletion, copying of messages
Voice, text, pictures
Number of unread people
Other message styles customized in the project
In actual projects, there are cloud disk, video playback, and circle of friends...
1. Start with the framework
2. The database uses a WeChat open source WCDB without writing a SQL statement.
3. I encountered some of the following pitfalls
1. Interface lag
- When using the interface layout, UITableView+...Cell's third-party automatic height calculation is used. Because there are many project chat styles, only left and right styles are laid out when using the xib layout, and the style is controlled by hiding and displaying. Because of the development, I did not use too much data to test, which caused me to be very stuttered when there was too much data. The boss was talking about Kakaka, which was even more stuttering than the old cow pulling a broken car. This kind of stuttering was clearly felt when sliding the page.
After finding the cause of the problem, the following solution:
First, manually calculate the height and resolve the conflicts in Xib layout. The smoothness of the sliding page is acceptable. Of course, it may be better to achieve a better smooth frame layout.
At the same time, when Xib is using Xib layout, try to have as few levels as possible. More levels will affect fluency.
2. Data lag
- At the beginning, because we were involved in the processing of the number of unread people per message, we replaced the current chat message model through the unread numbers of the server receipt. When the number of chatterers reaches a certain level, more people will read the news. Receipts are frequent at this time. When the receipt comes back to refresh a certain data, the interface comes again. During this process, unreads are processed. There are some problems with the client. When sliding the page, send the currently unread message to the server. The server successfully returns it to indicate that it has been read. Server messages are queued and frequently received to the server. Servers are frequently pushed to clients. This causes page refresh to be too frequent. It gets stuck on our client side. (The problem with replacing messages at this time is to find the data to be replaced during the current message traversal)
After finding the root cause of the problem, the following methods were used to solve it:
- Save the messages you send separately, and replace the unreaded number only needs to replace the currently sent one.
- And when determining the height (heightForRowAtIndexPath) puts a current message position in each model. When replacing messages, you can quickly read and find the message to be replaced as needed. Never write here cellForRowAtIndexPath to determine the location. Otherwise, it would be a scam again.
The fluency of the above method basically meets the requirements. Only find the data to be replaced from the messages you sent, and the location has been determined. Just replace it directly.
3. Database reading message stuck
- At the beginning, we used FMDB.
- When storing data, the model data is stored directly, and it is found that when there is a lot of data, it is stuttering again. (We didn't use it well) I feel faster when saving, but when I read it, I get stuck when I get too much data. There is another one here, which is to transfer the picture to Data and save it in. When you first enter the page, if you have dozens of pictures in a row, you have to wait for a while when you click in from the outside. The main thread is stuck.
We will solve the problem when we find it:
- We use WeChat open source WCDB for database, which is more enjoyable in all aspects. No need to thank SQL statements.
If you save the model, you will also get the model, without any lag.
- For image processing, we use the image to data to store the sandbox, and use the key fields in the image address and message as keys to store the sandbox. At this time, the database only needs to store the address. Based on the key as this address, find the picture. After dozens of pictures tested, I didn’t feel it. Here we only cache the pictures we posted. The other party's image SdwebImageView is cached. The purpose of cached your own image is to send it to use for processing. Here we use NScache cache to process the code in the code...
4. When the page is full of expressions, it is stuck
- After the above treatment, the fluency is already acceptable.
But one day, a colleague posted the whole page, which was full of expressions on the system keyboard, and I went and got stuck again. And other colleagues also posted that it was Kakaka, which everyone can understand (and in addition, there is a test situation in our company, which is that everyone tests half an hour every day from Monday to Friday, and half an hour every weekend night. The boss and all the employees are there). Because we use ordinary UILable without any processing.
This is what I remembered of YYLable, asynchronous rendering, making the interface smoother and smoother. After the replacement, the smoothness increased a lot.
5. Seriously missed news
- After the first version of the chat came out, multiple people tested it together. The leak was found to be very serious. After investigation, important problems arose when we were storing the news.
- Current Solution:
- According to the message pushed by the socket, as long as the socket is connected, it will be saved.
- And after receiving the message, it is returned to the server (the server receives the largest message at the moment when the interval is very short). If there is no receipt, the server will push multiple messages when sending messages, and you have to arrange the heavy loads by yourself.
- Moreover, when the network disconnects the socket and reconnects, it will also pull messages, effectively ensuring data
6. Talk about the lag of multiple avatars
Here we want to make avatars of 9 people like DingTalk and WeChat. And when there is no avatar, the last word of the name should be displayed on the location of the avatar.
Here I have used 9 buttons, which can be used for pictures and text. I thought it would be stuck when there was a lot of data when I wrote it, but as a result, I calculated the frame adjustment position based on the actual number of avatars, and hid the buttons that were not needed. After the result was written. The effect is pretty good. Fluency can meet the requirements. Just say this avatar has been written by three people. hey-hey.
7. The content is still being improved...
