Welcome to Ray's Blog

概述

工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。

• 工厂方法模式又简称工厂模式（Factory Pattern），又可称作虚拟构造器模式（Virtual Constructor Pattern）或多态工厂模式（Polymorphic Factory Pattern）。
• 工厂方法模式让一个类的实例化延迟到其子类。
• 工厂方法模式是一种类创建型模式。
• 工厂方法模式提供一个抽象工厂接口来声明抽象工厂方法，而由其子类来具体实现工厂方法，创建具体的产品对象。

角色详解：

• Product（抽象产品）：它是定义产品的接口，是工厂方法模式所创建对象的超类型，也就是产品对象的公共父类。

• ConcreteProduct（具体产品）：它实现了抽象产品接口，某种类型的具体产品由专门的具体工厂创建，具体工厂和具体产品之间 一一对应。
• Factory（抽象工厂）：在抽象工厂类中，声明了工厂方法factoryMethod()，用于返回一个产品。抽象工厂是工厂方法模式的核心，所有创建对象的工厂类都必须实现该接口。
• ConcreteFactory（具体工厂）：它是抽象工厂类的子类，实现了抽象工厂中定义的工厂方法，并可由客户端调用，返回一个具体产品类的实例。

与简单工程模式相比，工厂方法模式最重要的区别就是引入了抽象工厂角色，抽象工厂角色可以是接口，也可以是抽象类或者具体类。

总结

工厂方法模式是简单工厂模式的延伸，它继承了简单工厂模式的优点，同时还弥补了简单工厂模式的不足。工厂方法模式是使用频率最高的设计模式之一，是很多开源框架和 API 内裤的核心模式。
** 优点**

• 在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂类，无须关心创建细节，甚至无须知道具体产品类的类名。
• 基于工厂角色和产品角色的多态性设计是工程方法模式的关键。它能够让工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，就正是因为所有的具体工厂类都具有同一抽象父类。
• 使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了，这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。

** 缺点**

• 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
• 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到 DOM、反射等技术，增加了系统的实现难度。

** 使用场景**

• 客户端不知道它所需要的东西的类名。在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建。在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使用系统更容易扩展。

里氏替换原则

定义

原文：The Liskov Substitution Principle (LSP, lsp)
is a concept in Object Oriented Programming that
states: Functions that use pointers or references
to base classes must be able to use objects of derived classes without knowing it
中文：** 如果对每一个类型为 S 的对象 o1，都有类型为 T 的对象 o2，使得以 T 定义的所有程序 P 在所有的对象 o1 代换 o2 时，程序 P 的行为没有变化，那么类型 S 是类型 T 的子类型。**
通俗版中文：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

参考资源

概述

简单工厂模式（Simple Factory Pattern）： 定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。

• 因为在简单工程模式中用于创建实例的方法是静态（static）方法，因此简单工厂模式又被称为静态工厂模式（Static Factory Method）模式，它属于类创建型模式。
• 简单的说就是：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。

角色详解：

• Factory（工厂角色）：工厂角色即工厂类，它是简单工厂模式的核心类，负责实现创建产品实例的内部逻辑；工厂类可以被外界直接调用，创建所需的产品对象；在工厂类中提供了静态的工厂方法factoryMethod（）,它的返回类型为抽象产品类型product。

• Product（抽象产品角色）：它是工厂类所创建的所有对象的父类，封装了各种产品对象的公有方法，它的引入提高系统的灵活性，使得工厂类中只需定义一个通用的工厂方法，因为所有的创建的具体产品对象都是其子类对象。
• ConcreteProduct(具体产品角色)：它是简单工厂模式的创建目标，所有被创建的对象都充当这个角色的某个具体类的实例。每一个具体角色产品都继承了抽象产品角色，需要实现在抽象产品中声明的抽象方法。

总结

简单工厂模式提供了专门的工厂类用于创建对象，将对象的创建和对象的使用分离开，它作为一种最简单的工厂模式，在软件开发中得到了较为广泛的应用。

** 优点**

• 工厂类包含必要的判断逻辑，可以决定在什么时候创建那一个产品类的实例，客户端可以免除直接创建产品对象的职责，而仅仅“消费”产品，简单工厂模式实现了对象创建和使用的分离。
• 客户端无需知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以在一定程度上减少使用者的记忆量。
• 通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统灵活性。

** 缺点**

• 由于工厂类集中了所有产品的创建逻辑，职责过重，一旦不能正常工作，整个系统都要受到影响。
• 使用简单工厂模式势必会增加系统中类的个数（引入了新的工厂类），增加了系统的复杂度和理解难度。
• 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时候，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
• 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

