When it comes to app optimization, we can also optimize it in many aspects, such as package size, page fluency, memory occupation, data cache, network data security, etc. to optimize and strengthen our app, there are many things to be done at each point. I wrote a blog about app performance optimization before, as follows:
IOS – things about performance optimization
At the mobile end, APP network optimization is also a very important point of APP performance optimization, and 99.99% of apps are accompanied by network interaction;
Here, I will make a detailed summary of APP network optimization and network security, mainly from the aspects of traffic, quality and security
Let’s talk about a personal experience. I developed an app in a company before. A little customer service feedback showed that an old man in Shanghai called to curse people. Our app was installed on the mobile phone, and one or two G’s were used in one night; Later, the company also took the initiative to help others bear this part of the traffic charges. The key is that the 15 year traffic charges are still very high. Of course, this app is not written by me, it’s an Android partner!
Even if the price of traffic is not very expensive now, it’s very necessary to help users save money as much as possible!
Detection of flow consumption
I believe that when you develop the app, you will certainly do some buried points and log reporting functions. We can also monitor the network requests. We can detect the traffic consumption of users over a period of time, calculate the average and peak traffic, and report the traffic interface. We can record these in the log or buried point system, and then upload them to the server, Then data analysis is carried out to find out the deficiencies of traffic consumption.
When it comes to caching, it’s also a very big point. I can expand it when I have time. I usually talk a lot about caching in my blog. A very important advantage of caching is to improve the page loading speed and improve the user experience; But caching can also save the consumption of traffic for users.
The cache of app data is nothing more than the cache of list interface and WebView. I have also written about the cache of WebView separately, as follows:
IOS wkwebview cache and real time
IOS uiwebview cache and real time
We can also do resource package distribution, prefabrication, loading, etc., here is not expanded!
As for data compression, what I want to talk about here is data compression of resource files, mainly in terms of network upload and network download;
1. Data upload
For example, when uploading image data, do we need high-definition images of the original image? Now the pixels of the camera are all high. Can we compress the image or video and upload it again? For example, when sending images on wechat, users can choose to compress or upload the original image;
2. Data download
At present, downloading is also the big head of app. Generally, APP requests to download more data; When we load resources, we can choose to load compressed resources, such as wechat’s circle of friends, when we load small images, we can load thumbnails, if we click to view large images, we will consider loading large original images;
If the data interaction is frequent, it will consume the user’s traffic, and the user experience is not good. Another very important reason is that frequent network requests will also consume the power of the mobile phone; So we can merge some network requests that can be merged, such as when the log is reported.
In the process of app development, we usually make a network request as soon as we enter the page, and then wait for the end of loading data. But for example, the network request is relatively slow (the amount of data may be large, or the network condition may be bad), the user does not want to wait, and directly returns to the page for destruction, but most of our network requests are encapsulated separately, But the network request is still in the process of request. Here, the problems of data, performance, memory and power come out. So when you encapsulate the network request, you should consider the scenario of canceling the network request by destroying the page!
The speed of network requests is a very important reason for affecting the user experience, so the server should also think about improving the interaction speed of the API. Therefore, we can optimize the interaction speed through the following schemes, as follows:
a. Domain name merging reduces the number of DNS calls and the risk of DNS hijacking;
b. IP direct connection, remove DNS resolution steps;
c. API cache, such as redis cache;
d. Data resource compression and upload;
Monitor the quality and speed of network request, and then record the log to report to monitor the complete network request link;
The design of API should also consider the pressure of API and server to prevent the interface from hanging up because of too much pressure, which will affect the user experience;
When the server provides data to the app, it should avoid data processing or computing on the app. Compared with the limited memory and computing resources of the app, it should not waste app resources excessively;
For example, the user information of my last company contains the age of the user, but the server does not give the direct age data, but the birthday time stamp. The app needs to calculate the age by itself, but we know that
Nsdateformatter is also a major memory overhead object, which consumes memory when processing lists. Therefore, it is recommended that some things about computation should be calculated on the server side. This is not only a problem of ensuring app performance, but also a security problem!
Our network security problems on the app side are generally app packet capture, DNS hijacking and server security. The details are as follows:
When it comes to packet capture, intruders can choose to capture data to steal the key data of app, and then simulate requests to do things that are not easy for app to control. Here, we can use HTTP to make network requests, and we can also prohibit network requests from setting codes;
Can also request header and request body encryption transmission, one more guarantee!
But it needs to be pointed out that there is no absolute security, as long as it is designed by people, someone will design decryption, peep in the heart!
DNS hijacking, because in the process of domain name resolution to IP, the resolution is based on UDP protocol, so the message is in plaintext state, which may be monitored in the process of request. Then the attacker does some own processing, such as returning a fake IP address or doing nothing to make the request lose response. Its effect is that it cannot respond to a specific network or access a fake URL. The root causes are as follows:
a. Malicious attack, intercept the operator’s parsing process, embed their own illegal things in it.
b. For the sake of profit or other factors, operators allow some third parties to advertise in their own links.
How to prevent DNS hijacking?
Through the above I said IP direct connection, their own app resolution!
Recommend a more detailed article about DNS, as follows:
DNS Optimization Practice of APP network optimization
Server security can be viewed from physical security and network security
a. For physical security, the server should consider the security problems caused by power failure and network disconnection;
b. Network security, to prevent the server from being attacked, crawled and other issues;
Therefore, the server backup mechanism and data backup mechanism are very important, and the number and interval of requests for the same IP should be limited;
If there are any shortcomings, I hope you will give me your advice. You are welcome to join the group or call me QQ to discuss, exchange and study!