使用newInstance()来实例化fragment并传递数据操作
好问题。答案就是这篇文章的题目所建议的，这是一种合理的设计。在这种情况下,newinstance()方法是一种“静态工厂方法",让我们在初始化和设置一个新的fragment的时候省去调用它的构造函数和额外的setter方法。
为你的fragment提供静态工厂方法是一种好的做法,因为它封装和抽象了在客户端构造对象所需的步骤。
例如,考虑下面的代码:
不要让客户端去调用默认的构造函数，然后手动地设置fragment的参数。我们直接为它们提供一个静态工厂方法。这样做比调用默认构造方法好，有两个原因：一个是，它方便别人的调用。另一个是，保证了fragment的构建过程不会出错。通过提供一个静态工厂方法，我们避免了自己犯错--我们再也不用担心不小心忘记初始化fragmnet的参数或者没正确设置参数。
总的来说，虽然两者的区别只在于设计，但是他们之间的差别非常大。因为提供静态工厂方法有向上抽象了一个级别，让代码更容易懂。
译者注：
其实提供静态工厂而不是使用默认构造函数或者自己定义一个有参的构造函数还有至关重要一点。fragmnet经常会被销毁重新实例化，android framework只会调用fragment无参的构造函数。在系统自动实例化fragment的过程中，你没有办法干预。一些需要外部传入的参数来决定的初始化就没有办法完成。使用静态工厂方法，将外部传入的参数可以通过fragment.setargument保存在它自己身上，这样我们可以在fragment.oncreate(...)调用的时候将这些参数取出来。
传递数据
在fragment 的oncreatview里获取数据
@overridepublic view oncreateview(layoutinflater inflater, viewgroup container, bundle savedinstancestate) { // inflate the layout for this fragment view myview = inflater.inflate(r.layout.xxx, container, false); string args = getarguments().getstring("name"); return myview;}
在activity里
补充知识：正确使用fragment之创建/传参——newinstance方法（native）
说来忏愧，近来越发觉得写不出可分享的东西，更糟糕的是，甚至觉得可记录的东西都不多。
这实在是一个非常糟的信号——说明我开始逐渐把自己放在安全边际内了。
人若总是将自己畏缩在安全边际之内，不去做一些阵痛的改变，埋下的会是病来如山倒般的灾难种子。
好在，好在我还在不断的学习，只是但前处于一种较混沌的状态，需要踏出去更多一步。
今天来说一个简单的话题，找回一些状态。
关于fragment，相信大家已经熟之不能再熟了。然而，
使用频率如此之高的fragment，你的使用姿势，真的正确吗？
先对比一下两种使用姿势：
1.姿势a：
2.姿势b:
myfragment mfragment = myfragment.newinstance("a", "b","c");
getsupportfragmentmanager().begintransaction().replace(r.id.frame, mfragment).commit();
有没有，有没有觉得第二种姿势特别爽。
接来下进入今天的正题，关于fragment.newinstance()这个方法。
我先声明，其实第一种姿势没什么问题，（引用斯坦福白胡子老头一句话）”这只是代码风格的问题，但我不建议这么做。”
使用android studio新建一个fragment就一切明了了：
我们看到，studio默认帮我们创建的fragment中，有这样一段代码:
一个静态方法，返回我们创建的fragment类本身，显而易见的是，这个方法帮我们做了姿势a中我们手写的方法。
再来关注看我们较少override的方法oncreate（这里默认直接帮我们override了）
到这里，我们先捋一捋。姿势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找下去，发现其实相关的主要方法并不多：
这三个比较简单，就不说了
在instantiate()实例化过程中，可以看到
也就是说，如果我们调用时使用setarguments()传递了bundle,它会被保存在marguments 这个私有声明中。
而如果是通过构造函数传递的参数,那很不幸，fragment重建过程中，并没有持有相应参数的属性或方法，自然，你通过构造函数传递的参数就丢失了。
其实目前大家单纯无参new fragment()的方式并没有错，只是可以让activity更优雅的调用fragment.newinstance()，
而如果涉及到传递参数，万不可通过构造函数传递，会丢失。
知其然，知其所以然
总结，fragment.newinstance() ,别无其他，只是事关风格（代码”整”“洁”之道），建议大家以后均使用谷歌推荐的该方法
以上这篇使用newinstance()来实例化fragment并传递数据操作就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持。