AppCompatActivity是support.v7包里面用來替代Activity的Activity組件，主要用來兼容5.0之后的新特性，當我們在不同版本的系統里面使用的時候會發現，在5.0之后的系統中，控件會帶新特性，而在之前的版本中，則使用的控件則不能使用新特新。

比如:
TextView在Activity下是android.widget.TextView,
而在AppCompatActivity中則是android.support.v7.widget.AppCompatTextView，
為什么在AppCompatActivity中，我們的TextView會被系統篡改成AppCompatTextView，今天我們來一起找找原因。

首先我們來看下AppCompatActivity是如何加載布局的：

// AppCompatActivity.java
@Override
public void setContentView(@LayoutRes int layoutResID) {
   getDelegate().setContentView(layoutResID);
}

@NonNull
public AppCompatDelegate getDelegate() {
   if (mDelegate == null) {
       mDelegate = AppCompatDelegate.create(this, this);
   }
   return mDelegate;
}

private static AppCompatDelegate create(Context context, Window window,
       AppCompatCallback callback) {
   final int sdk = Build.VERSION.SDK_INT;
   if (BuildCompat.isAtLeastN()) {
       return new AppCompatDelegateImplN(context, window, callback);
   } else if (sdk >= 23) {
       return new AppCompatDelegateImplV23(context, window, callback);
   } else if (sdk >= 14) {
       return new AppCompatDelegateImplV14(context, window, callback);
   } else if (sdk >= 11) {
       return new AppCompatDelegateImplV11(context, window, callback);
   } else {
       return new AppCompatDelegateImplV9(context, window, callback);
   }
}

可以發現在create方法中，對版本進行了控制，對于不同的版本構建了不同的APPCOMPatDelegate對象。當我們點進去會發現，這些根據版本構建的對象最終都是繼承自同一個類AppCompatDelegateImplV9，而AppCompatDelegateImplV9則是實現了一個LayoutInflaterFactory的接口。這個接口到底是什么東西呢？

我們暫時先不要管這個，接著向下看：

@Override
public void setContentView(View v) {
   ensureSubDecor();
   ViewGroup contentParent = (ViewGroup) mSubDecor.findViewById(android.R.id.content);
   contentParent.removeAllViews();
   contentParent.addView(v);
   mOriginalWindowCallback.onContentChanged();
}

private ViewGroup createSubDecor() {
    subDecor = (ViewGroup) inflater.inflate(R.layout.abc_screen_simple, null);
    final ContentFrameLayout contentView = (ContentFrameLayout) subDecor.findViewById(
                R.id.action_bar_activity_content);
}

這邊其實就和Activity加載布局是一樣的了，都是通過先添加DecorView，在找到名為content的framelayout的id，通過在這個id上添加我們的布局：

請參考 【Android源碼】Activity如何加載布局

這個時候我們就會發現在我們當時做的【Android源碼】LayoutInflater 分析和【Android源碼】View的創建流程，所沒有注意到的細節：

View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
        boolean ignoreThemeAttr) {
      try {
      View view;
      if (mFactory2 != null) {
          view = mFactory2.onCreateView(parent, name, context, attrs);
      } else if (mFactory != null) {
          view = mFactory.onCreateView(name, context, attrs);
      } else {
          view = null;
      }
    
      if (view == null && mPrivateFactory != null) {
          view = mPrivateFactory.onCreateView(parent, name, context, attrs);
      }
    
      if (view == null) {
          final Object lastContext = mConstructorArgs[0];
          mConstructorArgs[0] = context;
          try {
              if (-1 == name.indexOf('.')) {
                  view = onCreateView(parent, name, attrs);
              } else {
                  view = createView(name, null, attrs);
              }
          } finally {
              mConstructorArgs[0] = lastContext;
          }
      }
    
      return view;
    } catch (InflateException e) {
      throw e;
    }      
}

createViewFromTag是用來創建View的，但是我們會發現在代碼中會有factory2、factory這兩個東西，而這兩個東西就是我們在上面發現的AppCompatDelegateImplV9實現的LayoutInflaterFactory接口，只要實現了這個接口，那么View會被這個接口來賦值，而不是接著走原來的View的創建過程。

所以我們現在返回到AppCompatDelegateImplV9中，找到接口的實現方法：

@Override
public final View onCreateView(View parent, String name,
       Context context, AttributeSet attrs) {
   // First let the Activity's Factory try and inflate the view
   final View view = callActivityOnCreateView(parent, name, context, attrs);
   if (view != null) {
       return view;
   }

   // If the Factory didn't handle it, let our createView() method try
   return createView(parent, name, context, attrs);
}

@Override
public View createView(View parent, final String name, @NonNull Context context,
       @NonNull AttributeSet attrs) {
   final boolean isPre21 = Build.VERSION.SDK_INT < 21;

   if (mAppCompatViewInflater == null) {
       mAppCompatViewInflater = new AppCompatViewInflater();
   }

   // We only want the View to inherit its context if we're running pre-v21
   final boolean inheritContext = isPre21 && shouldInheritContext((ViewParent) parent);

   return mAppCompatViewInflater.createView(parent, name, context, attrs, inheritContext,
           isPre21, /* Only read android:theme pre-L (L+ handles this anyway) */
           true, /* Read read app:theme as a fallback at all times for legacy reasons */
           VectorEnabledTintResources.shouldBeUsed() /* Only tint wrap the context if enabled */
   );
}

在這個實現方法中，最終我們找到類AppCompatViewInflater，而這個類通過createView方法來直接賦值給View：

public final View createView(View parent, final String name, @NonNull Context context,
       @NonNull AttributeSet attrs, boolean inheritContext,
       boolean readAndroidTheme, boolean readAppTheme, boolean wrapContext) {
   final Context originalContext = context;

   View view = null;

   // We need to 'inject' our tint aware Views in place of the standard framework versions
   switch (name) {
       case "TextView":
           view = new AppCompatTextView(context, attrs);
           break;
      case "ImageView":
           view = new AppCompatImageView(context, attrs);
           break;
      // 代碼省略
   }
   return view;
}

可以發現，如果是TextView，就直接返回V7包中的AppCompatTextView類，所以這就是為什么當我們使用AppCompatActivity的時候，TextView變成AppCompatTextView的原因。

通過實現LayoutInflaterFactory，系統就會根據當前系統的版本號，來對應的生成View，所以這就是為什么在不同版本中，同一個控件會有不同的效果的原因。