Phonegap：关闭DroidGap活动后javascript计时器仍在运行

Question

I'm working in an Android WebApp using Phonegap. To exit the application, I'm calling navigator.app.exitApp from JavaScript code.

I tried to find the documentation page for this method, but it does not exist. Then I downloaded the Phonegap source code for Android, but I got lost without finding where and how does this library exit the app from native code. I've no time for this so I decided to test it on my own.

My app has a single DroidGap activity (launched with singleInstance flag), but also a Service and a Broadcast Receiver. The user must be able to close the GUI, but I'd like to keep the services and everything else running. So what I'd like to do is to finish only the activity, instead of calling System.exit .

Now here comes the odd part. I've tested this in a simulator and the DroidGap activity seems to close the way I want it to (onDestroy is fired) and the services are kept running. But, despite the activity is closed, and the app icon is no longer shown in the task manager, somehow a JavaScript timer is still running. I've triple-checked this. I'd like to believe the activity is in the background, but it can't be: it is launched as singleInstance, and when I open the app again it shows the initial page (it was closed in a different page).

Why does this happens? Should I code a plugin to directly call finish over the activity?

Thanks in advance.

Answer 1

I've been investigating this for a couple hours, so I'll post here my findings.

In every Android WebApp, not only Phonegap apps, whenever you have a WebView two threads are spawned: WebViewCoreThread and WebViewWorkerThread . They are shown in DDMS. I've been reading the Android sources and I've tracked the creation of this thread down to the WebViewCore.java file. Apparently only two threads per application process are started, and they are shared by every WebView in the app.

IMHO, the fact that using a View in a screen means spawning threads is very bad design. If this field needs to do things as complex as starting a thread, then it should have been better designed as WebViewActivity or WebWiewFragment instead. In any case, the class that creates the thread should also be responsible to finish it when it is no longer needed. This unfortunately is not the case.

When the activity containing the WebView is closed but the application process is still running (maybe because you have other components like services, or perhaps the OS has not killed it yet), these threads are kept running. The core thread will continue executing the timers you set in your app. When the activity is created again, the threads are reused.

As a side note, notice how this allows running javascript code in background without having to keep an activity displayed.

I tried some of the workarounds for a regular WevView exposed in this question: WebView threads never stop (WebViewCoreThread, CookieSyncManager, http[0-3]) ,

but for some unknown reason it does not work with Phonegap. I tried overriding my DroidGap subclass like this:

@Override
public void onDestroy(){
    System.out.println("Activity destroyed");

    if(appView != null){ //This is a protected reference to the `CordovaWebView`, extending `WebView`
        //First attempt
        try {
            Class.forName("android.webkit.WebView").getMethod("onPause", (Class[]) null).invoke(appView, (Object[]) null);
        } catch (Exception e) {             
            e.printStackTrace();
        } 

        //Second attempt
        appView.pauseTimers();          
    }

    super.onDestroy();
}

So what I finally did is to make sure all timers are cancelled from JavaScript code before exiting the app. However, one would expect this fixed in the Android OS code, or patched in Phonegap, because even in the best case these threads are wasting resources that really are not needed when there's no web page being shown. And in the worst scenario, some DOM related JavaScript code could crash.

Answer 2

You need to kill the timer explicitly, right before calling navigator.app.exitApp() . This issue is also discussed here .

Hope this helps...:)