Optimizing the overall principle of iOS performance optimization (performance optimization is important, why don't you use it?) ）

The author has done some optimization work in the iOS development process, has some superficial understanding to the iOS performance optimization, has been wanting to own these experiences, summarizes briefly.

As the first of the series, I intend to summarize some of the general principles of iOS optimization. Because I think whether the list smoothness optimization, startup time optimization or other aspects of optimization, there are some common principles, only master the principles of these general, can better do optimization, give us specific optimization tasks to indicate the direction, let us less detour. Later, if time permits, I might write articles about list fluency, startup time, and memory optimization.

As a developer, there is a learning atmosphere with a communication circle is particularly important, this is a My iOS communication group: 638302184, whether you are small white or Daniel Welcome to settle, share bat, a inside test, interview experience, discuss technology, we exchange learning and growth! Hope to help developers less detours.

In the first "general principles of optimization". I summed up the overall principles of optimization, including do not advance over-optimization, to find performance bottlenecks, to be in different performance indicators, to understand the underlying operating mechanism of optimization tasks and to have a technical guarantee system of the five Principles, which specifically elaborated each principle is not limited to performance optimization, will spread to other related areas, Will do some simple discussion on some extended areas, hoping to have some revelation to the readers. The following is the main content of the first article.

First, do not over-optimize ahead of time

1, this principle includes two traps that need to be avoided during the optimization process, i.e., pre-optimization and over-optimization. Advance optimization refers to the performance optimization as an important task to consider in the initial stage of development, in the absence of actual data indicators on the basis of performance in advance to do some of the blind optimization work.

Of course, this view may be controversial, because in some areas of development, some performance indicators in the history of experience, there is indeed a great probability or even inevitably have a performance bottleneck, so in the early stages of the architecture need to consider performance issues. Therefore, I think it may not be appropriate to promote the idea of "don't optimize ahead" in all areas of development.

But if this view is constrained in the field of iOS development, I personally think it is still set up. Because the performance of the iOS platform is generally better at this stage, Apple has done a lot of optimizations on the performance side, both at the hardware level and at the system level. So I think the performance side is not the first thing to consider in the iOS development process. Compared to performance, I personally think that in the initial phase of iOS development, the following aspects are more important and need to be considered first.

2, the first thing to consider is the choice of architecture, where the architecture refers to the native architecture, the Web architecture, the native and the Web hybrid architecture, and the cross-platform architecture. My personal opinion is that we should try to avoid using the Web architecture first, and from the early experience of Facebook, we can see that there are many problems in performance, experience and so on compared to the web and native.

Even the company can not completely improve the webview problem, not to mention us. However, in some cases, compared with the user experience, the dynamic needs of the more urgent application scenario, you can choose the Web architecture, such as everyone has been spit slot a railway ticketing software. The advantage of the native architecture is that the product experience is good, and the technology stack for most iOS developers is friendly, and the downside is that Apple's strict restrictions on hot updates make it impossible for some dynamic schemes to be used.

Native and web hybrid architectures are mainly in the native architecture, in some scenarios where operational requirements are strong (such as e-commerce scenarios), some modules use web development, which can be used in most scenarios of the app native architecture, to ensure the user experience, It also satisfies the requirement of the dynamic of some scenes. The cross-platform architecture is mainly to reduce the cost of multi-terminal development, using a set of code to complete the development of iOS and Android two platforms, the current mainstream framework is reactnative, Weex and Xamarin.

The vision of these cross-platform architectures is good, but in practice, individuals feel that at this stage is no more than using the native architecture to save manpower, which will encounter many known unknown pits, of course, as a new technology we should develop a mindset, but in the use of time also need a comprehensive assessment, Especially as a possible long life cycle of the application, in the use of non-official recommendation of the development structure, open Source Library, or if the latter is not maintained, their team is not the strength to the tray, if not, the use of Apple's official recommended technology stack is more secure.

3, the second thing to consider is the choice of development language, this aspect in fact, after the selection of the architecture, but also the optional development language range narrowed to several. and the actual project development is not difficult to choose, because the team developer's technology stack almost determines the use of the development language, if the majority of the team members are unfamiliar with the language, I believe that even if the selected language in many ways has an overwhelming advantage, the project will not go very smoothly.

But the factors that exclude the team technology stack, the different development language is indeed unique. As we all know, the official development language is OBJC and swift if you use the native architecture during iOS development. OBJC is the official recommended language for early iOS development, with the advantage of being dynamic, flexible, and able to implement many "black magic", with a slightly weirder syntax (of course, it's not weird for iOS developers to use it for a long time), In addition, it is not very good to support some advanced language features (remember the first time you used OBJC to develop iOS apps because of some special needs.)

Because OBJC does not support namespace, the team caused a lot of trouble). Swift is Apple's main development language in recent years, which absorbs the advanced features of many other languages and is also relatively easy to get started with. With regard to the specific technical details of the two development languages, it is interesting to have a look at some of the information yourself. While Apple has been pushing swift, it is currently in the domestic iOS development area, because some of the major user base apps are written using OBJC before Swift, and mostly after several years of version iterations, plus early Swift ABI instability and version upgrades require more work, as well as swift and OBJC mixed problems, leading to the current domestic mainstream apps mostly still use OBJC as a development language.

In some startups, or new projects, only some developers use swift, of course, if the long-term vision, the future must be swift world, the two years OBJC in the annual language rankings of the yearly decline also confirms this point. In addition to the official recommended OBJC and is swift, if you use other architectures such as cross-platform, you can also use such as JS, C # and other languages, interested can be self-aware.

4, again need to consider is the development process specific code architecture choice, here simply talk about the code architecture selection under the native architecture. There are MVC, MVVM, VIPER, MVP, and so on, which are commonly used in iOS development. With regard to these architectures, there are many introductions on the Internet, so if you are interested in specific details, you can check them yourself. Here I just want to add that when you learn and practice, do not blindly follow the new technology, such as MVVM and other architectures may not be much better than MVC, MVC is not necessarily an outdated framework. It is possible to realize that many of the extensibility and decoupling lines brought by the new architectures are implemented by introducing an indirect layer, which can be followed by more glue code and more complex code structures. I hope you can choose the most suitable code architecture for your team and project according to the characteristics of the project and the situation of the team.

5, in addition to the three points mentioned above, there are some other key points need to be considered at the beginning of the project, such as how to achieve a unified code style within the team? How are some key technologies chosen? How to ensure the code structure is clear, simple, extensibility and so on. Performance issues can be considered at the end of the project, and if you really find that there are significant performance problems to optimize, it's too late. For example, when a project starts with an intuitive sense that a module may have performance problems, it blindly uses multiple threads instead of specific analysis based on the actual problem. Causes the program to become complex and prone to thread-safety issues.

Over-optimization means that the development cycle is longer, in order to optimize performance, increase system complexity and maintenance costs over time. While there may be some improvements in performance, it is obvious that this is not worth the benefit of the disadvantages that are caused by over-optimization.

6, the author in the work process, found that many students in the performance optimization process, are easy to fall into this over-optimization traps. For example, this simple setup interface, a total of only more than 10 static cells, if you consider fillet performance, off-screen rendering, picture caching, height caching, asynchronous rendering and even caching layout information, these are undoubtedly caught in the trap of over-optimization, in this application background, simple and fast implementation of the function is the first priority. In the current Apple development framework and platform, generally if the performance problem, in my actual experience, the problem is mostly out of business logic above, so encounter problems first need to find problems in business logic, some excessive limit optimization, is completely unnecessary.

In fact, not only performance optimization, I found that many students in the daily development, everywhere there are over-design situation. For example design happy this trap, many beginners at the beginning of learning design patterns, very obsessed with design patterns in solving different problems, the decoupling of code and scalability of the power, in the development process will always think about what design patterns should be used. The result is a lot of over-design, in fact, we write code process, if we can abide by the basic solid principle, in most cases can write high-quality code.

Second, to find performance bottlenecks

1, before doing optimization, we must first find out what performance bottlenecks, according to the severity of the performance of each solution. Do not blindly optimize, otherwise it may take a lot of effort, the optimization may be only a small part of the performance loss. This principle I think is particularly important, because I have met in the work, including me, many do not perform performance bottlenecks to find, all based on subjective speculation performance optimization situation. The following issues also need to be noted during the search for performance bottlenecks.

2, do not subjectively guess, let performance evaluation data speak.

This is very important, always remember to speak with the facts, do not think that the algorithm used by a function of the time complexity O (N2) feel certain there will be a performance problem, not a great effort to optimize to O (N*logn), but you can input data may only be dozens of or hundreds of, even if O (N2) There's not much of a performance problem. Also don't assume that a method simply calls a simple get method of the system library, there is no performance problem, but this get method may contain some very time-consuming operations (such as disk IO). Therefore, when encountering performance problems, do not rely on subjective speculation, the field run performance data, let the data tell us where the performance bottleneck.

3, use the appropriate performance evaluation tool.

For the performance optimizations of development releases, Xcode provides the instruments is definitely the best tool to look for performance bottlenecks, not one of them. Instruments has a wealth of performance evaluation tools, including Common Core Animation, time Profiler, leaks and allocations, and more. These tools provide me with a very convenient function for analyzing function execution time, FPS, and memory. You need to be aware of using the instruments process: use a real machine instead of an emulator. The emulator has a much faster CPU than the iOS machine, so CPU-related operations are faster on the emulator. Because the GPU on your Mac is different from the GPU on your iOS device, the emulator requires software on the CPU to emulate the GPU on the iOS device, so GPU-related operations are slower. Therefore, if you use the simulator to perform performance optimization, the performance of the evaluation equipment and real user equipment inconsistent, will lead to the optimization of the effect of a significant discount. This memory is an exception, when doing memory optimization, using the simulator and the real machine is generally not very different, you can use the simulator for memory optimization.

To use the release configuration instead of the debug configuration, because the compiler does some optimizations to improve performance when you release the package. Your own engineering code may also do some optimizations under release, such as removing log information and some debug functions. What we are concerned about is the performance under release, because the user is finally also using the release installation package.

So when testing to be sure to remember in the release configuration, instruments performance evaluation, the default is under release. But the optimization in the engineering code needs to be noticed. The author has paid a great price for this, because did not pay attention to some of the code inside the debug function, resulting in the optimization process wrong to think that the dynamic library is the culprit to affect the startup time, spent a great deal of effort to change the dynamic library into a static library, wasted a lot of time.

To use a relatively poor performance of the machine to evaluate, because we need to ensure that our application in poor performance of the machine also has good performance. If there are conditions, it is better to be able to cover multiple models, unlike our traditional understanding, the newer the model is not necessarily higher, such as iPad3 in animation and rendering performance than iPad2 poor.

To overwrite different system versions, because on iOS systems, the higher the general system version, the same machine performance tends to be poor, so if only the lower version of the model is covered, performance on the higher version may be unsatisfactory.

In addition to using instruments, you can use log and other methods to find performance bottlenecks.

For online apps, the main tool for finding performance bottlenecks is application performance Management (APM). At present, the major companies have their own APM, mainly on the online app performance monitoring and early warning. Because of the relatively limited number of users in the development and testing phase, it is difficult to cover all business scenarios. And after the app is released, a lot of users in the process of performance, will give our app to bring more comprehensive performance evaluation data, so online app performance monitoring is very important.

To grasp the focus, targeted. Find the top n problems with large performance losses, solve them according to the importance and ease of resolution, so as to spend the least effort to solve the biggest problems.

Third, to the different performance indicators to balance, to achieve the overall optimal

1, when the performance bottleneck has been found, the solution to the performance problem needs specific analysis, to the different performance indicators to achieve the overall optimal.

This requires us to have a holistic sense, the performance of the app can be divided into many classes, different performance indicators on the user experience impact is not the same, for example, the main impact of FPS is the user's sliding experience, page load time and application startup time affect the user waiting time experience. In the process of optimization, we have to keep in mind that our goal is to optimize the overall experience of the app rather than the performance index of a single item.

2, different optimization indicators may be positive correlation, such as the optimization of the sliding process of a large number of functions of time, so that the performance of FPS increases, may lead to less power consumption of the app. At the same time, the different optimization indicators may be negative correlation, mutual constraints, such as to do too much for fluency cache, will lead to memory performance degradation, and even caused by the system killed because memory warning, which undoubtedly has a negative impact on the overall experience of the app. Therefore, the actual optimization process requires us to repeatedly weigh the pros and cons, to achieve the overall performance optimal.

Iv. Understanding the underlying operating mechanism of the optimization task

1, it may be difficult to achieve better optimization results without understanding the underlying operating mechanism of the optimization task.

For example, if you do not know the startup time of an app in iOS is made up of two parts of the time before main and main after the start time optimization, if your app is taking up too much boot time because the part before the main function You may have spent a lot of time optimizing the main and not achieving a good optimization effect.

If you don't know how the app starts, you won't know whether to link too many custom dynamic libraries or go to the load function to check for time-consuming operations and so on. And when it comes to FPS optimization, if you don't know what the underlying cause of the lag is, how does a view go through the steps, CPU and GPU in the process from creation to display, it's hard to be smooth? And when it comes to memory optimization, it's hard to do memory optimization if you don't know what kind of memory it is, how the system is different from the memory-throttling mechanism of the app and the different types of extension, what the limit system will do, and so on. Therefore, only in-depth understanding of the underlying mechanism to better targeted the proposed better solution.

2, in fact, not only in the performance optimization, in the development process in many cases, understanding the underlying principles will make you more efficient, more easily solve the various problems encountered. Share an experience that I have a deep impression of. Remember that one time when developing a feature, you need to use the level DB database, in the development process to do unit testing, the level of the local storage files in the process of deletion and writing, the larger, even reach 1G size. At that time the first impression that the use of the problem, so the upper business logic to find the problem, the results of a long time did not find the problem. But if I was using level db to learn more about its underlying implementation principle, the principle of LSM (Log-structured-merge Tree), it would not be considered a bug when confronted with this problem, and would not waste a lot of time doing useless work. So it is recommended that you do not complain about the daily work is too simple and boring, in the development process to dig some deep-seated things, not only let your depth of technology deepened, but also to your coding efficiency has a great increase.

Five, to have a technical guarantee system

1, performance optimization can not once and for all, I personally feel more a protracted war. Not only need you to be able to do special optimization at a particular time of the battle, but also for the fight to make good logistical replenishment, in order to enable the app to maintain good performance over the long term, not only need developers have good development skills, but also need some technical support and system. Here's a quick list of some of the things I can think of.

2, to have a good test guarantee, the test guarantee here is not only refers to the test personnel manual testing, more need for automated testing. In order to set up special automatic test for different performance index, set up a set of complete automatic test system from the timing running test to the output of test result, which can provide solid data support for the performance guarantee.

3, the introduction of key performance indicators on-line access system. In the development phase, in order to not bring the code of performance problems to the line, such as start time, FPS, installation package size and other indicators as the key indicators, before the online testing, such as indicators are not standard, not allowed to go online.

4, for the online app using APM to monitor, found the performance problems on the line, there is a timely warning mechanism, can be at any time to solve the problem of online performance.

5, in the development process, the code needs to have a performance assurance design. For example, you can design reusable high-performance controls so that other developers can simply reuse them when developing similar functionality, not only improving performance, but also saving development time. For example, in order to prevent the app as the version iteration caused the service to load more and more, resulting in slow startup, you can design the app launcher, put these tasks unified to the main interface after the completion of loading, and in the group of developers to form a rigid specification, any start-up period does not need to do, or do not execute, It is either uniformly placed into the initiator's main interface when the completion of the callback is executed.

Regularly do some performance optimization technology sharing, not only can improve the students in the group's development skills, but also active in the group of technical atmosphere.

Above my summary of the overall principles of iOS performance optimization, I hope to have a little revelation to everyone. Many of these ideas may not be mature, and we hope that we can criticize each other and make progress together.

As a developer, there is a learning atmosphere with a communication circle that is particularly important this is my iOS communication group: 638302184, whether you are small white or Daniel Welcome to settle, share bat, a inside questions, interview experience, discuss technology, we exchange learning and growth!

The article originates from the network, if has the infringement, please contact the small compilation to delete.

Optimizing the overall principle of iOS performance optimization (performance optimization is important, why don't you use it?) ）