A iOS App optimization (stepping pit) trip

The optimization of the bug is not a deliberate source, this sentence has been done to optimize the depth of the students will be able to understand the bitterness. Today to share with you the next time to optimize the CoreText to fill the pit experience. Remember that time, iPhone 4S is still the mainstream models on the market.

Optimization causes

Was doing a IM App, product manager feel every time the first time to enter the chat interface a bit slow, and after entering the first slide card. It is due to the slow and the card, resulting in a series of subsequent optimization. Before starting an introduction to the optimization program, let’s start with the first experience.

First experience problem

The first experience is a classic scene, many App have similar problems exist. It is described that the new App into a scene, due to the delay of the first necessary resource loading, logic operations, etc., resulting in a delay in the user experience.

For example, you re open the WeChat Kill process, if the rapid slide session list, you can feel the obvious sliding animation Caton, and this Caton would experience once again when the slide back and forth and completely smooth. Most of the time consuming is due to the IO disk read of the head file, and fillet drawing. Ready to join cache after consuming resources disappeared, of course, avatar can asynchronous to the child thread to draw, but will lead the user to see Avatar avatar by default into the real picture “, the experience is a bit poor, apparently taken by WeChat synchronous rendering mechanism.

Of course, this is not a big problem, and now the hardware is fast enough, the function of the scene is also more than a few seconds of delay in the experience can be endured.

Back to the product manager just said the slow and card, in fact, is the classic experience for the first time. The first time to enter the chat interface, there are a lot of resources need to be prepared:

  1. Creating Controller and related classes
  2. Read message list
  3. Render message

After Instrument Profile, it was found that App had a considerable part of the time spent on the rendering of CoreText. At that time, the text of the App message is drawn using CoreText, and the entire process of CoreText which is one of the most important step: the height of the text message and hyperlink detection.

At that time, a head shot, there is a program to the space for time, the text of the high width and hyperlink information are stored in database, so the next time you do not have to restart the calculation, so there is the following code:

BOOL needDetectLink_calculateSize = false; if (textMsg.textWidth = = 0) {needDetectLink_calculateSize = true;} if {textSize = [_Msg_Helper (needDetectLink_calculateSize) calcuteSizeOfAttributedMessageText:textMsg.attributedMsgString withFrame:textMsg.ctFrame lastLineWidth:& lastLineWidth]; textMsg.isDirty = true;} else {textSize = CGSizeMake (textMsg.textWidth, textMsg.textHeight);}

After the calculation, and then start a background task in the sub thread to calculate the good information (dirty message) into the database. After the optimization of the product manager experience, product manager found a lot faster than before, very satisfied, happy.

First pit:

The original optimization task happy ending, until more than a year after the test students suddenly took the phone to me to see a strange news:

A iOS App optimization (stepping pit) trip

The last word seems to be cut off a small part, after a debugging, that is not cached before text width information, and spent a few hours to investigate why the width of the code is wrong, do not see any problems, and some text messages show no problem, only a specific message will appear, until accidentally caught a glimpse of mobile phone system language is Japanese, suddenly think it would not be the two systems under different language Chinese font, a survey indeed.

The first use of the Chinese system to send text messages, and then switch to the Japanese system will be able to reproduce the above probability, although the scene is relatively small, after all, is a bug, or repair a repair:

BOOL needDetectLink_calculateSize = false; if (textMsg.textWidth = 0 || preSysLanguage! = curSysLanguage) {needDetectLink_calculateSize = true;}

I think it is quite simple, the judgment of the system language can be rendered.

Second pits:

After more than a year, iOS 9 release, test students came over to me to see the following picture:

A iOS App optimization (stepping pit) trip

My first reaction is not to change the language, but for the language of the scene I had to deal with, according to the previous idea is likely to change the font, along the train of thought, oh, the original iOS 9 system for Chinese fonts. So I should change the code to this:

BOOL needDetectLink_calculateSize = false; if (textMsg.textWidth = = 0 = curSysLanguage || || preSysLanguage! PreiOSVersion! = curiOSVersion) {needDetectLink_calculateSize = true;}

This can be a total, or a little more insurance, I judge whether the font before and after the two rendering is consistent. Can be two times in a row, let me have an accident of this code has been suspected, and finally touched my hand silky smooth hardware index burst table iPhone 5S, I thought of a better solution.

Final plan:

I closed the optimization.

Welcome to the public number: MrPeakTech

A iOS App optimization (stepping pit) trip