How to write a stable and smooth iOS mobile app

Original link: http://www.jianshu.com/p/f4adce56166f

Don't forget beginner's mind

Over the past few years, mobile apps have swept the globe with Thunder. The way we use the Internet in our work and leisure time has changed as the mobile app progresses. In the development of applications, people also began to consider the "mobile first" approach. We are facing a new generation of mobile devices, such as wearables or a multitude of mobile gadgets, that make up the "Internet of Everything" world. We will face a new user interface, through their data display and instruction receive processing. At the same time, we will see that more and more companies will really practice the "mobile first" mentality. And over the next few years, all of this will affect how we design, develop and test software.

A client to do a stable, no rush, smooth, is to write client friends dream, but the results we face are often unsatisfactory. The World martial arts, only fast not broken. Many companies believe in this dogma. The application development cycle can be compressed to a minimum, which leads to a lot of problems hidden in the development. Some experienced engineers are sloppy, and worse, inexperienced engineers don't even make any optimizations to the app, which can make things worse.

Ten years ago, the hardware resources of mobile devices were very limited. Even floating-point numbers are banned. Because floating-point numbers can cause calculations to slow down. With the rapid development of science and technology, hardware can largely compensate for the short board of software. But the progress of hardware can not hide the lack of software, this is also the beginner's mind of this article.

Mobile-focused Essentials

In program development, testing is essential. Mobile testing can be divided into white-box and black-box testing by large types.

White-box testing is typically done by developers using coding. The tester needs to touch the internal code of the program, while black-box testing can be done without knowing the internal structure and code of the program.

The following are the main test procedures:
Smoke testing: In software testing, smoke testing refers to the ability to quickly verify the main functions of the app (e.g., login, exit, send messages, etc.). If no problems are found, then more in-depth testing is done, and if a problem is found, the app has a major flaw.

Functional testing: Functional testing is also called behavioral testing, and it is necessary to verify that the expected functionality of the application is implemented according to the test case.

Free Exploratory testing: Try the boundary conditions, enter special symbols, abnormal network environment, abrupt interruption of the program and other operations. The purpose of functional testing is to verify that normal functionality is not implemented, and that the purpose of the free exploration test is to try out the application in the extreme operation of the problem will not occur. Exploratory testing is about finding actions that can make an application go wrong.

Regression testing: Re-test a case for an application that was previously tested with our service.

Some of the metrics that the mobile side focuses on
How many hours of running do not crash;
Open the page multiple times to control the crash rate;
Interface optimization, how to make users not impatient, not irritable;
The server does not return data, whether it will lead to collapse;
Network is not good, the data came too slow, the interface is not smooth;
The data read from the database is too slow how to resolve and so on.

Mobile interface should have its own logic, the need for network data, there should be a default value, so that the network data is not returned, so that users have data to see. The network data received should be refreshed to the interface in some way instead of waiting for the data to be returned before the page is refreshed. When there is no network data, the interface should be able to self-contained, go through the flow, not strongly dependent on the network data.

Debugging in a weak network mode is a must for us, because we have to consider the user's implementation environment is usually not very good. Save frequently used data to the cache, improve the running efficiency of the app, the level of interface flow. At the same time, we need to have the ability to collect crash logs, so as to better reduce crashes and improve the user experience.

Causes and solutions of the interface lag

iOS interface processing is carried out under the main thread, the System Graphics Service informs the App,app main thread to start to calculate the display content in the CPU, such as view creation, layout calculation, picture decoding, text drawing, etc. through Cadisplaylink mechanism. The CPU then submits the computed content to the GPU, which is transformed, synthesized, and rendered by the GPU. The GPU then submits the rendered result to the frame buffer, waiting for the next refresh signal to appear on the screen. The display is usually refreshed at a fixed frequency, and if the CPU or GPU does not complete the content submission during a refresh time, the frame is discarded, waiting for the next opportunity to appear again, while the display retains the previous content. This is the reason for the interface lag. No matter which CPU and GPU block the display process, it will cause the frame to drop.

The CPU is consumed by the following types of resources:

• Object creation
• Object adjustment
• Object Destruction
• Layout calculation
• AutoLayout
• Text calculation
• Text rendering
• Drawing and decoding of pictures

There are several scenarios for GPU resource consumption:

• Rendering of textures
• Blending of views (composing)
• Generation of graphs, etc.

Refer to this article for details

Use Instruments to test your app

Time Event Viewer-time Profiler
In the Xcode menu, choose Product->profile
We will see the following interface:

Instruments

Click Time Profiler to enter.

Time Profiler

Let's delve into the following control Panel:

Control Panel

The following configuration options are described below:

1. Separate by thread: each thread should be considered separately. Only then can you find the "heavy" threads that are heavily CPU intensive.
2. Invert call Tree: From the top down the trace stack, which means that the method you see in the table will have been sampled from frame No. 0, which is usually what you want, so you can see the most time-out method in the CPU. That is, funca{funb{func}} Tick the stack with c->b-a to show the deepest C at the outermost level of the call.
3. Hide System Libraries: Check this to show your app's code, which is very useful. Because usually you only care about the time the CPU spends on its own code is not on the system.
4. Flatten recursion: A recursive function that tracks one entry per stack.
5. Top Functions: The sum of the time that a function spends directly in the function, and the total time it takes for the function to call the function. Therefore, if function A calls B, then A's time is reported in a time spent plus B. This is really useful, because it allows you to pick the maximum time number to go to the call stack each time, zeroing in on your most expensive method.

Find the most time-consuming process in the Detail panel, click to see the code, observe whether there is a different, so you can gradually optimize the operation of the application effect.

Modify

After modification, rerun the application in the Instrument product-profile (or? I remember that these shortcuts will really save you some time.
Distribution Tools

Distribution Tools
Click to enter

This time you will find two tracks. One is called (assigned) allocations, and one is called VM Tracker (virtual machine tracking).

There are two types of leaks in memory leaks. The first is a true memory leak, an object that has not been released, but is no longer referenced. Therefore, the memory cannot be reused. The second type of leakage is more troublesome. This is called "unbounded memory Growth". This occurs when the memory continues to be allocated and never has the opportunity to be released. If this goes on forever your program will take up an infinite amount of memory and will be killed by the system's watchdog when it exceeds certain memory.

Memory warnings are the best way for iOS to process apps, especially when memory is getting tighter, and you need to clear some memory. Memory growth is not necessarily a problem with your code, or it can be caused by the Uikit system framework itself.

Try

See for yourself, it's all natural and clear.

Memory leaks
This type of leak is mentioned earlier-the kind that occurs when an object is no longer referenced, the detection leak can be understood as a very complex thing, but the leaking tool remembers all the objects that have been allocated, by periodically scanning each object to determine if there is anything that cannot be accessed from any other object.

Turn off the instrument, go back to Xcode and select Product->profile

Memory leaks

Click to enter, run:

Run

Try it yourself, find the right panel, and if there is a black logo method, enter to see. To learn is to try more.

Limited space, more content we'll talk about it next time.

Wen/Wu Bai (Jane book author)
Original link: http://www.jianshu.com/p/f4adce56166f
Copyright belongs to the author, please contact the author to obtain authorization, and Mark "book author".

How to write a stable and smooth iOS mobile app