Window與WindowManager-有解無憂

相關類:

Window:是一個抽象類,只是一個概念并不實際存在,唯一實作類是PhoneWindow,其對View進行管理
WindowManager:一個介面類,繼承自ViewManager,字面意思對Window進行管理,實際上是對View進行添加,洗掉及更新操作.實作類是WindowManagerImpl

/**
  * code 1
  */
public interface ViewManager
{
    public void addView(View view, ViewGroup.LayoutParams params);
    public void updateViewLayout(View view, ViewGroup.LayoutParams params);
    public void removeView(View view);
}

WindowManagerService(WMS):實際對View進行處理的類,通過IPC與WindowManager進行通信

Activity通過ActivityThread中的performLaunchActivity()方法完成整個啟動流程,并通過ClassLoader類加載器創建Activity的實體,并呼叫attach方法關聯其運行程序所依賴的一系列背景關系環境變數:
frameworks/base/core/java/android/app/ActivityThread.java

/**
  * code 2
  */
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
	ContextImpl appContext = createBaseContextForActivity(r);
    Activity activity = null;
    java.lang.ClassLoader cl = appContext.getClassLoader();
    activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
    if (activity != null) {
    	Window window = null;
    	//如果保存Activity資訊的ActivityClientRecord實體中mPendingRemoveWindow不為空,則使用使用已保存的window物件
	    if (r.mPendingRemoveWindow != null && r.mPreserveWindow) {
	        window = r.mPendingRemoveWindow;
	        r.mPendingRemoveWindow = null;
	        r.mPendingRemoveWindowManager = null;
	    }
	    appContext.setOuterContext(activity);
	    activity.attach(appContext, this, getInstrumentation(), r.token,
	                        r.ident, app, r.intent, r.activityInfo, title, r.parent,
	                        r.embeddedID, r.lastNonConfigurationInstances, config,
	                        r.referrer, r.voiceInteractor, window, r.configCallback);
    }
}

ActivityClientRecord中的mPendingRemoveWindow只在handleDestroyActivity方法中出現過賦值代碼,而用于判斷的mPreserveWindow(是否保留window)則出現在handleRelaunchActivity方法中,relaunch也就是先銷毀再啟動,將mPreserveWindow改為true,再呼叫handleDestroyActivity把延遲銷毀的window和wms物件進行保存,然后將Activity銷毀,最后呼叫handleLaunchActivity,走performLaunchActivity方法重新拉起Activity,這時就走到了上面這段代碼,attach方法中的window物件就由剛才銷毀Activity后保存的window物件賦值.

/**
 *  code 3
 *  此處ActivityThread會回呼Activitiy的onDestroy方法
 */
