foreword
I was on a whim today. I originally wanted to write an article and publish it on Jianshu, but what I didn’t expect was that he would not allow it. He said that according to the request of the competent authority, all user publications will be suspended until September 28th. Do you know this feeling? In fact, I wanted to post articles on csdn quite a long time ago, but I have never had time. I am a rookie-level Android development engineer who has just stepped into the society. The main purpose of writing an article is to record your own work experience. Without further ado, let's enter today's topic.
The current fragmentation of Android is actually quite serious. Since it is an open source system, each mobile phone manufacturer has its own Rom. The adaptation of each manufacturer is a big problem for a hard-working junior rookie Android development programmer like me. But what I’m talking about today is not about adaptation, hahaha, so what exactly is it that I’m going to talk about today?
What I said earlier can be regarded as nonsense, hahaha, what I want to talk about today is one of the positioning methods when encountering a bug that cannot be reproduced.
source of problem
I don’t know if you have ever encountered that the app developed was smooth to death on your own mobile phone, but as a result, customers had problems as soon as they used it. That's how I am now. When the company's App was running on my mobile phone, it started up very quickly, but in the hands of some customers, it became difficult to open. It takes more than ten seconds to display the main interface.
What a UX! ! ! !
Solutions
Not all mobile phones have problems, so first rule out code logic bugs. Most likely a third party issue. But we can't blindly solve it blindly. First of all, we have to find out where the problems occur. Whether it can be solved or not, we must first locate the location of these problems. (Actually, I was like a headless chicken at the beginning. I have been on Baidu how to improve the startup speed. What third-party initialization should not be placed in the main thread, etc.) Later, there was really no way. I consulted experienced people and learned about
a positioning problem. Method. Let's talk now.
To be honest, when your own mobile phone and the tested mobile phones have no problems, customers keep saying that the app is not easy to use. So, the positioning method is:
positioning method
First of all, you have to think about why this happens. There are several reasons for this:
1. The third-party framework may be stuck during initialization (the main thread is blocked by the network or other reasons)
2. The network is not good
3. Get local data something went wrong
...
Well, as soon as you open it, it must beOnCreatThere is a relationship in the method. After we understand the process inside, we can enter the focus of this article.
focus
You need a background server. If you know the background, write a small demo, which is mainly used to display the data uploaded by the App. What if there is no background? ? Baidu understands and realizes it by yourself. This is a method that can expand your knowledge. But this is time consuming. What should I do then? This is easy to handle, just ask your company's background for help, it is very simple to achieve this.
Then the background server Demo is ready, and we start to use the knife on the App. At the end of each initialization of the third-party framework, we upload the current mobile phone model, network status, remaining memory, initialized third-party information, and the most important completion time (in milliseconds). What? Don't know how to get these? This will be explained in detail in my next article. In this way, when you build a test app for users to open, you will know which step is the culprit for the slow entry through time comparison. It is useless to say more, let me give a chestnut:
/**
* 初始化极光推送SDK
*/
JPushInterface.setDebugMode(true);
JPushInterface.init(context);
//调用网络访问封装类，上传 Log 日志数据
new MyLibraryLogAPI().uploadLog("initApp", "App", LogTestUtils.produceLogMsg(this, "极光推送初始化"), 1);
LogTestUtils.produceLogMsg(this, "Jiguang push initialization") This is to get the value I need, as follows:
public static String produceLogMsg(Context context,String problemSite){
String logMsg=null;
logMsg="调试哪个步骤造成卡顿：" +
" 当前手机：" + getDeviceBrand()+" "+getSystemModel()+
" 时间:"+getLogTimeString() +
" 本机总内存大小：" +getTotalMemory(context)+
" 当前可用内存大小：" +getAvailMemory(context)+
" 网络状态：" + getAPNType(context)+
" 停留的定位："+problemSite;
return logMsg;
}
At this point, the operation of the App is finished, isn’t it very simple? The main reason is that the background is a bit difficult to deal with. Hahaha
When we compile the app and test it on the mobile phone, the background server will print the data we uploaded, and attach the background result map.
In this way, the initialization is clear at a glance. We only need to package it to the customer and ask him to open the app, and we can locate where the problem is! !
Careful friends may find that the result graph I gave seems to be quite normal, and each initialization is completed in milliseconds. That's right, there is really no problem, because I haven't located where the problem is yet, hahahaha, at least now I can know that the problem with the customer is not initialized by a third party, and the next step will be in network and local data acquisition position.
Summarize
This is a method of problem positioning, and there must be other better methods, because I firmly believe in one sentence: There are always more solutions than difficulties, and everything is possible!
Code words are not easy, please like and follow. It is also my first formal article, if there are any mistakes, please criticize and correct them. ??
In the end, a divine map came to the bottom.