** 适用场景**

• 工厂类负责创建的对象比较少，由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
• 客户端只知道传入工厂类的参数，对于如何创建对象并不关心。

参考资源

概述

建造者模式（Builder Pattern）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。

Deprecated

This section is deprecated and no longer maintained. Please refer to the latest documentation for updated information.

定义

示例

总结

我们为什么需要多线程机制？什么时候需要使用到多线程？

1. 因为 Android 官方明确在多线程编程时有俩大原则：

   • 第一、不能阻塞 UI 线程（主线程）；

• 第二、不能在 UI 线程之外访问 UI 组件；

2. 使用情况

   • 第一、将任务从主线程抛到工作线程;
   • 第二、将任务从工作线程抛到主线程。

   Read more »

常用快捷键总结

Android：windowSoftInputMode 属性使用详解：

1
2
3
4
5
6
7
8
9
10
11
12

<activity
	android:windowSoftInputMode=["stateUnspecified"
	|"stateUnchanged"
	|"stateHidden"
	|"stateAlwaysHidden"
	|"stateVsible"
	|"stateAlwaysVisibe"
	|"adjustUnspecified"
	|"adjustResize"
	|"adjustPan"
	]
	.../>

目录

1. getActivity()空指针；
2. Fragment重叠异常—正确使用Hide()/show()的姿势；

Pre

• Android App 有一种特殊情况，就是在 App 运行在后台的时候，系统资源紧张的时候导致把 App 的资源全部回收（杀死 App 进程），这个时候把 App 再从后台返回前台时，app 会重启。这种情况简称“内存重启”。

getActivity()空指针

多数原因：你在调用了getActivity()时，当前的 Fragment 已经onDetach()了宿主 Activity.比如：你在 pop 了 Fragment 之后，该 Fragment 的异步任务仍然在执行，并且在执行完成后调用了getActivity()方法，这样就会报 NULLPOINTEXCEPTION；
解决方法：（对于 Fragment 已经onDetach()这种情况，我们应该避免在这之后再去调用宿主 Activity 对象，比如取消这些异步任务，当我们的团队可能会有粗心大意的时候，所以下面给出的方法会保证安全）

• 在 Fragment 基类里设置一个 Activity mActivity 的全局变量，在onAttach(Activity act)里赋值，使用 mActivity 代替getActivity(),保证 Fragment 即使在 onDetach 后，仍持有 Activity 的引用（有 MermoryLeak 风险。）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

protected Activity mActivity;
@Override
public void onAttach(Activity activity){
	super.onAttach(activity)
    this.mActivity = activity;
}
	/**
	*  如果你用了support 23的库，上面的方法会提示过时，有强迫症的小伙伴，可以用下面的方法代替
	*/
@Override
public void onAttach(Context context){
	super.onAttach(context);
    this.mActivity = (Activity)context;
}

Fragment 重叠异常—–正确的才使用hide()/show()姿势

如果你add()了几个 Fragment，使用show()/hide()等方法控制显示，比如微信、QQ 的底部 tab 等情景，如果你什么都不做的话，在“内存重启”后回到前台，app 的这几个 Fragment 界面会重叠。

原因

FragmentManager 帮我们管理 Fragment，当发生“内存重启”，他会从栈底向栈顶的顺序一次性恢复 Fragment；但是因为没有保存 Fragment 的 mHidden 属性，默认为 false，即 show 状态，所以所有的 Fragment 都是以 show 的形式恢复，即发生了界面重叠现象。（如果是replace（），恢复形式和 Activity 一致，只有当你的 pop 之后上一个 Fragment 才开始重新恢复，所以使用replace（）不会造成重叠现象。）

解决方案 1

• findFragmentByTag：即在add（）或者replace（）时绑定一个 tag，一般我们是用 fargment 的类名作为 tag，然后在发生“内存重启”时，通过findFragmentByTag找到对应的 Fragment，并hide（）需要隐藏的 Fragment。
  下面是标准的恢复写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

@Override
protected void onCreate(Bundle SavedInstanceState){
	super.onCreate(savedInstanceState);
   setContentView(R.layout.activity);
   TargetFragment targetFragment;
   HideFragment hideFragment;
   if(savedInstanceState!=null){
   //内存重启时调用
   targetFragment = getSupportFragmentManager().findFragmentByTag(TargetFragment.class.getName());
   hideFragment = getSupportFragmentManager().findFragmentByTag(hideFragment.CLASS.GETnAME());
   //解决重叠问题
   getFragmentManager().beginTransaction()
   	.show(targetFragment)
       .hide(hideFragment)
       .commit();
   }else{
   //正常时
   targetFragment = TargentFragment.newInstance();
   hideFragment = HideFragment.newInstance();
   getFragmentManager().beginTransaction()
   	.add(R.id.container,targetFragment,targetFragment.getClass().getName())
       .add(R.id.container,hideFragment,hideFragment.getClass().getName())
       .hide(hideFragment)
       .commit();
   }
}

