【Android原始碼】不同版本系統如何載入View AppCompatActivity和Activity的setContentView

指間沙似流年發表於2017-12-23

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,所以這就是為什麼在不同版本中,同一個控制元件會有不同的效果的原因。

相關文章