iOS development in the memory of an app bug resolution process (stepping on a storyboard pit)

Although today is a weekend, but still want to learn is not. The purpose of this blog is to keep a record of the pits that have been trampled on in the last iteration of the project, but the pit has been filled. Although the pit is not big, but must be able to step up the foot . In fact, that sentence, in the case of no one to show you the way, step on the pit more, slowly grow up. I didn't sleep in my nap to fill out the pit I was going to talk about today. Of course, the content of today's blog is not advanced, and the odds are pretty big, so just record it. Perhaps you have stepped on, or you have already filled the pit, but today is I stepped on the foot, no way, or record it.

The solution is described in one word:" Delete ".

First, describe this "pit"

First of all, let's take a look at the scenario where this bug occurred. A page push to page B, on the system below IOS9 on the A page for a period of time, and then on the push to page B. Of course a page and B page is still quite a lot of things. Under such a description, the bottom of the two application of the bar, the application has been launched, we can support it, the use of the two apps in the blog should be no big deal, presumably the company will allow it, of course, the code of the project is certainly not posted on the blog .

Below is a list of two bugs, and of course, these two parts are part of my responsibility for the project's needs. Click the Studio Info button on the studio page to push to the studio information page. When the button is clicked, the bug appears, and only the two pages jump. and iOS9 below the system in the first two to enter the "Studio Information" page will stutter, and the third time there is no this problem , it is really charm it.

The a page is written by Swift code , of course, using the snapkit Cloth's Bureau. The b page is written by Objective-c, and is made with storyboard . On the iOS8 or iOS7 from a push to B page card, and only in the first two entered the time of the card, re-enter the words are very smooth. What the hell is this? So, the process of troubleshooting the bug began.

Second, find "pit"

Bug appeared, the phenomenon is "lag". Realized that he had stepped on the pit, but where the pit, stepping on what pits to be cleared. Below is the whole process of positioning.

1. Narrow the scope of "pit"

On the "a" page there are 6 uicollectionview cells, clicking each cell will jump to the corresponding page. These pages of the jump are written by Swift, also have OC, have pure code, also have storyboard realization. But only when entering the B page of the time lag. So, it should be B page related things out of the question. Then we turn the target to the VC on the B-page related viewcontroller and storyboard.

As a viewcontroller, I added a breakpoint to the B-page's Viewdidload method to see if the card was executed immediately. Run a bit, click the button jump occurred card immediately found below the breakpoint and did not execute. That is, in the case of the card immediately B page view is not loaded, that is, the lag should occur before the view load is complete.

　　

Then the above results are then cleared, in order to determine the lag that occurs when the B view is loaded, the following code is written to test whether the loadview occurs. Sure enough, when you click the related cell on page A, a "front" log is printed, and then it happens. After the lag, a "post" is printed, followed by the entry and the B page. This makes it clear that the B view is stuck in Loadview and the B-page view is loaded by Storyboard, so the reason for this is that the control is implemented in the Storyboard of the B page.

　　

2, further find "pit"

After the previous step, we put ios8+ bug on the b page of the storyboard implementation. The following page is used by the Static TableView to do, each row is a cell, the entire TableView to delete, and then run will not be stuck. Thus the tableview on a static cell in turn, the deletion of each cell to run sequentially. As a result, the "profile" of this cell was deleted and then not stuck. So we put the problem to the "introduction" of the cell.

The status of the page back to the original state, and then the "personal profile" this textview to delete, found on the card. And with a personal profile this textview is still going to Dayton. The problem was then fixed on the TextView. That is not the textview constraints add to the problem, and then the constraints on the TextView to delete, but the problem of the lag still exists, it is certainly not the constraints of the control of the problem. That must be the problem with setting the TextView control itself.

After all of the above steps, we end up locating the bug in the Uitextview control of the profile on page B.

　

Iii. filling "pits"

Through the above steps, we find the location of the "pit". The next pits is not, and then I carefully examined the textview of all the configuration items, I really do not see any problem. Then I deleted this uitextview, and then dragged a random, found that there is no lag problem. So amazing, and then I contrasted the uitextview, and the biggest difference between my previous textview is that the new TextView's default text is in English , and it was in Chinese .

In the sense that this is the problem, and then suspect that "is not when the default value of TextView in storyboard is Chinese , when the view load rendering is very time-consuming?" ". This also depends on the experiment to speak, so, the previous " personal profile " changed to English, and then run, the results of the problem is good ! When filled with this pit my mood is excited, although pits means extremely simple, but pits posture is important. In fact, the process of finding a "pit" is more interesting than the process of pits.

　　

Iv. summary of the trample pit

At the end of the blog is to summarize. In the ios7.0+, ios8.0+ if you VC layout is implemented with storyboard, and on your VC has uitextview this space, and you storyboard on this uitextview set the "Chinese" default value, The VC then loads the view in the first two times. It should be time-consuming to load the view to render the "Chinese" default value in this TextView. The workaround is to "remove the Chinese default value in storyboard and add the corresponding default value in the Viewdidload method ."

In order to verify the problem again, I specifically wrote a small demo. Demo is relatively simple, is two VC, one VC push out another VC. There is a textview in the target VC, and the default value for this textview is the "Chinese" character. In this case, the iOS8 and iOS7 systems will be stuck on push, and there is no problem on the iOS9. Then change the default value of TextView "Chinese" to English, or remove it to solve the problem.

　　

Everything above is the "pit", "Find the Pit" and "pits" process. In fact, the process of finding a bug is quite interesting, although no nap, but also do not feel sleepy. OK, today's blog is here first.

iOS development in the memory of an app bug resolution process (stepping on a storyboard pit)