如果你想要恢复到用户离开时那个 Fragment 的界面，你还需要在onSaveInstanceState（Bundle outState）里保存离开时的按个可见的 tag 或者下标，在onCreate（）“内存重启”代码块中，去除 tag/下标，进行恢复。

解决方法 2:

• 使用getSupportFragment（）.getFragments()恢复:使用getFragment()可以获取到当前FragmentManager管理的栈内所有 Fragment。
  写法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

@Override
protected void onCreate(Bundle savedInstanceState){
	super.onCreate(savedInstanceState);
    setContentView(R.layout.activity);
    TargetFragment targetFRAGMENT;
    HideFragment hideFragment;
    if(savedInstanceState !=null){//"内存重启"时调用}
    List<Fragment> fragmentList = getSupportFragmentManager().getFragments();
    for(Fragment fragment : fragmentList){
    	if(fragment instanceof TargetFragment){
        	targetFragment = (TargetFragment)fragment;
        }else if(fragment instancof HideFragment){
        	hideFragment = (HideFragment)fragment;
        }
    //解决重叠问题
    getFragmentManager().beginTransaction()
    	.show(targetFragment)
        .hide(hideFragment)
        .commit();
    }else{
    	targetFragment = TargetFragment.newInstance();
        hideFragment = HideFragment.newInstance();
        //这里add（）时，可以不传tag
        getFragmentManager().beginTransaction()
        	.add(R.id.container)
            .add(R.id.container,hideFragment)
            .hide(hideFragment)
            .commit();
    }
}

在下一篇中介绍在不同场景下如果选择，何时用 findFragmentByTag()，何时用 getFragments()恢复。

解决方法 3：

发生 Fragment 重叠的根本原因在于FragmentState没有保存 Fragment 的显示状态，即mHidden，导致页面重启后，该值为默认的 false，即 show 状态，所以导致了 Fragment 的重叠。因此自己去维护一个mSupportHidden值即可解决问题：
Fragment 基类代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class BaseFragment extends Fragment{
	private static final String STATE_SAVE_IS_HIDDEN = “STATE_SAVE_IS_HIDDEN”；
    @Override
    public void onCreate(@Nullable Bundle savedInstanceState){
    	boolean isSUpportHidden = savedInstanceState.getBoolean(STATE_SAVE_IS_HIDDEN);
        FragmentTransaction ft = getFragmentManager().beginTransaction();
        if(isSupportHidden){
        	ft.hide(this);
        }else{
        	ft.show{this};
        }
        ft.commit();
    }
     @Override
     public void onSavedInstanceState(Bundle outState){
    	...
        outState.putBoolean(STATE_SAVE_IS_HIDDEN,isHidden());
    }
}

解决思路：由 Activity/父 Fragment 来管理子 Fragment 的 Hidden 状态转变为 由 Fragment 自己来管理自己的 Hidden 状态！

补充：

加载根 Fragment 时需要判断saveInstanceState是否为null，避免重复加载相同的 Fragment：

1
2
3
4
5
6
7
8
9
10
11

public class MainActivity ... {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        ...
        // 这里一定要在save为null时才加载Fragment，Fragment中onCreateView等生命周里加载根子Fragment同理
        // 因为在页面重启时，Fragment会被保存恢复，而此时再加载Fragment会重复加载，导致重叠
        if(saveInstanceState == null){
              // 这里加载根Fragment
        }
    }
}

Pre

今天敲代码的时候发现突然想起，一直在 XML 布局文件中为每个组件赋值 ID 的时候是使用的@+id/来定义 ID，但是就突然疑惑了，为什么是@+id/，而不是@id/？果断的 Google 大法，找到了 StackOverflow 上的解答 1 、 解答 2：

1. 新建一个 project，如果 project 已经存在那么直接创建一个 module，这里一定要注意选择 Java library，然后点击下一步；
2. 输入 module 信息，然后点击下一步；
3. 在创建的 Java 类中添加 main 方法:

1
2
3

public static void main（String[] args）{
	System.out.println("如何利用AndroidStudio开发可以运行的java工程");
}