Making the address
WX_Chat_YJ
I have done IM for a period of time. This time, I will record some pits I met before. Later, I will share the chat part with you. In the projects I have been looking at online before, I met pits in the middle of development. If writing chat for the first time, you may meet more problems, here I mainly talk about their own pit. You are welcome to clap bricks. If you want different opinions, please raise them. Thank you. Make progress together!
# 1. The basic functions are
-
Messages are withdrawn, deleted, and copied
-
Voice, text, pictures
-
The number of unread
-
Additional message styles customized in the project
-
The actual project has cloud disk, video playback, circle of friends…
Second, the database is using wechat open source WCDB without writing a SQL statement.
Three, encountered the following pits
1. Interface lag
- The layout of the interface started with UITableView+… The third party of the Cell automatically calculates the height. Because there are many chat styles in the project, only the left and right styles are arranged when using the XIB layout, and the styles are controlled by hiding and displaying. Because of the development of the time, did not use too much data test, resulting in more data is very card, the boss said is kakaka, than the old cow pull broken car card. This kind of lag is obvious when you swipe the page.
After finding the cause of the problem, the following solutions are available:
-
After calculating the height manually and resolving the Xib layout conflicts. Slide page fluency is acceptable. Of course, if you want to achieve better smoothness, the frame layout might be better.
-
At the same time, the Xib uses the Xib layout with as few levels as possible. More layers can affect fluency.
2. Data lag
- Initially, because we were concerned with handling the number of unread messages per message, we replaced the current chat message model with unread messages from the server’s return receipt. When the number of people chatting reaches a certain level, the number of people reading the message is more. When the receipt is more frequent, when the receipt comes back to refresh a piece of data, then the interface khaki. In this process, no readings are processed. The client side is having some problems. The current unread message is sent to the server when the page is swiped. The server returns a successful message indicating that it has been read. Server messages are queued and frequently returned to the server. The server pushes the client frequently. The page is refreshed too often. It got stuck on our client. (The problem with replacing the message is that the current message traverses to find the data to replace.)
After finding the root of the problem, the following methods were adopted to solve it:
- Save the message sent by yourself separately, unread replacement only needs to replace the current message sent by yourself.
- And when height is determined (heightForRowAtIndexPath), place a current message location in each model. When replacing a message, you can quickly read the message to be replaced as needed. Don’t write it here cellForRowAtIndexPath determines the position. Or else we’re gonna get screwed again.
Through the above method the fluency is basically met the requirements. Find the data to replace only from your own message, and the location has been determined. I can just replace it.
3. The database reads messages without time
- When we started, we used FMDB,
- The model data was directly saved when the data was saved, and it was found that when there was a lot of data, it was stuck again. When we save it, it feels faster, and when we read it, it freezes when there is more data. There is another one here, which is to transfer the image to Data and save it. When you first enter the page, if there are dozens of images in a row, it takes a while to click in from the outside. The main thread is stuck.
When we find a problem, we solve it:
- Database we used wechat open source WCDB, all aspects to cool some. Never mind the SQL statement.
Save the model, take the model, there is no lag.
- For image processing, we transfer the image to data and store it in sandbox, and store it in sandbox according to the image address and key fields in the message. In this case, the database only needs to store the address. According to this address as the key, find the picture. After testing dozens of pictures did not feel. Here we only cache the images we posted. SdwebImageView caches each other’s images. The purpose of caching your own images is to send them for use doing processing. Here the NScache cache is used to process the code in the code…
4. Caton when the page is full of emojis
- After the above treatment, the fluency is generally acceptable.
But one day a colleague posted a whole page of emoticons from the system keyboard, and I got stuck again. In addition, we have a test situation in our company, that is, we test for half an hour at noon every day from Monday to Friday and half an hour at weekends. The boss and all the staff are there. Because we’re using normal UILable and we’re not doing anything with it.
This reminds me of YYLable, asynchronous rendering that makes the interface as smooth as possible. The smoothness increases a lot after the replacement.
5. A serious leak
- After the first version of chat came out, multiple people tested together. It turned out to be a serious leak. There was a major problem when we tried to save the message.
- Current solutions:
- According to the message pushed by the socket, as long as the socket is connected to the store.
- And when a message is received, it is returned to the server (after a short interval, the server received the largest message). If there is no return receipt, the server will push multiple messages when they are sent.
- In addition, when the network is disconnected and the socket is reconnected, the message is pulled, effectively ensuring data
6. Talk about caton with multiple heads
Here we are going to make 9 heads like Dingding and wechat. And when there is no profile picture, the position of the profile picture should show the last character of the name.
Here I use 9 buttons, buttons with pictures and text. The result is that the 9 heads button is used to calculate the frame adjustment position according to the actual number of heads, and the button is not needed. So when I write it down. It worked out pretty well. The fluency can meet the requirements. By the way, this head was written by three people. Hey hey.