Interface fluency large list scrollView related closely associated
Smooth visual : that is silky smooth
Not smooth Vision : "Caton", "shake", "late he felt"
Two states described above are based on subjective feelings, for developers should indeed have a critical index to reference, if I write something as well as the optimization of space yet.
Per Second Frames (frames per second) this indicator can be observed through the Instruments tool Core Animation (xCode -> Tools - > Instrument).
Description page frame number 0 is at rest as long as the page a move, there will be a change in the number of frames and then comes to rest. That page was rolling up the number of frames is a trend of "asymmetric" parabola.
So a state reached a peak of number of frames will show a continuous change then this is its fluency, an ordinary scroll up a list of fluency about 60 (pro-test their app in a regular page), a complex page 53 - 60 (pro-test) say the internet was "45 frames per second, the frame rate has to make people feel less smooth, and if less than 40 frames per second, the average user will not notice the obvious fluent." so we can refer to a relative based on these reference, or test their application and comparison of several common page can also have a complex page. theoretical analysis of whether this can be relatively complex page optimization is worth it.
Can optimize the place (which is usually the place to shoot the forehead can think of)
1.CPU: Instruments which can be detected by the cpu and other tools found in the end is which function of relatively increasing the burden on the CPU
2. If tableView. Not very complicated to organize data to map a model? Are cell reuse? Drawing height method is not very long, constantly repeating the calculation? Need to refresh the tableView using improper way?
3. fillet rolling process view
Under normal circumstances we do:
.layer.masksToBounds = YES;
.layer.cornerRadius = imageView.size.width * 0.5;
This method is particularly affect the performance of the scroll view
the reason:
Cause of slow frame rates are actually Off-Screen Rendering (off-screen rendering).
Off-screen rendering: it refers to the CPU and then open up a new buffer rendering operations other than the current screen buffer.
Way off-screen rendering optimization is a very good performance, but the frequent occurrence of off-screen rendering (scroll will be very frequent ah) is very time consuming. If a fillet is almost not have much impact on the frame rate, the key number, if a good number. It can be seen from the above definition of "off-screen rendering" The key is not rendered but offscreen.
The cost of off-screen: The main reason is to create a buffer and context switching. Create a new buffer costs are not large, paid the ultimate price is the context switching !!!!! (a bitter tears Full of ridiculous statement pit over who is who knows)
About context switching:
In a context switch which is time-consuming operation, whether CPU rendering process or the process switching:
(1) We must ensure that the current screen rendering environment
(2) switch to a new environment drawing -> Drawing Application Resources -> Initialize Environment -> Start Draw -> Draw end -> destruction draw environment
(3) back to the main screen rendering or re-open a new off-screen rendering repeat (2)
solve:
So how to deal with this problem? Do not use the following methods in use scroll view cornerRadiu
(1) have to seek death using layer.ornerRadius, remember to also add the following method
= YES .layer.shouldRasterize; // this in most cases you can immediately save more than 55 frames per second. shouldRasterize = YES will view rendering content is cached, the next time the display buffer can be drawn directly, of course, the case does not change the content view. (Detailed explanation layer header file, enter to view the property description in English feel Ming Li)
= .layer.rasterizationScale [UIScreen mainScreen] .scale; // need to be properly set up "anti-aliasing" otherwise these views appear zigzagged on the retina devices. (See specific knowledge of layer properties)
(2) If the mask can be replaced with restriction FIG efficiency will be high if
(3) pre-cached fillet live picture (the background picture fillet pretreatment process, process it, cached, and then displayed in the main thread), to avoid rendering the off-screen
Resources
http://www.zhihu.com/question/20382396 (know almost)
http://www.cnblogs.com/ioriwellings/p/5011993.html (more specific solution)
Reproduced in: https: //www.cnblogs.com/someonelikeyou/p/5226449.html