跳至主要内容

[Skill]慎用onBackPressed()

慎用onBackPressed()

Android中在按下back键时会调用到onBackPressed()方法,onBackPressed相对于finish方法,还做了一些其他操作,而这些操作涉及到Activity的状态,所以调用还是需要谨慎对待。

问题描述

最近公司的项目在Bug统计当中,发现了一大堆IllegalStateException的报错:
java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
    at android.support.v4.app.FragmentManagerImpl.checkStateLoss(Unknown Source)
    at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(Unknown Source)
    at android.support.v4.app.FragmentActivity.onBackPressed(Unknown Source)
    at android.view.View.performClick(View.java:4768)
    at android.view.View$PerformClick.run(View.java:19692)
    at android.os.Handler.handleCallback(Handler.java:739)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at android.os.Looper.loop(Looper.java:135)
    at android.app.ActivityThread.main(ActivityThread.java:5539)
    at java.lang.reflect.Method.invoke(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:372)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:960)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

问题解决

在Activity已经保存了状态以后(onSaveInstanceState)进行了Fragment退栈操作(popBackStackImmediate),触发方法为调用了onBackPressed方法首先我们翻API 24的源码来看看onBackPressed里面到底都干啥了:
/**
 * Called when the activity has detected the user's press of the back
 * key.  The default implementation simply finishes the current activity,
 * but you can override this to do whatever you want.
 */
public void onBackPressed() {
    if (mActionBar != null && mActionBar.collapseActionView()) {
        return;
    }

    if (!mFragments.getFragmentManager().popBackStackImmediate()) {
        finishAfterTransition();
    }
}
果然,onBackPressed首先去关闭ActionBar的展开菜单(collapseActionView),其次再对FragmentManager进行退栈操作(popBackStackImmediate),最后才关闭Activity,低版本直接调用finish,高版本调用finishAfterTransition。而当Activity处于onSaveInstanceState状态之后时,调用onBackPressed报错,其实在Activity处于活动状态下时是没有任何问题的。个人习惯通常把Toolbar与onBackPressed方法捆绑起来:
/**
 * 设置Toolbar 为ActionBar
 * @param toolbarId Toolbar资源ID
 */
public void setSupportActionBar(@IdRes int toolbarId) {
    Toolbar mToolbar = (Toolbar) findViewById(toolbarId);
    if (mToolbar != null) {
        setSupportActionBar(mToolbar);
        mToolbar.setNavigationOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                onNavigationClick();
            }
        });
        getSupportActionBar().setDisplayShowTitleEnabled(false);
    }
}

/**
 * Toolbar 返回按钮点击
 */
protected void onNavigationClick() {
    onBackPressed();
}
这里不存在问题,因为Toolbar的返回按钮必须得在Activity活动状态下才能点击到,而从代码层则需要通过遍历或者id找到到这个ImageButton再对其进行performClick操作(没有id,只能遍历),而真正问题出在于我将其写在网络请求结果处理的回调里面,毫无疑问,这就会出现Activity处于非活动状态了。

结论

  • 调用onBackPressed()方法需要注意Activity状态。
  • 调用onBackPressed()方法不一定就能结束Activity。
  • 调用onBackPressed()方法结束Activity,其调用的终究还是finish()方法。

评论

此博客中的热门博文

[Widget]StateFrameLayout-状态帧布局