private void handleDestroyActivity(IBinder token, boolean finishing,
            int configChanges, boolean getNonConfigInstance) {
            ...
            if (r.activity.mWindowAdded) {
                    if (r.mPreserveWindow) {
                        // 延遲移除window和wms物件,直到新Activity中的window被添加
                        r.mPendingRemoveWindow = r.window;
                        r.mPendingRemoveWindowManager = wm;
                        // We can only keep the part of the view hierarchy that we control,
                        // everything else must be removed, because it might not be able to
                        // behave properly when activity is relaunching.
                        r.window.clearContentView();
                    } else {
                        wm.removeViewImmediate(v);
                    }
            ...
	}

那么如果是正常的啟動Activity呢?attach方法中傳參window將為空,現在走進attach方法,可以看到Window的具體實作類就是PhoneWindow,PhoneWindow直接在attach方法中創建實體,并設定回呼介面,在Callback介面中有諸如dispatchTouchEvent,onAttachToWindow等方法

/**
  * code 4
  */
final void attach(Context context, ActivityThread aThread,
            Instrumentation instr, IBinder token, int ident,
            Application application, Intent intent, ActivityInfo info,
            CharSequence title, Activity parent, String id,
            NonConfigurationInstances lastNonConfigurationInstances,
            Configuration config, String referrer, IVoiceInteractor voiceInteractor,
            Window window, ActivityConfigCallback activityConfigCallback) {
    attachBaseContext(context);

    mFragments.attachHost(null /*parent*/);
        
	mWindow = new PhoneWindow(this, window, activityConfigCallback);
	mWindow.setWindowControllerCallback(this);
	mWindow.setCallback(this);
	mWindow.setOnWindowDismissedCallback(this);
	...
	mWindow.setWindowManager(
                (WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
                mToken, mComponent.flattenToString(),
                (info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
	...

在attach方法中直接實體化了PhoneWindow,并在下面的setWindowManager方法為Window設定WindowManager,此方法在PhoneWindow父類Window中:
frameworks/base/core/java/android/view/Window.java

	/**
	  * code 5
	  */
    public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
            boolean hardwareAccelerated) {
        mAppToken = appToken;
        mAppName = appName;
        mHardwareAccelerated = hardwareAccelerated
                || SystemProperties.getBoolean(PROPERTY_HARDWARE_UI, false);
        if (wm == null) {
            wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
        }
        mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
    }

如果傳入的WindowManager為空,則通過mContext.getSystemService(Context.WINDOW_SERVICE)來獲取,此處Context實作類是ContextImpl,為什么呢?這里要先找到Activity實體化的地方,也就是ActivityThread的performLaunchActivity方法,即文章的第一段代碼code1,其中第一行代碼:

ContextImpl appContext = createBaseContextForActivity(r);

/**
  * code 6
  */
private ContextImpl createBaseContextForActivity(ActivityClientRecord r) {
        final int displayId;
        try {
            displayId = ActivityManager.getService().getActivityDisplayId(r.token);
        } catch (RemoteException e) {
            throw e.rethrowFromSystemServer();
        }
		//annotation 1
        ContextImpl appContext = ContextImpl.createActivityContext(
                this, r.packageInfo, r.activityInfo, r.token, displayId, r.overrideConfig);

        final DisplayManagerGlobal dm = DisplayManagerGlobal.getInstance();
        // For debugging purposes, if the activity's package name contains the value of
        // the "debug.use-second-display" system property as a substring, then show
        // its content on a secondary display if there is one.
        String pkgName = SystemProperties.get("debug.second-display.pkg");
        if (pkgName != null && !pkgName.isEmpty()
                && r.packageInfo.mPackageName.contains(pkgName)) {
            for (int id : dm.getDisplayIds()) {
                if (id != Display.DEFAULT_DISPLAY) {
                    Display display =
                            dm.getCompatibleDisplay(id, appContext.getResources());
                    appContext = (ContextImpl) appContext.createDisplayContext(display);
                    break;
                }
            }
        }
        return appContext;
    }

這里appContext是ClassLoader獲取的來源,而Activity又是通過類加載器生成,也就是說Activity中的context來源于ContextImpl的
createActivityContext方法,即注釋1,看到這里也就明白了getSystemService的來源,讓我們繼續順著ContextImpl往下看
frameworks/base/core/java/android/app/ContextImpl.java

/**
  * code 7
  */
@Override
public Object getSystemService(String name) {
        return SystemServiceRegistry.getSystemService(this, name);
    }

這里會呼叫SystemServiceRegistry.getSystemService(this, name),點進這個類會發現這個類是管理所有可以被回傳也就是可以被呼叫的系統服務
frameworks/base/core/java/android/app/SystemServiceRegistry.java

private static final HashMap<String, ServiceFetcher<?>> SYSTEM_SERVICE_FETCHERS =
            new HashMap<String, ServiceFetcher<?>>();
/**
  * code 8
  */
public static Object getSystemService(ContextImpl ctx, String name) {
        ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
        return fetcher != null ? fetcher.getService(ctx) : null;
    }

查看代碼發現,getSystemService傳入的name相當于key,還記得傳入的是什么嗎?
Context.WINDOW_SERVICE

public static final String WINDOW_SERVICE = "window";

也就是說當我們傳入對應的背景關系及key時會回傳給我們fetcher.getService方法回傳的物件,那"window"回傳的是什么呢?已知systemservice來源于名為SYSTEM_SERVICE_FETCHERS的HashMap,那么全域查找該map的put方法,定位如下:

/**
  * code 9
  */
private static <T> void registerService(String serviceName, Class<T> serviceClass,
            ServiceFetcher<T> serviceFetcher) {
        SYSTEM_SERVICE_NAMES.put(serviceClass, serviceName);
        SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
    }

查找registerService方法的呼叫發現,SystemServiceRegistry存在一個靜態代碼塊,里面通過registerService方法注冊了所有的系統服務,而我們要找的WINDOW_SERVICE就在其中:

/**
  * code 10
  */
static {
	registerService(Context.WINDOW_SERVICE, WindowManager.class,
	                new CachedServiceFetcher<WindowManager>() {
	            @Override
	            public WindowManager createService(ContextImpl ctx) {
	                return new WindowManagerImpl(ctx);
	            }});
}

CachedServiceFetcher是一個抽象類,真正回傳的是WindowManagerImpl,也就是說getSystemService(Context.WINDOW_SERVICE)最侄訓傳的是WindowManagerImpl物件,這樣我們結束ContextImpl及SystemServiceRegistry原始碼的查看,重新回傳到Window抽象類的setWindowManager方法中,也就是code 5,在獲得WindowManagerImpl物件后繼續向下走,會發現呼叫了createLocalWindowManager方法,點進去看看

frameworks/base/core/java/android/view/WindowManagerImpl.java

/**
  * code 11
  */
public WindowManagerImpl createLocalWindowManager(Window parentWindow) {
        return new WindowManagerImpl(mContext, parentWindow);
}

private WindowManagerImpl(Context context, Window parentWindow) {
        mContext = context;
        mParentWindow = parentWindow;
}

這里還是實體化了一個WindowManagerImpl,和前面的區別在于SystemServiceRegistry靜態代碼塊中實體化的WindowManagerImpl建構式只有背景關系,而這次構造方法中傳入了Window,也就是說WindowManagerImpl持有了Window的參考,這樣的話就可以在window中進行增加洗掉view的操作了,接下來看addView方法:

/**
  * code 12
  */
private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();

@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
	applyDefaultToken(params);
	mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}

本以為WindowManagerImpl就是終點,沒想到真正對View操作的并不是它,而是WindowManagerGlobal,這里通過單例模式獲取其實體,并對view進行實際操作

到目前為止,我們可以大概梳理一下Window與WindowManager之間的關系:

PhoneWindow繼承于Window抽象類,本質上也是View.其內部通過setWindowManager方法與WindowManager產生關聯(實體化WindowManagerImpl)
ViewManager介面內部有對view進行添加洗掉更新的方法,WindowManager繼承ViewManager,WindowManagerImpl又繼承WindowManager
Window與WindowManager產生關聯,最后也就是兩者的實作類PhoneWindow與WindowManagerImpl系結
在WindowManagerImpl內部實際處理view的其實是WindowManagerGlobal(橋接模式)

在這里插入圖片描述

參考:

http://liuwangshu.cn/framework/wm/1-windowmanager.html
https://blog.csdn.net/weixin_41101173/article/details/79685305
https://blog.csdn.net/tonyandroid1984/article/details/71046368
Android開發藝術探索

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/264185.html

標籤：其他

上一篇：Android設備：外接掃碼槍與系統軟鍵盤問題

下一篇：Android TP驅動分析