Understand these three reasons that slow down mobile applications before solving the problem

【51CTO.com Quick Translation】Generally speaking, the slowness of software application services is mainly manifested in two aspects: one is the delay in loading pages, or the long wait for the establishment of UI (user interface); the other is related to UX (user experience), including interface buttons that fail to respond as expected, or users find that various default gestures, actions and animations do not work. Obviously, both of these will affect the user experience. In this article, I will discuss with you the main reasons for the slowness of applications and how to solve them through a cross-platform application framework.

[[267502]]

Cross-platform vs. native

In daily R&D, people often have prejudices against cross-platform technologies, believing that since they are not native but network-based, their overall efficiency will be slower and, of course, they are bound to make mistakes.

However, they don't know that nowadays, the functions that native architecture can achieve can basically be achieved by cross-platform application frameworks, and the operating efficiency between them usually depends on how users implement their program codes. In actual projects, we often see some teams using Swift/Java to develop slow and frequently crashing native applications; while other teams can use cross-platform technologies such as Titanium to develop smooth products.

In addition, there is no need to use hybrid cross-platform tools, the cross-platform framework itself can generate a truly native UI. Therefore, as a native application developer, the problems you have encountered in the past, such as memory leaks, have been completely solved in most cross-platform frameworks today, and they can assist developers in implementing most of the heavyweight loading tasks.

It can be seen that only by understanding the limitations of the framework you use is the key to avoiding slow applications. Below, I will try to analyze with you the reasons why cross-platform applications run slowly or even unresponsive on mobile devices, and help you find various ways to speed up. As a code example, I chose Titanium as the framework. Of course, these improvement tips are also applicable to other types of frameworks.

Reason 1: Design

Usually, when developing cross-platform applications, the development team tends to combine the versions of the two major platforms into one. This design concept is precisely one of the fundamental reasons why the application becomes slow after running for a long time.

First, you need to understand that the default UI and (more importantly) UX for different platforms are very different. For example, iOS configures open/close animations and slide gestures for each window "stack". Although these may seem insignificant, the triggering of animations can give users an interactive experience. The idea of ​​"letting users switch between different pages in the window stack by sliding their fingers on the phone screen" buffers the jump time. Users will not intuitively experience the slowness that may be encountered when clicking the back button.

Therefore, when designing a different appearance for a form, developers should consider whether to use the native display effect. If you want to customize it, then the developer needs to use an event listener to capture whether the user slides the finger on the screen and then close the corresponding form. Otherwise, the sudden disappearance of the animated gesture will make the user feel the decline of the entire UX, and then feel that the application is slow.

In addition to the above-mentioned differences in animation effects and UI, developers should also pay attention to the garbage collection issues of cross-platform frameworks to prevent memory leaks in custom UIs during operation.

At the same time, with the widespread use of users and the improvement of mobile device hardware performance, they will set more custom gestures and shortcuts, and your mobile application needs to capture, track and calculate more finger trajectories. Therefore, you will find that data loading and calculation blocking will affect each other and form a vicious circle. As a result, some applications have lost their maintainability and usability after one year of launch, and the development team has to rewrite and refactor the program.

Solution

First, during the design phase of the application, we should fully understand and accept the differences between the platforms. By designing products for the two systems, we can find out what users of different platforms expect from the interface and effects. Within the company, you can invite people who have been using Android phones and iPhones for a long time to conduct actual tests on various usage effects.

Secondly, use the built-in UX/UI features to try to implement various functions on the application interface from the perspective of the native platform. For example, in most iOS applications, buttons are generally placed on the left and right sides of the title; while Android versions usually place buttons on the right or hide them directly inside the menu icon. In addition, Android applications have a built-in back button, while iOS has a return gesture. By supporting these features based on different mobile platforms, users can intuitively understand your application and have a certain sense of identity.

Category 2: Too much loading

Another major reason for slow applications is that there are too many elements loaded at once in the UI. After all, the performance of mobile devices is not as good as that of users' computers, and it is difficult to handle multiple tasks at the same time. Moreover, not everyone can use the latest version of iPhone and high-end Android devices. There are also many users who are still using Android 4.4. Therefore, in order to stand out in various app stores, your mobile product should have the ability to still have good performance on low-end configuration and old version devices.

