正确使用Fragment之创建/传参??newInstance方法(native)

发布于:2021-11-27 13:10:08

说来忏愧,*来越发觉得写不出可分享的东西,更糟糕的是,甚至觉得可记录的东西都不多。
这实在是一个非常糟的信号??说明我开始逐渐把自己放在安全边际内了。
人若总是将自己畏缩在安全边际之内,不去做一些阵痛的改变,埋下的会是病来如山倒般的灾难种子。
好在,好在我还在不断的学*,只是但前处于一种较混沌的状态,需要踏出去更多一步。

今天来说一个简单的话题,找回一些状态。


关于Fragment,相信大家已经熟之不能再熟了。然而,

使用频率如此之高的Fragment,你的使用姿势,真的正确吗?

先对比一下两种使用姿势:
1.姿势A:

MyFragment mFragment = new MyFragment();
Bundle bundle = new Bundle();
bundle.putString("arg1", "a");
bundle.putString("arg2", "b");
bundle.putString("arg3", "c");
mFragment.setArguments(bundle);
getSupportFragmentManager().beginTransaction().replace(R.id.frame, mFragment).commit();

2.姿势B:

MyFragment mFragment = MyFragment.newInstance("a", "b","c");
getSupportFragmentManager().beginTransaction().replace(R.id.frame, mFragment).commit();


有没有,有没有觉得第二种姿势特别爽
接来下进入今天的正题,关于Fragment.newInstance()这个方法。


我先声明,其实第一种姿势没什么问题,(引用斯坦福白胡子老头一句话)”这只是代码风格的问题,但我不建议这么做。”


使用Android Studio新建一个Fragment就一切明了了:
我们看到,Studio默*镂颐谴唇ǖ腇ragment中,有这样一段代码:


// TODO: Rename and change types and number of parameters
public static BlankFragment newInstance(String param1, String param2) {
BlankFragment fragment = new BlankFragment();
Bundle args = new Bundle();
args.putString(ARG_PARAM1, param1);
args.putString(ARG_PARAM2, param2);
fragment.setArguments(args);
return fragment;
}

一个静态方法,返回我们创建的Fragment类本身,显而易见的是,这个方法帮我们做了姿势A中我们手写的方法。


再来关注看我们较少Override的方法onCreate(这里默认直接帮我们Override了)


@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (getArguments() != null) {
mParam1 = getArguments().getString(ARG_PARAM1);
mParam2 = getArguments().getString(ARG_PARAM2);
}
}


到这里,我们先捋一捋。姿势B的机理在于,通过传递参数给Fragment.newInstance()方法,它会创建一个该Fragment类,并通过创建Bundle把我们的参数代入。然后在onCreate()生命周期中,把参数拿回出来。(为什么这么做?是本文后半部分传参讨论的内容,先跳过),之后的事情大家都是熟手了,把参数拿来用就好。



为什么谷歌默认要使用这样一个工厂方式创建我们的Fragment呢?


既然newInstance()是父类Fragment的方法,我们跟进去一看究竟:


//可以看到这是一个native方法
public native T newInstance() throws InstantiationException, IllegalAccessException;

题外话:关于native方法: native关键字说明其修饰的方法是一个原生态方法,方法对应的实现不是在当前文件,而是在用其他语言(如C和C++)实现的文件中。Java语言本身不能对操作系统底层进行访问和操作,但是可以通过JNI接口调用其他语言来实现对底层的访问。


就感觉线索断了一样,这是要往下去读C/C++啊,抛开底层机理不知,不说,姑且猜测为,二者完全是一样的方式,只是姿势B封装了一点内容,让Fragment的宿主Activity更加整洁一些,仅此而已。



既然如此,我们转为本文的下半部分,关于传参。


想过吗?Fragment作为java类
为什么传参需要用Fragment.setArguments(bundle)这样的方式,
而不通过构造函数直接传递new Fragment(arg1,arg2);


实践出真知,其实在大多数时候,这两种方法传递参数都是没有问题的。
但是,但是当某些情景发生,一切就不一样了。(比如竖屏切换横屏时),切换到横屏时,构造方法传递的参数就找不到了。


原因很简单,因为Fragment是有自己封装的生命周期的,这一点和Activity类似,Activity传参也不是用构造方法的方式。
但是究竟生命周期对构造方法传递参数有什么影响呢?


源码中一探究竟:


在Fragment中,是通过Bundle来保存参数的,它的私有声明在此:


Bundle mArguments;

顺着这个声明的命名mArguments找下去,发现其实相关的主要方法并不多:


public FragmentState(Fragment frag) {
...
mArguments = frag.mArguments;
...
}

public void setArguments(Bundle args) {
if (mIndex >= 0) {
throw new IllegalStateException("Fragment already active");
}
mArguments = args;
}

final public Bundle getArguments() {
return mArguments;
}

这三个比较简单,就不说了


public Fragment instantiate(FragmentHostCallback host, Fragment parent,
FragmentManagerNonConfig childNonConfig) {
if (mInstance == null) {
final Context context = host.getContext();
if (mArguments != null) {
mArguments.setClassLoader(context.getClassLoader());
}
mInstance = Fragment.instantiate(context, mClassName, mArguments);

if (mSavedFragmentState != null) {
mSavedFragmentState.setClassLoader(context.getClassLoader());
mInstance.mSavedFragmentState = mSavedFragmentState;
}
mInstance.setIndex(mIndex, parent);
mInstance.mFromLayout = mFromLayout;
mInstance.mRestored = true;
mInstance.mFragmentId = mFragmentId;
mInstance.mContainerId = mContainerId;
mInstance.mTag = mTag;
mInstance.mRetainInstance = mRetainInstance;
mInstance.mDetached = mDetached;
mInstance.mHidden = mHidden;
mInstance.mFragmentManager = host.mFragmentManager;

if (FragmentManagerImpl.DEBUG) Log.v(FragmentManagerImpl.TAG,
"Instantiated fragment " + mInstance);
}
mInstance.mChildNonConfig = childNonConfig;
return mInstance;
}

在instantiate()实例化过程中,可以看到
if (mArguments != null) {
mArguments.setClassLoader(context.getClassLoader());
}
也就是说,如果我们调用时使用setArguments()传递了Bundle,它会被保存在mArguments 这个私有声明中。
而如果是通过构造函数传递的参数,那很不幸,Fragment重建过程中,并没有持有相应参数的属性或方法,自然,你通过构造函数传递的参数就丢失了。


其实目前大家单纯无参new Fragment()的方式并没有错,只是可以让Activity更优雅的调用Fragment.newInstance(),
而如果涉及到传递参数,万不可通过构造函数传递,会丢失。


知其然,知其所以然


总结,Fragment.newInstance() ,别无其他,只是事关风格(代码”整”“洁”之道),建议大家以后均使用谷歌推荐的该方法

相关推荐

最新更新

猜你喜欢