m7 fragment mvvm

最新推荐文章于 2024-06-26 22:15:00 发布

chouhuo6409

最新推荐文章于 2024-06-26 22:15:00 发布

阅读量287

点赞数

原文链接：https://my.oschina.net/u/2288454/blog/1922825

版权

#Fragment

##为何产生
* 同时适配手机和平板、UI和逻辑的共享。

##介绍
* Fragment也会被加入回退栈中。
* Fragment拥有自己的生命周期和接受、处理用户的事件
* 可以动态的添加、替换和移除某个Fragment

##生命周期
* 必须依存于Activity

![Mou icon](https://img-blog.csdn.net/20140719225005356?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbG1qNjIzNTY1Nzkx/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)

* Fragment依附于Activity的生命状态
* ![Mou icon](https://github.com/GeniusVJR/LearningNotes/blob/master/Part1/Android/FlowchartDiagram.jpg?raw=true)

生命周期中那么多方法，懵逼了的话我们就一起来看一下每一个生命周期方法的含义吧。

##Fragment生命周期方法含义：
* `public void onAttach(Context context)`
	* onAttach方法会在Fragment于窗口关联后立刻调用。从该方法开始，就可以通过Fragment.getActivity方法获取与Fragment关联的窗口对象，但因为Fragment的控件未初始化，所以不能够操作控件。
	
* `public void onCreate(Bundle savedInstanceState)`
	* 在调用完onAttach执行完之后立刻调用onCreate方法，可以在Bundle对象中获取一些在Activity中传过来的数据。通常会在该方法中读取保存的状态，获取或初始化一些数据。在该方法中不要进行耗时操作，不然窗口不会显示。
	
* `public View onCreateView(LayoutInflater inflater, ViewGroup container,Bundle savedInstanceState)`
	* 该方法是Fragment很重要的一个生命周期方法，因为会在该方法中创建在Fragment显示的View，其中inflater是用来装载布局文件的，container是`<fragment>`标签的父标签对应对象，savedInstanceState参数可以获取Fragment保存的状态，如果未保存那么就为null。
	
* `public void onViewCreated(View view,Bundle savedInstanceState)`
	* Android在创建完Fragment中的View对象之后，会立刻回调该方法。其种view参数就是onCreateView中返回的view，而bundle对象用于一般用途。
	
* `public void onActivityCreated(Bundle savedInstanceState)`
	* 在Activity的onCreate方法执行完之后，Android系统会立刻调用该方法，表示窗口已经初始化完成，从这一个时候开始，就可以在Fragment中使用getActivity().findViewById(Id);来操控Activity中的view了。
	
* `public void onStart()`
	* 这个没啥可讲的，但有一个细节需要知道，当系统调用该方法的时候，fragment已经显示在ui上，但还不能进行互动，因为onResume方法还没执行完。
	
* `public void onResume()`
	* 该方法为fragment从创建到显示Android系统调用的最后一个生命周期方法，调用完该方法时候，fragment就可以与用户互动了。

* `public void onPause()`
	* fragment由活跃状态变成非活跃状态执行的第一个回调方法，通常可以在这个方法中保存一些需要临时暂停的工作。如保存音乐播放进度，然后在onResume中恢复音乐播放进度。

* `public void onStop()`
	* 当onStop返回的时候，fragment将从屏幕上消失。

* `public void onDestoryView()`
	* 该方法的调用意味着在 `onCreateView` 中创建的视图都将被移除。

* `public void onDestroy()`
	* Android在Fragment不再使用时会调用该方法，要注意的是~这时Fragment还和Activity藕断丝连！并且可以获得Fragment对象，但无法对获得的Fragment进行任何操作（呵~呵呵~我已经不听你的了）。

* `public void onDetach()`
	* 为Fragment生命周期中的最后一个方法，当该方法执行完后，Fragment与Activity不再有关联(分手！我们分手！！(╯‵□′)╯︵┻━┻)。

##Fragment比Activity多了几个额外的生命周期回调方法：
* onAttach(Activity):当Fragment和Activity发生关联时使用
* onCreateView(LayoutInflater, ViewGroup, Bundle):创建该Fragment的视图
* onActivityCreate(Bundle):当Activity的onCreate方法返回时调用
* onDestoryView():与onCreateView相对应，当该Fragment的视图被移除时调用
* onDetach():与onAttach相对应，当Fragment与Activity关联被取消时调用

###注意：除了onCreateView，其他的所有方法如果你重写了，必须调用父类对于该方法的实现

##Fragment与Activity之间的交互
* Fragment与Activity之间的交互可以通过`Fragment.setArguments(Bundle args)`以及`Fragment.getArguments()`来实现。

##Fragment状态的持久化。
由于Activity会经常性的发生配置变化，所以依附它的Fragment就有需要将其状态保存起来问题。下面有两个常用的方法去将Fragment的状态持久化。

* 方法一：
	* 可以通过`protected void onSaveInstanceState(Bundle outState)`,`protected void onRestoreInstanceState(Bundle savedInstanceState)` 状态保存和恢复的方法将状态持久化。
* 方法二(更方便,让Android自动帮我们保存Fragment状态)：
	* 我们只需要将Fragment在Activity中作为一个变量整个保存，只要保存了Fragment，那么Fragment的状态就得到保存了，所以呢.....
		* `FragmentManager.putFragment(Bundle bundle, String key, Fragment fragment)` 是在Activity中保存Fragment的方法。
		* `FragmentManager.getFragment(Bundle bundle, String key)` 是在Activity中获取所保存的Frament的方法。
	* 很显然，key就传入Fragment的id，fragment就是你要保存状态的fragment，但，我们注意到上面的两个方法，第一个参数都是Bundle，这就意味着*FragmentManager*是通过Bundle去保存Fragment的。但是，这个方法仅仅能够保存Fragment中的控件状态，比如说EditText中用户已经输入的文字（*注意！在这里，控件需要设置一个id，否则Android将不会为我们保存控件的状态*），而Fragment中需要持久化的变量依然会丢失，但依然有解决办法，就是利用方法一！
	* 下面给出状态持久化的事例代码：
		```		
			 /** Activity中的代码 **/
			 FragmentB fragmentB;

		    @Override
		    protected void onCreate(@Nullable Bundle savedInstanceState) {
		        super.onCreate(savedInstanceState);
		        setContentView(R.layout.fragment_activity);
		        if( savedInstanceState != null ){
		            fragmentB = (FragmentB) getSupportFragmentManager().getFragment(savedInstanceState,"fragmentB");
		        }
		        init();
		    }

		    @Override
		    protected void onSaveInstanceState(Bundle outState) {
		        if( fragmentB != null ){
		            getSupportFragmentManager().putFragment(outState,"fragmentB",fragmentB);
		        }

		        super.onSaveInstanceState(outState);
		    }

		    /** Fragment中保存变量的代码 **/

		    @Nullable
		    @Override
		    public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
		        AppLog.e("onCreateView");
		        if ( null != savedInstanceState ){
		            String savedString = savedInstanceState.getString("string");
		            //得到保存下来的string
		        }
		        View root = inflater.inflate(R.layout.fragment_a,null);
		        return root;
		    }

			@Override
		    public void onSaveInstanceState(Bundle outState) {
		        outState.putString("string","anAngryAnt");
		        super.onSaveInstanceState(outState);
		    }

		```

##静态的使用Fragment
1. 继承Fragment，重写onCreateView决定Fragment的布局
2. 在Activity中声明此Fragment,就和普通的View一样

##Fragment常用的API
* android.support.v4.app.Fragment 主要用于定义Fragment
* android.support.v4.app.FragmentManager 主要用于在Activity中操作Fragment，可以使用FragmentManager.findFragmenById，FragmentManager.findFragmentByTag等方法去找到一个Fragment
* android.support.v4.app.FragmentTransaction 保证一些列Fragment操作的原子性，熟悉事务这个词
* 主要的操作都是FragmentTransaction的方法
(一般我们为了向下兼容，都使用support.v4包里面的Fragment)
<code>

	getFragmentManager() // Fragment若使用的是support.v4包中的，那就使用getSupportFragmentManager代替
	
</code>

* 主要的操作都是FragmentTransaction的方法

```
	
	FragmentTransaction transaction = fm.benginTransatcion();//开启一个事务
	transaction.add() 
	//往Activity中添加一个Fragment

	transaction.remove() 
	//从Activity中移除一个Fragment，如果被移除的Fragment没有添加到回退栈（回退栈后面会详细说），这个Fragment实例将会被销毁。

	transaction.replace()
	//使用另一个Fragment替换当前的，实际上就是remove()然后add()的合体~

	transaction.hide()
	//隐藏当前的Fragment，仅仅是设为不可见，并不会销毁

	transaction.show()
	//显示之前隐藏的Fragment

	detach()
	//当fragment被加入到回退栈的时候，该方法与*remove()*的作用是相同的，
	//反之，该方法只是将fragment从视图中移除，
	//之后仍然可以通过*attach()*方法重新使用fragment，
	//而调用了*remove()*方法之后，
	//不仅将Fragment从视图中移除，fragment还将不再可用。

	attach()
	//重建view视图，附加到UI上并显示。

	transatcion.commit()
	//提交一个事务

```

##管理Fragment回退栈
* 跟踪回退栈状态
	* 我们通过实现*``OnBackStackChangedListener``*接口来实现回退栈状态跟踪，具体如下
 	```
 	public class XXX implements FragmentManager.OnBackStackChangedListener 

 	/** 实现接口所要实现的方法 **/

	@Override
    public void onBackStackChanged() {
        //do whatevery you want
    }

    /** 设置回退栈监听接口 **／
    getSupportFragmentManager().addOnBackStackChangedListener(this);


 	```
		
* 管理回退栈
	* ``FragmentTransaction.addToBackStack(String)`` *--将一个刚刚添加的Fragment加入到回退栈中*
	* ``getSupportFragmentManager().getBackStackEntryCount()`` *－获取回退栈中实体数量*
	* ``getSupportFragmentManager().popBackStack(String name, int flags)`` *－根据name立刻弹出栈顶的fragment*
	* ``getSupportFragmentManager().popBackStack(int id, int flags)`` *－根据id立刻弹出栈顶的fragment*

#MVC,MVP,MVVM的区别
---


#MVC
软件可以分为三部分

* 视图（View）:用户界面
* 控制器（Controller）:业务逻辑
* 模型（Model）:数据保存

各部分之间的通信方式如下：

1. View传送指令到Controller
2. Controller完成业务逻辑后，要求Model改变状态
3. Model将新的数据发送到View，用户得到反馈

Tips：所有的通信都是单向的。

#互动模式
接受用户指令时，MVC可以分为两种方式。一种是通过View接受指令，传递给Controller。

另一种是直接通过Controller接受指令


#MVP

MVP模式将Controller改名为Presenter，同时改变了通信方向。

1. 各部分之间的通信，都是双向的
2. View和Model不发生联系，都通过Presenter传递
3. View非常薄，不部署任何业务逻辑，称为"被动视图"(Passive View)，即没有任何主动性，而Presenter非常厚，所有逻辑都部署在那里。


#MVVM

MVVM模式将Presenter改名为ViewModel，基本上与MVP模式完全一致。

唯一的区别是，它采用双向绑定(data-binding)：View的变动，自动反映在ViewModel，反之亦然。

#面向对象的六大原则

单一职责原则

　　所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。通俗的说，即一个类只负责一项职责，将一组相关性很高的函数、数据封装到一个类中。

开闭原则

　　对于扩展是开放的，这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。　　对于修改是关闭的，对模块行为进行扩展时，不必改动模块的源代码。

　　通俗的说，尽量通过扩展的方式实现系统的升级维护和新功能添加，而不是通过修改已有的源代码。

里氏替换原则

　　使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。任何基类可以出现的地方，子类一定可以出现。

　　在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

依赖倒置原则

　　高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。抽象不应该依赖于具体实现，具体实现应该依赖于抽象。　　　　程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合（各个模块之间相互传递的参数声明为抽象类型，而不是声明为具体的实现类）。

接口隔离原则

　　一个类对另一个类的依赖应该建立在最小的接口上。其原则是将非常庞大的、臃肿的接口拆分成更小的更具体的接口。

迪米特原则

　　又叫作最少知识原则，就是说一个对象应当对其他对象有尽可能少的了解。　　通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，不关心被耦合或调用的类的内部实现，只负责调用你提供的方法。

#ART和Dalvik区别

Art上应用启动快，运行快，但是耗费更多存储空间，安装时间长，总的来说ART的功效就是"空间换时间"。

ART: Ahead of Time Dalvik: Just in Time

什么是Dalvik：Dalvik是Google公司自己设计用于Android平台的Java虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一，它可以支持已转换为.dex(即Dalvik Executable)格式的Java应用程序的运行，.dex格式是专为Dalvik应用设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik应用作为独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

什么是ART:Android操作系统已经成熟，Google的Android团队开始将注意力转向一些底层组件，其中之一是负责应用程序运行的Dalvik运行时。Google开发者已经花了两年时间开发更快执行效率更高更省电的替代ART运行时。ART代表Android Runtime,其处理应用程序执行的方式完全不同于Dalvik，Dalvik是依靠一个Just-In-Time(JIT)编译器去解释字节码。开发者编译后的应用代码需要通过一个解释器在用户的设备上运行，这一机制并不高效，但让应用能更容易在不同硬件和架构上运行。ART则完全改变了这套做法，在应用安装的时候就预编译字节码到机器语言，这一机制叫Ahead-Of-Time(AOT)编译。在移除解释代码这一过程后，应用程序执行将更有效率，启动更快。

ART优点：