For example, in the iOS App Store, if you click and select the "Today" tab, it will quickly load five app tabs. Then, when you slide down, please pay attention to the position and size of the scroll bar. You will find that the scroll bar will slide to the bottom of the screen with its original size, and when it is close to 20% of the bottom of the screen, it will quickly shrink or even bounce back to a position above. The screen will begin to display the data of the "second page".

It can be seen that the app store does not load all the data at once. Therefore, in the design and construction of actual applications, we should ask ourselves: When we let users see the pushed content for the first time, do we also load the subsequent content? Do you perform delayed loading for images? Among the pre-loaded data, how many should be displayed in the ListVIEW? 100 items or 200 items? How many APIs do you need to call when the application starts? I have seen the post "How to call 50 APIs most effectively when the app starts" and the message "How to effectively load 10,000 messages in ListVIEW" in the TiSlack forum.

My answer is: "Don't do it!" No one can view so many messages at once. If you want users to be able to scroll through the list, use lazy-loading and paging, even if the data is stored locally on the device. And if you want users to search? Then push the data to the user's device after the server completes the search locally.

Solution

From the example of Apple App Store above, we can understand that the data content is loaded after the application is opened by ***. For example, in the default TabGroup:

...

Additionally, I added a postlayout event listener to the form for the home page tab. The function calls the form's initializer, after getting the relevant data for the tab, before loading it. By waiting for the postlayout event, you can ensure that the user does not see the loading page, but the normal application content. Here is a simple function for lagging the initialization content - handlePostlayout:

 function handlePostlayout() { $.todayWindow.add ( Alloy.createController( 'todayContent' ).getView() ); }

As you can see, in the Today tab, the actual requested content and its dependencies are not initialized or loaded right away, which undoubtedly speeds up the overall performance of the application.

At the same time, for other tabs, we can monitor the "focus" event of the screen form and load it only when the form is focused. Similarly, you can also use this event to refresh the data in time when the current form is focused again; and apply it to Firebase Analytics (Android integrated tracking analysis).

Remember: Compared to reinitializing the entire page using paging or lazy loading, downloading only the data is lighter, faster, and saves CPU computing power.

Reason 3: Bridge

The "bridge" here is a concept that comes from cross-platform frameworks such as Titanium and React Native. It means that every interaction between JavaScript code and native code will incur overhead. For example, when you make an API call on the server, it is obvious that we would rather call the API once and retrieve 100 pieces of data at a time than calling the API 100 times and retrieving only 1 piece of data each time.

So what is "bridge"? In fact, we will generate calls when adding UI elements, updating UI elements, and triggering animations. For example, the Ti.App.fireEvent flow in Titanium requires the concept of bridge. This type of event is usually used to trigger certain operations in the application to achieve initialization. In addition, this type of event will also trigger the update of the UI. Therefore, one event may trigger two bridges.

Then when all these things happen at the same time, especially in a loop-triggered state, the bridge process will become "overcrowded". If the bandwidth capacity of the bridge is relatively "narrow", your application will experience large-scale delays and even interruptions, which will directly affect the user experience.

Solving this problem is actually very simple. You just need to batch the UI together. So when you need to modify the entire table of ListTimes, you can use ListTeal.RePateTimeSt to easily reinsert the entire data set at once. And when you need to change a group of properties of a UI element, you can use applyProperties without changing the specific order of each property.

At the same time, you can use Backbone Events to trigger various events throughout the application without having to use a bridge. Moreover, it is easy to migrate the current various Ti.App events to Backbone Events.

As shown below, we first include Backbone Events into alloy.js.

 Alloy.Globals.events = _.clone(Backbone.Events);

Then, replace any places in your application where Ti.App.fireEvent() is used with the following function:

 Alloy.Globals.events.trigger () ;

Then, in the same way, you can continue to replace Ti.App.addEventListener() with:

 Alloy.Globals.events.on ( )

You can even perform a global search and replace on your projects for immediate performance improvements.

in conclusion

In summary, there are many reasons that slow down mobile applications, most of which are related to inefficient code implementation. Therefore, we should try to use native UI components, load as little data as possible, and reduce the number of bridges. Finally, I reiterate: cross-platform frameworks are not destined to be slower than native applications. In fact, in various app stores, you will find that 95% to 99% of applications (excluding game applications) are built using frameworks such as Titanium.

Original title: 3 Reasons Mobile Apps Can Be Slow, Author: Rene Pot

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]