android - Release resources in onPause instead of onDestroy -
this post-honeycomb (i.e., android 3.0+) , quotes below come https://developer.android.com/reference/android/app/activity.html
according lifecycle, onstop , ondestroy killable, means:
note "killable" column in above table -- methods marked being killable, after method returns process hosting activity may killed system @ time without line of code being executed
in other words, onstop (along others occur before event) guaranteed called, yet @ moment method returns, process might die, ondestroy not guaranteed called.
another quote states:
for methods not marked being killable, activity's process not killed system starting time method called , continuing after returns.
followed by
thus activity in killable state, example, between after onpause() start of onresume().
but not correspond said above, unless corresponds pre-honeycomb. not true post-honeycomb, right? basically, both onpause , onstop guaranteed called.
assuming release resource in ondestroy, might lead possible leak since ondestroy might not called, right?
however, can scenario (i.e., ondestroy not called) occur besides when process killed android itself? there other scenarios cause ondestroy not called, thus leaking resource.
is true when android kills process resources destroyed , no leak can occur (even when did not explicitly released resource?).
please provide detailed information whether statements (1) (2) (3) (4) (5) correct or not.
first of let's understand what's going on documentation quoted.
the following commands show git blame output of activity.java file in aosp:
$ cd $aosp/frameworks/base $ git blame ./core/java/android/app/activity.java the relevant part of output:
9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 363) * <p>note "killable" column in above table -- methods 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 364) * marked being killable, after method returns process hosting 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 365) * activity may killed system <em>at time</em> without line 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 366) * of code being executed. because of this, should use 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 367) * {@link #onpause} method write persistent data (such user edits) 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 368) * storage. in addition, method 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 369) * {@link #onsaveinstancestate(bundle)} called before placing activity 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 370) * in such background state, allowing save away dynamic instance 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 371) * state in activity given bundle, later received in 550116576 (roboerik 2014-07-09 15:05:53 -0700 372) * {@link #oncreate} if activity needs re-created. 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 373) * see <a href="#processlifecycle">process lifecycle</a> 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 374) * section more information on how lifecycle of process tied 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 375) * activities hosting. note important save 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 376) * persistent data in {@link #onpause} instead of {@link #onsaveinstancestate} 5c40f3fcc (daisuke miyakawa 2011-02-15 13:24:36 -0800 377) * because latter not part of lifecycle callbacks, not 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 378) * called in every situation described in documentation.</p> 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 379) * 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 380) * <p class="note">be aware these semantics change between 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 381) * applications targeting platforms starting {@link android.os.build.version_codes#honeycomb} 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 382) * vs. targeting prior platforms. starting honeycomb, application 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 383) * not in killable state until {@link #onstop} has returned. 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 384) * impacts when {@link #onsaveinstancestate(bundle)} may called (it may 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 385) * safely called after {@link #onpause()} , allows , application safely 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 386) * wait until {@link #onstop()} save persistent state.</p> 0aae2d4e0 (dianne hackborn 2010-12-07 23:51:29 -0800 387) * 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 388) * <p>for methods not marked being killable, activity's 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 389) * process not killed system starting time method 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 390) * called , continuing after returns. activity in killable 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 391) * state, example, between after <code>onpause()</code> start of 9066cfe98 (the android open source project 2009-03-03 19:31:44 -0800 392) * <code>onresume()</code>.</p> note paragraph discusses post-honeycomb behavior added dianne hackborn on 2010-12-07, whereas enclosing paragraphs date 2009-03-03.
what tells dianne added new paragraph without updating rest of javadoc, therefore contradiction. unfortunately, not rare in android.
to questions:
1) on post-honeycomb versions of android both onresume() , onstop() guaranteed called (as stated dianne hackborn in addition activity's javadoc).
2) on pre-honeycomb onpause() guaranteed called (as stated earlier version of activity's javadoc)
3,4,5) ondestroy() not called if process hosting entire application killed. when process killed, resources allocated freed, therefore there no risk of memory leak in case.
important note: since releasing resources in ondestroy() not cause memory leak, might idea put "releasing" code there. however, optimal approach. why? read below.
when activity goes background stopped, not destroyed (usually). activity can remain in "stopped" state quite long time, , started again if user returns application. if release resources in ondestroy(), not called default when activity goes background, activity hold these resources while in stopped state, causing higher amount of resources consumed app in background state.
when android runs out of memory, starts killing processes in order free memory consumed them. 1 of important considerations taken account when choosing processes kill resource consumption. thus, if app holds resources while in background stopped state, have higher chance of being killed android.
in addition, we, developers, must make sure make best apps our users. application consumes non-minimal amount of user phone's resources , battery while in background not application. , users know it!
therefore, advice releasing resources in onstop() method. don't overwrite ondestroy() methods in activities , fragments @ all.
corollary: pointed out @juan in comment, above important note has equally important, not evident corollary: onstart() should method in resources being allocated. whatever definition of "resources" is, neither oncreate() nor onresume() should allocate these resources.
Comments
Post a Comment