跳至主要内容

[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]ShapeImageView-图形裁剪ImageView

ShapeImageView 图形裁剪ImageView,API 21 及以上 使用 setOutlineProvider 方式实现,支持动态图;以下使用 BitmapShader 方式实现。 支持固定高宽缩放比缩放,支持前景Drawable,支持ImageView的所有ScaleType,且API 21具备更高性能。 预览 要求 minSdkVersion 4 链接 Github Bintray 使用 基本布局 < am .widget.shapeimageview.ShapeImageView android : id = " @+id/siv_image_c " android : layout_width = " match_parent " android : layout_height = " wrap_content " android : layout_margin = " 5dp " android : layout_weight = " 1 " android : clickable = " true " android : scaleType = " centerCrop " android : src = " @drawable/bg_welcome " app : sivBorderColor = " @color/colorAccent " app : sivBorderWidth = " 2dp " app : sivForeground = " @drawable/bg_common_press_dark " app : sivHeightScale = " 1 " app : sivScaleTarget = " height " app : sivShape = &q

[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

[Skill]URLConnection从HTTP重定向到HTTPS

URLConnection从HTTP重定向到HTTPS   也不知什么原因,公司项目的服务端一直在吸引着大波攻击,于是服务端的同学打算把所有HTTP的请求都换为HTTPS,他们决定兼容旧版本于是就将之前的所有HTTP请求全部重定向到另一个HTTPS请求。 项目请求框架搭建初期,考虑到应用也不会使用太复杂的请求模式,于是就简单使用URLConnection完成服务端交互。服务端一修改,全部请求都失败了。虽然URLConnection有是否遵循重定向开关(setInstanceFollowRedirects),其默认就是开启的,即便你再强制其打开,也是没有用,问题依旧。找了大量资料,其实问题的关键点不是重定向而是从HTTP重定向到HTTPS,关键点就在URLConnection的两个子类上。 HttpURLConnection与HttpsURLConnection   HttpURLConnection为URLConnection的子类,而HttpsURLConnection为HttpURLConnection的子类,在HttpURLConnection基础上对HTTPS进行支持。 URLConnection通常使用URL的openConnection()方法获得,而URL是根据其是否为Https开头来打开一个HttpURLConnection还是HttpsURLConnection。 而当URLConnection进行connect()时,遇到了重定向,如果打开了遵循重定向,那么其会获取重定向的地址,然后尝试连接这个地址。值得注意的是,这时候并不是使用新的链接地址重新openConnection()一个URLConnection,而是直接尝试连接这个重定向的地址,否则也就不存在以上的Bug了。 于是理论上分析,HTTP重定向到HTTP是不存在问题的,HTTPS重定向到HTTPS也是不存在问题的,而HTTP与HTTPS之间的重定向,那么就很可能会有问题了。HTTP重定向到HTTPS,URLConnection会将重定向的HTTPS以HTTP方式继续提交,那么服务端肯定是认为你是错误的提交方式;同理,HTTPS重定向HTTP也一样。 问题解决 使用URLConnection抓取到重定向,就使用重定向的地址重新人为openConnection()一个新