StateFrameLayout icon 一般网络交互的状态提示及处理大多数情况下考虑使用Dialog,在一切状态处理理想状态下时,使用Dialog进行交互是可行的。但稍微一不注意,使用Dialog则会出现一系列隐藏的Bug。为节省用户时间怎加体验感觉,数据的载入可以在onCreate时候就进行,甚至可以在Activity构造函数里面启动网络请求,因为Activity还没有建立窗口(onAttachedToWindow),而Dialog必须附着在Activity的Window上,显然这时候不能弹出Dialog;网络交互并非即时,也就是在交互过程中用户可能进行任何操作,多数情况下,应用并不允许用户中断网络交互,而将Dialog设置为不可取消的话,用户体验是很差的,因为你同时阻止了用户退出当前Activity的操作,若用户仅仅是误点了进来,那么必须等待交互结束才能退出,而如果不讲Dialog设置为不可取消的话,那么用户进行了取消操作,但实际是并没有取消,这又会让用户很困惑,如果交互是更新当前页面的数据,当用户取消以后就可以进行旧数据操作,但其实这时候数据已过时,操作是不应该的;当网络交互已完成时,若交互结果需要告知用户时,此时又得注意Activity的状态,也许Activity已经关闭了Window(用户进行了返回操作,Activity在销毁;或者用户点按了Home键,设备内存不够,Activity在进行保存并关闭Window)。操控好Window,则使用Dialog并无任何问题,但是这就会怎加代码复杂度。其实我们的目的就是告知用户在进行网络请求,阻止用户对未载入或旧页面进行操作,网络交互结束后有必要时告知用户;使用StateFrameLayout则能轻松达到效果。 状态帧布局,通常用于网络请求的四种状态,普通、载入、错误、空白。支持Drawable或者View来展示,也可以混搭。 预览 screenshots 要求 minSdkVersion 4 链接 Github Bintray 使用 基本布局 < am .widget.stateframelayout.StateFrameLayout xmlns : app = " http://schemas.androi...

[Widget]Android小票打印,蓝牙打印、固定IP打印、黑白图片打印

Printer 标准ES-POS命令打印,固定IP或蓝牙打印,支持黑白图片打印 预览 screenshot printer_example 要求 minSdkVersion 5 <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.BLUETOOTH" /> 引用 dependencies { ⋯ compile ' am.util:printer:1.1.3 ' ⋯ } 详情 继承PrintTask来实现打印任务 继承PrinterWriter来实现更多纸张类型的打印 PrinterUtils包含了众多打印指令 使用 1.添加蓝牙权限 <uses-permission android:name="android.permission.BLUETOOTH" /> 或者网络请求权限 <uses-permission android:name="android.permission.INTERNET" /> 2.继承PrintTask类,实现具体打印任务: private class TestPrintTask extends PrintTask { public TestPrintTask ( BluetoothDevice device , int type ) { super (device, type); } public TestPrintTask ( String ip , int port , int type ) { super (ip, port, type); } @Override protected void onPreExecute () { super . onPreExecute();...

[Skill]多个开源项目Bintray一键发布环境部署

多个开源项目Bintray一键发布环境部署   我们发布到Bintray上共享的一般是一些库,而不是完整的App,而这些库是依附在我的主项目之中,如果我们主项目只维护一个共享库,那没什么问题,但维护多个开源库呢?不规划一下打包发布的流程,那么就会浪费我更很多的时间在打包发布上。截至至撰文时,笔者的ProjectX主项目已经管理维护者16个开源库,不规划一套打包方案,那么妥妥的能把笔者累死。 基础Plugin载入   需要实现自动化发包,就必须载入 gradle-bintray-plugin 与 android-maven-gradle-plugin (点击链接查看最新版本号,使用最新版本插件)。载入方式有两种: 传统方式 dependencies { classpath ' com.jfrog.bintray.gradle:gradle-bintray-plugin:1.7.1 ' classpath ' com.github.dcendents:android-maven-gradle-plugin:1.5 ' } 新型方式(Gradle 2.1) plugins { id " com.jfrog.bintray " version " 1.7.1 " id " com.github.dcendents.android-maven " version " 1.5 " }   使用新型方式导入的gradle-bintray-plugin会提交不成功,不知AS更新以后是否解决,但是笔者出错的版本是1.7.1,新版本没出来前gradle-bintray-plugin还是建议使用传统方式,android-maven-gradle-plugin可以选择新型方式。 部署方案 在库根目录(不是项目根目录)创建bintray.gradle文件,文件内容(可以直接拷贝给其他项目使用): apply plugin : ' com.github.dcendents.android-maven ' apply plugin : ' com.jfr...