Imagine you come to a company for a job and find yourself on the Facebook app development team. Your first task concerns the feed. A feed is an endless list of content: the user scrolls through it, reaches the end, new content is loaded here, and so on to infinity. Technically, the ribbon is a UITableView. And the problem is that the ribbon is slow. You need to speed it up.

What will you do as a developer: first, second, third to solve this problem?

Solution

First, let’s check if the developer understood the task itself. The word “slow” can mean a lot of things. It can mean different things to the user and the developer. If the developer doesn’t check for proper understanding, he can solve a completely different problem. So, the first question I expect the developer to ask is, “What does it mean to slow down?” “Slow” can mean both that the user expects the application to do some operation faster, or that the interface is “laggy,” that is, it responds to user actions intermittently. Technically, these are completely different things, and they need to be handled differently.

Next. Consider the braking.

Slowness can occur if:

• something is slow in the application;
• something is slow outside the application, but the application is waiting for a result;
• there are blockages in the process;
• all of the above.

If something in the application is slow, how do you know what it is? The surest solution is to use a profiler. We then discuss with the candidate the most frequent causes:

• Incorrect UITableViewCell reuse;
• heavy cell constructor or configurator;
• heavy logic calculations in the main thread;
• picture conversion, JSON parsing, and other nonsense.

It’s not uncommon for candidates to just guess and offer expensive solutions at random in terms of implementation and support. For example, most want to throw out Autolayout and rewrite it on the frame themselves. And now many people consider it to be a silver bullet, although there are a lot of cases where it won’t fit or won’t help.

If it slows down outside of the application, it could be the network. Here it is necessary to look at the requests: the number, frequency, server response size, response time, the presence and size of the cache. You can play with the channel width, HTTP version and look in this direction.

If we consider blocking, for example, the application may not cache data but make a blocking request to the server every time it goes to the beginning of the feed. The user has accessed the page and always sees the load indicator spinning. It gives the impression that the application is slow, because you always have to wait. There can also be an interesting issue here if the application is doing a large operation consisting of many asynchronous operations. And the user gets a wait with an indicator after each click on any button. Each of them can last a second, but if after each sneeze the application hangs for a second, after 6-7 such operations there is a dense feeling of lags.

Consider lags. This is a narrower case, which can be treated by unloading the main thread and taking heavy things into secondary threads. This is a good place to discuss synchronization tools for threads, what code should and should not be moved to where and why.