-
WindowManager获取：
window作为一种视图抽象承载者，唯一的实现类是PhoneWindow，PhoneWindow中包含一个视图结构DecorView(FrameLayout 包含Title布局) 该View便是我们会addView时的视图根布局 包含结构如下图：
PhoneWindow 结构
添加Window时代码如下：
WindowManager windowManager = (WindowManager) activity.getSystemService(Context.WINDOW_SERVICE);
WindowManager windowManager = (WindowManager) getApplicationContext().getSystemService(Context.WINDOW_SERVICE);
上图中第一种获取的WindowManager是当前Activity窗口管理类WindowManagerImp，这个窗口管理实现类会有多个每个Activirty都会包含一个该实例，Activity销毁 该窗口管理器包含的视图也将销毁 。第二种是通过获取全局应用级别的WindowManagerImpl实现类 ，该窗口管理器包含的窗口个和Application的生命一样长，而平时遇到的其他非Activity类型的Context获取到的WindowManager都是代理到ContextImpl来具体获取，所以非Activity获取到的WindowManagerImpl均是同一个对象
下面是Activty获取WindowManager的实现：
Activity.class
@Override
public Object getSystemService(@ServiceName @NonNull String name) {
if (getBaseContext() == null) {
throw new IllegalStateException(
"System services not available to Activities before onCreate()");
}
if (WINDOW_SERVICE.equals(name)) {
return mWindowManager; // 返回当前Acticvty的成员变量mWindowManager
} else if (SEARCH_SERVICE.equals(name)) {
ensureSearchManager();
return mSearchManager;
}
return super.getSystemService(name);
}
该mWindowManager是在ActivityThread采用反射加载Activity之后调用Activity.attach()方法时，将当前Activity的PhoneWindow与WindowManager关联
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);
...
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE), //关联WindowManagerImpl
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
if (mParent != null) {
mWindow.setContainer(mParent.getWindow());
}
mWindowManager = mWindow.getWindowManager();// 将当前WindowManagerImpl赋值
mCurrentConfig = config;
mWindow.setColorMode(info.colorMode);
setAutofillCompatibilityEnabled(application.isAutofillCompatibilityEnabled());
enableAutofillCompatibilityIfNeeded();
}
继续看关联WindowManager代码：
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); // 获取WindowManagerService
}
mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this); // 创建一个WindowManagerImpl
}
对于使用Activity上下文获取的WindowManager是专门管理当前Activity得窗口实例 ，当前界面销毁时 ，该管理器管理的界面也都要回收销毁， 这个也就是Dialog和Popwindow这种子窗口的实现方式
而第二种方式是通过获取Aplication的上下文从而调用ContextWrap的getSystemService,因为Context的实现采用桥接设计模式将所有ContextWrap的实现交给ContextImpl来执行 创建application的代码：
ActivityThread.class - > makeApplication
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);
看出application的方法就是ContextImpl实现
ContextImpl.class
@Override
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
SystemServiceRegistry这个类是用来管理所有的系统Service的获取类,内部包含一个静态代码块,实例化系统服务的客户端调用的代理
SystemServiceRegistry.class
static{
...
registerService(Context.WINDOW_SERVICE, WindowManager.class,
new CachedServiceFetcher<WindowManager>() {
@Override
public WindowManager createService(ContextImpl ctx) {
return new WindowManagerImpl(ctx);
}});
...
}
因此第二种获取WindowManager才是作为与Applicatuon的全局唯一的WindowManagerImpl
-
Window与WindowManagerService交互
每WinowManagerImpl实例内部对View的操作也是通过获取WindowManagerGlobal这个类的单例来实现实现，WindowManagerGlobal内部将ViewRootImpl、view 、 windowmanager.params、刚才销毁的View存储起来：
WindowManagerGlobal.class
private final ArrayList<View> mViews = new ArrayList<View>();
private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
private final ArrayList<WindowManager.LayoutParams> mParams =
new ArrayList<WindowManager.LayoutParams>();
private final ArraySet<View> mDyingViews = new ArraySet<View>();
WindowManagerGlobal（后面统称wmg）通过Binder获取wms,然后wms同样通过Binder通信获取 IWindowSession.stub 的实现类Session ，Session类的注释:
Session 注释
Session与windowManager协同管理每个app的窗口交互，每个app拥有一个Session和一个全局的WindowManagerGlobal ,
Session与application关系
在wmg的setView以及update等View的操作又统统交给ViewRootImpl来实现,ViewRoorImpl在操作View展示以及跟新时调用wmg的静态方法获取IwindowSession.Stub实例，ViewRootImpl通过IWindowSession与WMS进行交互，IWindowSession定义在IWindowSession.aidl文件中,而ViewRootImpl的内部类 class W extends IWindow.Stub 作为在WMS操作后利用Binder通信的响应类，主要用来通知ViewRootImpl来进行View的调整等信息。
- Window类型
-
WindowManager.LayoutParams.TYPE_TOAST
Toast类型的窗口 由NMS管理 Android4.4之前该类型的窗口系统为其添加两个flags WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE | WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE 表明这种类型窗口无法获取焦点与交互行为 4.4 之后该类型的Toast取消了以上两个flag 而且这种类型窗口不需要SYSTEM_ALERT_WINDOW权限的申明 直到6.0 google也没有解决这个类似bug的漏洞，但是7.1 google 添加了一个限制 就是每一个Uid只能弹出一个该类型的窗口 不能重叠弹出 （由于国内rom定制需要具体分析 ），也就是说当你的target>25的时候也就是7.1的时候该类型的非系统app设置窗口类型为TYPE_TOAST会抛出BadToken异常，8.0 时google为了解决这些悬浮窗问题不用户用户使用TYPE_TOAST 、TYPE_PHONE、TYPE_SYSTEM_ALERT 如果设置为该类型会直接奔溃 必须修改为 TYPE_APPLICATION_OVERLAY -
WindowManager.LayoutParams.TYPE_PHONE （窗口类型和手机来电窗口级别一致）WindowManager.LayoutParams.TYPE_SYSTEM_ALERT（该窗口类型和与低电量系统提示窗口级别一致 ）
在6.0以前只需在Manifest中注册SYSTEM_ALERT_WINDOW权限即可，6.0以后可以通过Setting.canDrawOverLays来判断该权限授予情况 则需要条状到设置页面手动授权，6.0以前国内厂商可能也需要动态去授权改权限 -
TYPE_APPLICATION_OVERLAY
该窗口类型是Android8.0以后新增 为了统一之前版本对于用户随意使用悬浮窗导致混乱的情况 该窗口类型需要通过Setting.canDrawOverLays判断是否授权 如果未授权 通过一下代码跳转到允许悬浮窗权限界面
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + this.getPackageName()));
startActivityForResult(intent, OVERLAY_PERMISSION_REQ_CODE);
网友评论