Preface
In Android development, WebView is often used to display WEB pages, launch your own browser in Activiry, or simply display some online content.
WebView can help us display html pages very well, but if the webview is used improperly, it may still cause certain problems. Let’s talk about my optimization skills in the following aspects.
1. Show the webview activity, you can open another process, so that it can be separated from the main process of our app. Even if the webview causes Oom crashes and other problems, it will not affect the main program. How to implement it? It is actually very simple. Add it to the activity tag.android:process=""That's it. When you run it, you will find that there is one more process, haha.
2. There are also tricks to create a webview. It is best not to use webview in it. You can use a viewgroup container to dynamically enter the container using code.addview(webview), this wayonDestory()Destroy the webview in time to clean the memory. In addition, you need to note that creating a webview requires the applicationContext instead of the activity context. When destroying it, you will no longer occupy the activity object. Everyone should know this. When you leave, you need to destroy the webview in time.onDestory()You should remove the webview from the viewgroup first, and then call it();();
create
ll = new LinearLayout(getApplicationContext()); (); wv = new WebView(getApplicationContext());
destroy
@Override
rotected void onDestroy() {
();
();
();
();
wv = null;
ll = null;
();
3. Further optimization. After the activity is passively killed, it is best to save the webview status, so that the user will see the previous status when opening it next time. Well, just do it. Webview supportssaveState(bundle)andrestoreState(bundle)Method, so it's simple, haha, look at the code:
Save status:
@Override
protected void onSaveInstanceState(Bundle outState) {
(outState);
(outState);
(TAG, "save state...");
}
Recovery status:
In activityonCreate(bundle savedInstanceState)Inside, use it like this:
if(null!=savedInstanceState){
(savedInstanceState);
(TAG, "restore state");
}else{
("");
}
A few more pitfalls
() . You can never be sure whether the webpage content is actually loaded when the WebView calls this method. This method may be called multiple times when the currently loading web page generates a jump. There is a more specific explanation on * (How to listen for a Webview finishing loading a URL in Android?), but the solutions listed are not perfect. So when your WebView needs to load various web pages and need to take some actions when the page loads, it may()Compare()All need to be more reliable.
WebView background power consumption problem. When your program calls WebView to load a web page, the WebView will start some threads (?) by itself. If you do not destroy the WebView correctly, these residual threads (?) will always run in the background, which will cause your application to consume a lot of power. The way I used to deal with this is lazy, simple and rough (not recommended), that is,()Call directly in(0) , so that the application is completely removed from the virtual machine, so there will be no problems.
Switching the WebView splash screen problem. If you need to switch back and forth between different WebViews (including different web page content) in the same ViewGroup, you will find that splashing is inevitable. This should be a bug in Android hardware acceleration. If you turn off hardware acceleration, it will be much better, but you cannot get a good browsing experience. You will feel that when the web page slides, you will not follow the action.
Data accumulation problem. Turning on cache is beneficial to the browsing experience of web pages, but you will find that even if you clear the necessary content, such as Cache, Cookies, Form Data, History, Password, etc., the storage space occupied by your application will still increase and increase. In the end, you have to manually clear the data from the application information interface set by the system:(
Scrollbar issue. The horizontal scroll bar of Android System WebView is so thick?
On some mobile phones, when the Webview has videos, the video resources are not destroyed after the activity is destroyed, and you can even hear them playing in the background. Even destroying webviews in various ways like before is useless. The solution is: modify the url to an empty address before onDestory. Isn't it a scam?
Summarize
The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support.