自定义控件---基础入门篇

 Android系统内置了许多控件,如果这些控件不能满足需求,您可以自定义自己的控件,自定义的控件必须继承View类。


三种自定义控件的方式

  按实现方式来划分的话,自定义View分为三种:自绘控件、组合控件、以及继承控件。

-  自绘控件:View上所展现的内容全部都是我们自己绘制出来的。此种方式也是最难的,一般会通过直接继承View类来实现自定义控件。
-  继承控件:如果对已有的控件进行小调整就能满足需求,那么可以通过继承它们并重写onDraw()方法来实现自定义控件。比如,继承EditText使之产生了带有下划线的记事本页面。
-  组合控件:通过将几个系统原生的控件组合到一起,来实现自定义控件。比如,使用PopupWindowButton来组合出一个下拉列表框等。


  为了更好的理解自定义控件的各个步骤,在正式开始之前,我们先来了解一些相关的知识点:Activity的组成。

第一节 Activity的组成

  本节来介绍一下WindowWindowManagerServiceWindowManager三个类。

Window

  我们都知道,在Android中,屏幕上所显示的控件是以Activity为单位进行组织的。
  但是再深入点看的话,就会发现Activity其实主要是处理一些逻辑问题(比如生命周期的管理等),显示在屏幕上的控件并不是由它来管理的,而是交给了Window类。

  不信的话,可以打开Activity类的源码,看一下它的setContentView方法:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
       
       
       
       
private Window mWindow;
private WindowManager mWindowManager;
public void setContentView(@LayoutRes int layoutResID) {
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
}
public Window getWindow() {
return mWindow;
}
语句解释:
-  从上面可以发现,Activity会转调用Window类的setContentView方法。
-  再次声明,Android系统的源码每个版本之间都会有一些差别,所以笔者在本章以及以后章节中所贴出的源码,如果和你看到的源码不一致,那么请淡定!
   -  笔者使用的源码版本是:Android-23


  观察仔细点的话会发现Window是一个抽象类,为了能继续追踪源码,我们得先去查看mWindow是何时初始化的,进而找到实例化的是哪个类。
  查看的过程就不说了,直接说一下初始化的步骤吧:

-  首先,当我们请求启动某个Activity时,系统会调用它的无参构造方法实例化一个它的对象。
-  然后,会调用该对象的attach方法,执行初始化操作。
-  最后,mWindow的初始化操作,就是在attach方法中进行的。


  那么就来看一下Activity的attach方法的代码:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
       
       
       
       
final void attach( /*此处省略若干参数*/) {
mWindow = new PhoneWindow(this);
// 省略若干代码...
// 依据一些参数,来初始化WindowManager对象。
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
// 省略若干代码...
// 为mWindowManager属性赋值。
mWindowManager = mWindow.getWindowManager();
// 省略若干代码...
}
语句解释:
-  其实Window类官方文档已经告诉我们了,该类只有一个唯一的子类android.view.PhoneWindow-  如果继续追踪上面第8行代码的话,就可以知道mWindowManager所指向的对象将是WindowManagerImpl类型的。
-  用一句话概括:“当Activity被实例化之后,会接着初始化它的mWindow、mWindowManager属性”。


  继续追踪就会发现,我们调用setContentView方法设置给Activity的布局,最终会由PhoneWindow类的DecorView管理。

  这里先给出一个完整的示意图,后面会详细分析:


自定义控件---基础入门篇_第1张图片 Activity内部结构

  DecorViewPhoneWindow的内部类,继承自FrameLayout还有一点需要知道的是:

-  我们之所以说Activity的控件是由DecorView管理的,而不说是由PhoneWindow管理的,是因为:
   -  DecorView是一个真正的View对象,我们设置给Activity的布局,最终会被放到DecorView里面。
   -PhoneWindow并不是一个View


  回到刚才说的地方,我们来看一下PhoneWindow类的setContentView方法:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
       
       
       
       
public void setContentView( int layoutResID) {
// 省略若干代码...
// mContentParent就是上图的R.id.content所对应的布局。
if (mContentParent == null) {
// mContentParent没有值就意味着DecorView没被初始化,下面就去初始化。
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
// 如果已经初始化了,则删除现有的所有子View。
mContentParent.removeAllViews();
}
if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
// 将用户传递过来的布局,放入到mContentParent中。
mLayoutInflater.inflate(layoutResID, mContentParent);
}
// 省略若干代码...
}
语句解释:
-  这段代码用来检测DecorView是否初始化完毕,然后在将layoutResID所对应的布局放到DecorView中。


  接着看一下installDecorgenerateDecorgenerateLayout方法:

       
       
       
       
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
       
       
       
       
private void installDecor() {
if (mDecor == null) {
// 创建DecorView。
mDecor = generateDecor();
// 省略若干代码...
}
if (mContentParent == null) {
// 获取R.id.content所对应的布局,并把它赋值给mContentParent。
mContentParent = generateLayout(mDecor);
// 省略若干代码...
}
}
protected DecorView generateDecor() {
return new DecorView(getContext(), - 1);
}
protected ViewGroup generateLayout(DecorView decor) {
// 省略若干代码...
// 依据当前设备的情况来决定使用哪个布局。
int layoutResource;
int features = getLocalFeatures();
if ((features & ( 1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
layoutResource = R.layout.screen_swipe_dismiss;
} else if ((features & (( 1 << FEATURE_LEFT_ICON) | ( 1 << FEATURE_RIGHT_ICON))) != 0) {
// 省略若干代码...
} else if ((features & (( 1 << FEATURE_PROGRESS) | ( 1 << FEATURE_INDETERMINATE_PROGRESS))) != 0
&& (features & ( 1 << FEATURE_ACTION_BAR)) == 0) {
// 省略若干代码...
} else if ((features & ( 1 << FEATURE_CUSTOM_TITLE)) != 0) {
// 省略若干代码...
} else if ((features & ( 1 << FEATURE_NO_TITLE)) == 0) {
// 省略若干代码...
} else if ((features & ( 1 << FEATURE_ACTION_MODE_OVERLAY)) != 0) {
// 省略若干代码...
} else {
layoutResource = R.layout.screen_simple;
}
// 装载布局,并将它放入到DecorView中。
View in = mLayoutInflater.inflate(layoutResource, null);
decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
// 这个mContentRoot在上面的图中有标注。
mContentRoot = (ViewGroup) in;
// 从DecorView中查找出id为R.id.content的布局。
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
// 省略若干代码...
return contentParent;
}
public View findViewById(@IdRes int id) {
return getDecorView().findViewById(id);
}
语句解释:
-  至此也就看明白了,传递给setContentView方法的布局,最终会被放入到DecorView中。
-23行代码用来获取当前窗口配置,后面会依据该方法的返回值来决定使用哪个布局。
   -  例如,窗口配置类型包括FullScreen(全屏)、NoTitleBar(不含标题栏)等。


  另外,我们可以使用Activity的requestFeature()方法来修改窗口配置,不过该方法必须在setContentView之前调用
  从PhoneWindow类的requestFeature方法可以看出,若在setContentView之后修改窗口配置,会抛异常:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
       
       
       
       
@Override
public boolean requestFeature( int featureId) {
if (mContentParent != null) {
throw new AndroidRuntimeException( "requestFeature() must be called before adding content");
}
// 省略若干代码...
return super.requestFeature(featureId);
}


  默认情况下,DecorView内部只有一个子元素,也就是上面说的mContentRoot,而且mContentRoot一般是LinearLayout的子类,里面包含标题栏内容区域两部分:

       
       
       
       
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
       
       
       
       
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:fitsSystemWindows= "true"
android:orientation= "vertical"
android:layout_width= "match_parent"
android:layout_height= "match_parent">
<RelativeLayout android:id="@android:id/title_container"
style= "?android:attr/windowTitleBackgroundStyle"
android:layout_width= "match_parent"
android:layout_height= "?android:attr/windowTitleSize" >
RelativeLayout>
<FrameLayout android:id="@android:id/content"
android:layout_width= "match_parent"
android:layout_height= "0dip"
android:layout_weight= "1"
android:foregroundGravity= "fill_horizontal|top"
android:foreground= "?android:attr/windowContentOverlay"
/>
LinearLayout>
语句解释:
-  我们调用Activity的setContentView()方法设置的布局,最终会以子结点的形式加入到这个FrameLayout中。


  比如,我们可以在Activity中通过代码来控制内容区域的显示与隐藏。
  范例1:隐藏contentView

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
       
       
       
       
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// FrameLayout的id为android.R.id.content。
findViewById(android.R.id.content).setVisibility(View.GONE);
}
}
语句解释:
-  您可以直接输出findViewById(android.R.id.content)的值来验证是否是一个帧布局。
-  你也可以在onCreate方法中隐藏掉标题栏、状态栏,具体的代码请自行搜索。

WindowManagerService

  通过上面的分析,我们知道DecorView是何时创建的了,但它是如何被添加到屏幕上的呢?

答案是:通过WindowManagerService类来完成的。


  下面给出一张示意图:


自定义控件---基础入门篇_第2张图片 Activity深层结构图

  我们从下往上看这张图,整个图分为三部分:

-  SdkClient部分表示Activity的内部结构,由PhoneWindowDecorView组成。
-  FrameworkServer端用来完成整个Android系统的窗口、事件捕获和分发、输入法等的控制。
-  FrameworkClient用来连接SdkClient端和FrameworkServer端,它通过Binder机制让两者进行(跨进程)通信。
   -  也就是说,WindowManagerService(简称WMS)只会和ViewRoot类通信,DecorView也只会和ViewRoot通信。


添加Activity到屏幕
  比如我们现在新建一个Activity,那么此时系统会这么执行:

-  第一,先实例化Activity对象,然后调用attach方法初始化,然后在setContentView被调用时初始化DecorView-  第二,当需要显示Activity时,系统会使用WindowManager类来将DecorView添加到屏幕上。
-  第三,但WindowManager并不会执行添加操作,它会为DecorView创建一个ViewRoot对象,然后再请ViewRoot去添加。
-  第四,但ViewRoot实际上也不会执行添加操作,它会使用Binder机制(跨进程)访问远程的WMS类,也就是说添加操作会由WMS来完成。

  上面只是说了一下大体执行步骤,下面就来跟随源码一起,观察一个新Activity被添加到屏幕中的过程。


  第一步,当系统准备resume一个Activity时,会调用ActivityThreadhandleResumeActivity方法:

       
       
       
       
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
       
       
       
       
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume) {
// 省略若干代码...
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (a.mVisibleFromClient) {
a.mWindowAdded = true;
wm.addView(decor, l);
}
// If the window has already been added, but during resume
// we started another activity, then don't yet make the
// window visible.
} else if (!willBeVisible) {
if (localLOGV) Slog.v(
TAG, "Launch " + r + " mStartedActivity set");
r.hideForNow = true;
}
// 省略若干代码...
}
语句解释:
-  从第17行代码可以看出来,系统会调用WindowManager的addView方法来将DecorView添加到屏幕上。
-  通过前面的分析可以知道,实际上调用的是WindowManagerImpl类的addView方法。
-  继续跟进的话,就会看到最终会调用WindowManagerGlobal的addView方法。


  第二步,查看WindowManagerGlobal类的addView方法:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
       
       
       
       
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
// 省略若干代码...
ViewRootImpl root;
View panelParentView = null;
// 省略若干代码...
root = new ViewRootImpl(view.getContext(), display);
// 省略若干代码...
root.setView(view, wparams, panelParentView);
// 省略若干代码...
}
语句解释:
-  此方法里创建一个ViewRootImpl对象,这个对象很重要:
   -WMS需要分发事件、绘制控件时都会通知ViewRootImpl,然后再由ViewRootImpl来通知DecorView   -  相应的,当想往屏幕上添加控件时,也得通过ViewRootImpl类来将控件传递给WMS-15行代码调用了ViewRootImpl的setView方法,同时将DecorView传递过去。


  第三步,查看ViewRootImpl类的setView方法:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
       
       
       
       
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
// 持有DecorView的引用。
mView = view;
// 省略若干代码...
// 调用WindowManagerService来执行添加操作。
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(),
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mInputChannel);
// 省略若干代码...
}
语句解释:
-  此方法第4行代码,首先保存了DecorView的引用,因为以后会用到它。
-  然后调用addToDisplay方法来请求WMS执行一些初始化操作。
-  当然此时屏幕上还没有绘制任何内容,不过我们就不继续向下深入了,只需要知道控件的绘制等操作是在WMS那端完成的即可。


分发输入事件
  除了负责往屏幕上添加和删除控件外,WMS还会用来分发输入事件。

  以触摸事件为例:

触摸事件是由Linux内核的一个Input子系统来管理的(InputManager),Linux子系统会在/dev/input/这个路径下创建硬件输入设备节点(这里的硬件设备就是我们的触摸屏了)。当手指触动触摸屏时,硬件设备通过设备节点像内核(其实是InputManager管理)报告事件,InputManager经过处理将此事件传给Android系统的一个系统Service —— WindowManagerService 。


  当WMS接收到一个输入事件时,会按照下面的路线传递:

-  首先,把事件传递给当前前台ActivityViewRootImpl类。
-  然后,ViewRootImpl又会将事件传递给它的内部类ViewPostImeInputStage,该类依据事件的类型来调用不同的方法:
   -  processPointerEvent方法:处理触屏事件。
   -  processTrackballEvent方法:处理轨迹球事件。
   -  processKeyEvent方法:处理键盘事件。

  接着,同样以触屏事件为例,processPointerEvent方法在接到事件后,源代码如下所示:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
       
       
       
       
private int processPointerEvent(QueuedInputEvent q) {
final MotionEvent event = (MotionEvent)q.mEvent;
mAttachInfo.mUnbufferedDispatchRequested = false;
// 将事件传递给DecorView的dispatchPointerEvent方法。
boolean handled = mView.dispatchPointerEvent(event);
if (mAttachInfo.mUnbufferedDispatchRequested && !mUnbufferedInputDispatch) {
mUnbufferedInputDispatch = true;
if (mConsumeBatchedInputScheduled) {
scheduleConsumeBatchedInputImmediately();
}
}
return handled ? FINISH_HANDLED : FORWARD;
}
语句解释:
-  从第6行代码可以看到调用了DecorView的dispatchPointerEvent方法,该方法继承自View类。

  接着来看一下View类的dispatchPointerEvent方法:

       
       
       
       
1
2
3
4
5
6
7
8
       
       
       
       
public final boolean dispatchPointerEvent(MotionEvent event) {
// 如果当前处于触摸模式,则调用View类的dispatchTouchEvent方法。
if (event.isTouchEvent()) {
return dispatchTouchEvent(event);
} else {
return dispatchGenericMotionEvent(event);
}
}
语句解释:
-  就像我们看到的那样,一般情况下,会接着转调用View类的dispatchTouchEvent方法。

  接着,看一下DecorViewdispatchTouchEvent方法:

       
       
       
       
1
2
3
4
5
       
       
       
       
public boolean dispatchTouchEvent(MotionEvent ev) {
final Callback cb = getCallback();
return cb != null && !isDestroyed() && mFeatureId < 0 ? cb.dispatchTouchEvent(ev)
: super.dispatchTouchEvent(ev);
}
语句解释:
-  这里的Callback是一个关键点,实际上它就是DecorView所属的Activity-Activity的attach方法中可以找到初始化的代码:
   -  mWindow.setCallback(this);


  分析到此也就明白了,输入事件的传递顺序为:

WMS -> ViewRootImpl -> DecorView -> Activity 


执行绘制操作
  与分发输入事件的过程类似,当系统需要绘制Activity的界面时,也会执行下面的步骤:

-  首先,调用ViewRootImpl的performTraversals方法。
-  然后,该方法依据具体的情况来调用不同的子方法:
   -  performMeasure方法:执行测量操作。其内部会转调用DecorView的measure方法。
   -  performLayout方法:执行布局操作。其内部会转调用DecorView的layout方法。
   -  performDraw方法:执行绘制操作。其内部会转调用DecorView的draw方法。

  其实DecorView类的measurelayoutdraw三个方法都是继承自View类,而且我们稍后也会遇到它,所以此处先将它们列出来,混脸熟。


本节参考阅读:

  • Android 窗口管理
  • Android Touch事件的分发过程
  • Android 事件分发机制详解

WindowManager

  ActivityDialogToast里的控件,都是通过WindowManager来添加到屏幕上的,因此我们先来看一看该类的用法。

基础用法

  接下来,从最简单的范例开始,一步步的介绍WindowManager类。


  范例1:添加一个TextView

       
       
       
       
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
       
       
       
       
public class MainActivity extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// 将Activity的引用传递过去。
addViewToScreen( this);
}
private void addViewToScreen(Context context){
// 首先,获取一个WindowManager对象。
WindowManager manager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
// 然后,创建布局参数。
WindowManager.LayoutParams params = new WindowManager.LayoutParams();
params.width = WindowManager.LayoutParams.WRAP_CONTENT;
params.height = WindowManager.LayoutParams.WRAP_CONTENT;
// 接着,创建一个按钮。
Button button = new Button(context);
button.setOnClickListener( new View.OnClickListener() {
public void onClick(View v) {
Toast.makeText(getApplicationContext(), "click", Toast.LENGTH_SHORT).show();
}
});
button.setText( "请点击这个按钮");
// 最后,将载入的内容放到屏幕中。
manager.addView(button, params);
}
}
语句解释:
-  添加到屏幕上的View对象,既可以是使用LayoutInflater来载入一个布局文件,也可以是通过代码来new出来的View对象。
-  运行本范例时,我们就可以在屏幕的中央看到按钮了。


  程序运行后就会发现一个问题:

-  除了按钮之外屏幕上的任何东西都没法点击了。
-  这是因为,默认情况下,通过WindowManager添加到屏幕中的控件会拦截所有事件。


  我们可以通过给WindowManager.LayoutParams类的flags属性设置值来解决这个问题:

       
       
       
       
1
2
       
       
       
       
params.flags =
WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL | WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
语句解释:
-  FLAG_NOT_FOCUSABLE表示View不需要获取焦点,也不需要接收各种输入事件,此标记会同时启用FLAG_NOT_TOUCH_MODAL-  FLAG_NOT_TOUCH_MODAL表示系统会将View区域以外的单击事件传递给底层控件,区域以内的单击事件则由View自己处理。
-  FLAG_SHOW_WHEN_LOCKED可以让Window对象显示在锁屏界面上,这个Flag需要作用到Window对象上,具体用法请自行搜索。
-  如果想为LayoutParams指定多个flag,则flag之间使用“|”间隔。


  解决了这个问题之后,又发现如果我们点击Home键,那么屏幕上的按钮就会随着Activity一起被切到后台。
  如果想让按钮一直显示在屏幕上,而不随着Activity一起隐藏,那么可以这么写:

       
       
       
       
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
       
       
       
       
public class MainActivity extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// 将Activity的引用传递过去。
addViewToScreen(getApplicationContext());
}
private void addViewToScreen(Context context) {
WindowManager manager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
WindowManager.LayoutParams params = new WindowManager.LayoutParams();
params.flags = WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL;
// 为type字段赋值。
params.type = WindowManager.LayoutParams.TYPE_PHONE;
params.width = WindowManager.LayoutParams.WRAP_CONTENT;
params.height = WindowManager.LayoutParams.WRAP_CONTENT;
Button button = new Button(context);
button.setOnClickListener( new View.OnClickListener() {
public void onClick(View v) {
System.out.println( "click");
Toast.makeText(getApplicationContext(), "click", Toast.LENGTH_SHORT).show();
}
});
button.setText( "请点击这个按钮");
manager.addView(button, params);
}
}
语句解释:
-  本范例中主要修改了两处代码,这两处缺一不可:
   -  将传递给addTextViewToScreen()方法的Activity对象改为Application对象。
   -  将params.type属性赋值为TYPE_PHONE。常用取值为:
      -  TYPE_PHONE :手机级别,即表示在所有应用程序之上,但在状态栏之下。
      -  TYPE_SYSTEM_ALERT :系统窗口级别。比如:显示电量低时弹出的Alert对话框。
      -  TYPE_SYSTEM_OVERLAY :系统窗口之上的级别,此级别的控件无法响应点击事件。
-  创建浮动窗需要添加下面这个权限:
   -  android:name="android.permission.SYSTEM_ALERT_WINDOW" />
-  如果你是小米手机则默认是无法在屏幕上添加View的,去应用程序设置里,把权限给打开即可。


优先级
  事实上WindowManager中可以放置很多个View(控件),控件之间有优先级之分,优先级高的将被放到优先级低的上面。若最高优先级控件的宽高是“MATCH_PARENT”,则其下面的控件都将被完全遮住,若优先级相同则后加入的会被放到上面显示

  我们来看一下下面的代码:

       
       
       
       
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
       
       
       
       
public class MainActivity extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
addTextViewToScreen(getApplication(), WindowManager.LayoutParams.TYPE_PHONE, "Phone1");
addTextViewToScreen(getApplication(), WindowManager.LayoutParams.TYPE_PHONE, "Phone2");
addTextViewToScreen(getApplication(), WindowManager.LayoutParams.TYPE_SYSTEM_OVERLAY, "Overlay");
addTextViewToScreen(getApplication(), WindowManager.LayoutParams.TYPE_SYSTEM_ALERT, " Alert ");
addTextViewToScreen(getApplication(), WindowManager.LayoutParams.TYPE_PHONE, "Phone3");
}
static int offsetY;
private void addTextViewToScreen(Context context, int type, String text){
WindowManager manager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
WindowManager.LayoutParams params = new WindowManager.LayoutParams();
params.width = WindowManager.LayoutParams.WRAP_CONTENT;
params.height = 70;
params.type = type;
// 设置View在y轴上的坐标值,相应的也可以设置x值。
params.y = offsetY;
offsetY += 60;
TextView textView = new TextView(context);
textView.setText(text);
manager.addView(textView, params);
}
}


  程序的运行效果为:


自定义控件---基础入门篇_第3张图片


  从上图可以看出:

-  Phone2Phone1是同级别的,但是Phone2却在Phone1上面。
-  Overlay的级别最高,所以它压在了Phone2上面。
-  Alert的级别第二高,虽然是在Overlay之后添加的,但是它任然被放到了Overlay下面。
-  Phone3被压在了Alert下面。


删除和更新


  范例1:从屏幕中移除一个已经存在的控件。

       
       
       
       
1
       
       
       
       
windowManager.removeView(destView);


  范例2:更新屏幕中一个已经存在的控件。

       
       
       
       
1
2
3
4
       
       
       
       
// 让y轴坐标偏移100个像素
mParams.y += 100;
// 依据最近的mParams中的信息(x、y、width、height等)来重新设置view的显示效果。
mWindowManager.updateViewLayout(view, mParams);
语句解释:
-  这里所说的更新控件,其实就是更新控件的LayoutParams对象。


百度安全卫士

  如果你基础不错的话,通过上面学的知识,就可以模仿360的小火箭特效了(具体请参考郭霖的博客),笔者仿写了一个百度安全卫士内存清理动画的Demo,程序运行效果如下:



  从上图中可以看出,仿写的效果和正牌还是有一些差距的,但是通过这个Demo可以让大家更深刻的理解WindowManager类可以做哪些事情。

  点击下载源码

  如果你没有Android Studio环境,那么可以去AndroidTest\app\build\outputs\apk目录找到apk直接安装运行。


本节参考阅读:

  • Android桌面悬浮窗效果实现,仿360手机卫士悬浮窗效果
  • Android桌面悬浮窗进阶,QQ手机管家小火箭效果实现

第二节 Hello World

  为了对自定义控件有个整体的认识,接下来我们先来写一个HelloWorld,其中涉及到的知识后面会详细介绍。


  范例1:MyView

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
       
       
       
       
// 所有自定义控件都必须继承View或View的子类。
public class MyView extends View {
// 当通过代码来创建View对象时(通过new关键字),调用此方法初始化View。
public MyView(Context context) {
super(context);
}
// 当通过XML标签来创建View对象时,调用此方法。
public MyView(Context context, AttributeSet attrs) {
super(context, attrs);
}
}
语句解释:
-  我们有两种方式来创建View对象:
   -  第一种,在代码中通过new关键字,直接实例化View对象。
   -  第二种,在XML中使用标签来创建View对象。
-  这两种方式分别会导致上面两个构造方法的调用。


  然后,我们来重写onDraw方法,该方法继承自View类,当系统需要绘制某个View时,就会调用该View对象的onDraw方法执行绘制操作。


  范例2:MyView

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
       
       
       
       
public class MyView extends View {
// 当通过代码来创建View对象时(通过new关键字),调用此方法初始化View。
public MyView(Context context) {
super(context);
}
// 当通过XML标签来创建View对象时,调用此方法。
public MyView(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
// 在当前控件上写一行文字。
Paint p = new Paint();
p.setTextSize( 72);
canvas.drawText( "Hello World!!!", 0, 100, p);
}
}
语句解释:
-  对于onDraw方法里的代码,暂且知道它们的作用即可,每行代码的具体含义后面会有详细的介绍。


  接着,在布局文件中使用我们自定义的控件:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
       
       
       
       
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation= "vertical"
android:layout_width= "match_parent"
android:layout_height= "match_parent">
<com.cutler.demo.common.view.MyView
android:layout_width= "wrap_content"
android:layout_height= "wrap_content" />
LinearLayout>
语句解释:
-  使用自定义控件时,控件的名称要包含包名。
-  由于笔者将MyView放到了com.cutler.demo.common.view包中,所以才这么写。


  最后,程序的运行效果如下图所示:


自定义控件---基础入门篇_第4张图片


  提示:

-Android中,View类占据了屏幕上一个“矩形区域”,并负责绘制和处理事件。
-  从整体上来看,Activity内的所有View按照从上到下的顺序,排列成了一个“树型结构”,我们把这个树形结构称为“View树”、“视图树”。

第三节 生命周期方法

  在继承了View类且重写完构造方法后,接着你就可以根据自己的需要来重写View所提供的一些回调方法了。你不需要重写所有的方法,实际上你可以从仅重写onDraw(android.graphics.Canvas)方法开始,但是本节将会详细讲解View类的各个回调方法的调用时机。

  首先,要知道的是,任何一个视图都不可能凭空突然出现在屏幕上,它们都是要经过非常科学的绘制流程后才能显示出来的。
  然后,当Activity获取焦点的时候,它就需要绘制它的View树了。
  接着,整个View树会从根节点开始,依次执行绘制。
  最后,每个View对象从创建到结束的整个生命周期中,会经历多个阶段创建、布局、绘制、事件处理、焦点等,每个阶段中都提供了一个或多个回调方法。

创建阶段

  在View的创建阶段中,框架会首先调用该View的构造方法进行对象的初始化,通常在你自定义的View类中会定义两个不同的构造器,并在其内部来调用父类的构造器。

  在构造方法返回之后,系统会进行如下判断:

-  若当前控件继承自View类,则构造方法执行完毕后会接着调用它的onFinishInflate方法。
-  若当前控件继承自ViewGroup或其子类,则将在当前控件的所有子View的onFinishInflate方法都调用完成后,才会调用它的onFinishInflate方法。


  onFinishInflate方法的一个比较常见的应用场景是:

-  你自定义了一个ViewGroup,它支持在XML文件中使用,这就不可避免的在它的标签里包含其它子标签。
-  如果你想在代码中获取到它的子标签的引用,那么就应该在这个方法里写,而不是在构造方法里。这是因为,当ViewGroup的此方法被调用时,意味着它所包含的所有子控件也都加载完了(但只是加载完毕,宽高什么的都没测量)。


  假设我们有如下的布局文件:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
       
       
       
       
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation= "vertical"
android:layout_width= "match_parent"
android:layout_height= "match_parent">
<com.cutler.demo.common.view.MyViewGroup
android:layout_width= "match_parent"
android:layout_height= "match_parent">
<com.cutler.demo.common.view.MyView
android:id= "@+id/myView"
android:layout_width= "wrap_content"
android:layout_height= "wrap_content" />
com.cutler.demo.common.view.MyViewGroup>
LinearLayout>


  然后,MyViewGroup类的代码为:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
       
       
       
       
public class MyViewGroup extends LinearLayout {
private MyView myView;
public MyViewGroup(Context context) {
super(context);
}
public MyViewGroup(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
protected void onFinishInflate() {
super.onFinishInflate();
myView = (MyView) findViewById(R.id.myView);
}
}
语句解释:
-  程序运行是,会按照下面的顺序调用:
   -  首先,调用MyViewGroup的构造方法。
   -  然后,调用MyView的构造方法。
   -  接着,调用MyView的onFinishInflate方法。
   -  最后,再调用MyViewGroup的onFinishInflate方法。


  注意:如果你的控件不是从XML中创建的(而是通过代码new出来的),那么不会导致onFinishInflate方法调用。


  创建阶段完成后,还有三个比较重要的阶段:测量布局绘制

测量阶段

  测量(measure)指的是对View的尺寸进行测量,因为父控件只有知道了每个子View的尺寸之后,它才能正确的摆放子View(比如防止子View重叠等)。
  因此在创建完View之后,系统首先要做的就是测量View的尺寸。


  前面已经分析过,当系统需要测量View时,会调用DecorViewmeasure方法,它内部的代码如下:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
       
       
       
       
public final void measure( int widthMeasureSpec, int heightMeasureSpec) {
// 省略若干代码...
if (cacheIndex < 0 || sIgnoreMeasureCache) {
// measure ourselves, this should set the measured dimension flag back
onMeasure(widthMeasureSpec, heightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
// 省略若干代码...
}
语句解释:
-  measure方法定义在View中,并且是final的,子类没法去重写它。
-  简单的说在measure方法内,就做了三件事:
   -  首先,在测量之前执行一些预处理操作。
   -  然后,在上面第7行代码中调用了onMeasure方法,开始正式的测量工作。
   -  最后,对测量的结果进行收尾处理。
-  由于一个View到底需要多少宽高只有它自己才知道,因此系统在View类中提供了onMeasure()方法供子类重写,你只需要在该方法内部执行测量操作即可,当然可以不重写它,因为View提供了默认的实现。


  在讲解如何重写onMeasure()方法进行测量之前,需要先介绍一下MeasureSpec类。

MeasureSpec

  首先让MyView类重写onMeasure方法,但是在其内部会直接调用父类的实现:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
       
       
       
       
public class MyView extends View {
public MyView(Context context) {
super(context);
}
public MyView(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
// 我们不做任何操作,只是输出参数的值。
System.out.println(widthMeasureSpec + "," + heightMeasureSpec);
}
}
语句解释:
-  从onMeasure方法的两个参数的名字来看,它们应该是表示宽度和高度,但是在程序运行时输出的值却是类似于:
   -  -2147482568,-2147481937
   -  1073742904,-2147481937
-  这他妈根本看不懂啊,逗爹呢? 


  其实onMeasure方法的两个参数虽然是int类型的,但是我们称它们为MeasureSpec

-  MeasureSpec是一个32位的int值,高2位代表SpecMode(测量模式),低30位代表SpecSize(测量尺寸)。
-  MeasureSpec通过将SpecModeSpecSize打包成一个int值来避免过多的对象内存分配。而且为了方便操作,MeasureSpec类提供了打包和解包的方法。
-  SpecModeSpecSize也使用int值表示。

  总之一句话,“系统之所以使用int值,就是为了节省内存分配,这样只需要使用1个int值就能表示两个数据”。


  既然这两参数是混合值,那么在使用它们之前,首先得使用MeasureSpec类来拆分出SpecModeSpecSize

  范例1:获取modesize

       
       
       
       
1
2
3
4
5
6
7
8
9
10
       
       
       
       
protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
// 获取widthMeasureSpec中的mode值。
int widthMode = MeasureSpec.getMode(widthMeasureSpec);
// 获取widthMeasureSpec中的size值。
int widthSize = MeasureSpec.getSize(widthMeasureSpec);
int heightMode = MeasureSpec.getMode(heightMeasureSpec);
int heightSize = MeasureSpec.getSize(heightMeasureSpec);
}


  其中size指的是尺寸,mode指的是模式,常见的模式有:

-  MeasureSpec.EXACTLY:精确尺寸。
   -  当控件的layout_width或layout_height指定为具体数值(如50dip)或FILL_PARENT时,mode的值会为EXACTLY   -  当mode是EXACTLY时,表示父视图希望子视图的大小应该是由size的值来决定的。
-  MeasureSpec.AT_MOST:最大尺寸。
   -  当控件的layout_width或layout_height指定为WRAP_CONTENT时,mode的值会为AT_MOST
   -  当mode是AT_MOST时,size给出了父控件允许的最大尺寸,此时控件尺寸只要不超过父控件允许的最大尺寸即可。
-  MeasureSpec.UNSPECIFIED:未指定尺寸。
   -  这种情况比较少见,不太会用到,笔者也没搞清楚。


  从上面的描述可以看出来,MeasureSpec的值与LayoutParams有关系,下面就具体介绍。

LayoutParams

  当系统需要测量控件尺寸时,会从DecorView开始,从上到下依次测量View树中的每一个控件。在测量时,每一个子View的onMeasure方法的参数,都是由其父View传递过来的。

父View会综合自身的情况以及子控件的LayoutParams来计算出需要传递给子控件的MeasureSpec值。


  而且,DecorView和普通View的MeasureSpec的计算过程略有不同,我们分开来看。


DecorView
  对于DecorView来说,它的MeasureSpec值是在ViewRootImpl中的measureHierarchy方法中计算的,代码:

       
       
       
       
1
2
3
4
       
       
       
       
// desiredWindowWidth和desiredWindowHeight是屏幕的尺寸
childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth, lp.width);
childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight, lp.height);
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

  接着再看一下getRootMeasureSpec方法的代码:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
       
       
       
       
private static int getRootMeasureSpec( int windowSize, int rootDimension) {
int measureSpec;
switch (rootDimension) {
case ViewGroup.LayoutParams.MATCH_PARENT:
// Window can't resize. Force root view to be windowSize.
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY);
break;
case ViewGroup.LayoutParams.WRAP_CONTENT:
// Window can resize. Set max size for root view.
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
break;
default:
// Window wants to be an exact size. Force root view to be that size.
measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
break;
}
return measureSpec;
}
语句解释:
-  静态方法MeasureSpec.makeMeasureSpec用来将两个普通的int值合成一个MeasureSpec值。
-  上面的代码已经表示的很清楚了,ViewRootImpl会依据DecorViewLayoutParams的值以及窗口的尺寸来计算出DecorViewMeasureSpec


普通View
  对于普通View来说,它的measure方法是由ViewGroup调用的,先来看一下ViewGroup的measureChildWithMargins方法:

       
       
       
       
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
       
       
       
       
protected void measureChildWithMargins(View child, int parentWidthMeasureSpec, int widthUsed,
int parentHeightMeasureSpec, int heightUsed) {
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin + widthUsed, lp.width);
final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin + heightUsed, lp.height);
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
public static int getChildMeasureSpec( int spec, int padding, int childDimension) {
int specMode = MeasureSpec.getMode(spec);
int specSize = MeasureSpec.getSize(spec);
int size = Math.max( 0, specSize - padding);
int resultSize = 0;
int resultMode = 0;
switch (specMode) {
// Parent has imposed an exact size on us
case MeasureSpec.EXACTLY:
if (childDimension >= 0) {
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size. So be it.
resultSize = size;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent has imposed a maximum size on us
case MeasureSpec.AT_MOST:
if (childDimension >= 0) {
// Child wants a specific size... so be it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size, but our size is not fixed.
// Constrain child to not be bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent asked to see how big we want to be
case MeasureSpec.UNSPECIFIED:
if (childDimension >= 0) {
// Child wants a specific size... let him have it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size... find out how big it should
// be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size.... find out how
// big it should be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
}
break;
}
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
语句解释:
-  从代码中也可以容易看出来,子View的MeasureSpec值,是由其父容器的MeasureSpec和子View的LayoutParams来确定的。


开始测量

  稍微总结一下,我们现在知道的知识有:

-  第一,当需要测量View的时,系统会从DecorView开始自上向下的测量每一个View-  第二,不论是DecorView还是普通的View,它们的MeasureSpec都是由它的上级传递过来的。
   -  对于DecorView来说,它的MeasureSpec是由屏幕的尺寸和它自身的LayoutParams决定的。
   -  对于普通View来说,它的MeasureSpec是由父View剩余空间和它自身的LayoutParams决定的。
      -  比如,若父ViewGroup的layout_height值为100,子View的值为200,则最终传入到子View的高度就是200
-  第三,当系统需要测量某个View时,会调用View类的onMeasure方法。
-  第四,MeasureSpec是一个复合的int值,在使用之前需要将它们拆解。


  需要说的是,普通View和ViewGroup的重写onMeasure方法时是有区别的:

-  普通View只需要在onMeasure中测量自己的尺寸即可。
-  ViewGroup除了完成自己的测量过程外,还会遍历去调用其所有子View的measure方法,各个子View再递归去执行这个流程。


普通View的重写

  范例1:重写onMeasure方法。

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
       
       
       
       
public class MyView extends View {
public MyView(Context context) {
super(context);
}
public MyView(Context context, AttributeSet attrs) {
super(context, attrs);
}
protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
// 什么都不干,直接设置MyView的宽高为300*300像素,注意此处的单位是px,而不是dp。
setMeasuredDimension( 300, 300);
}
}
语句解释:
-  当系统调用onMeasure方法时,就是在要求View执行测量了。
-  View测量完毕时需要将测量结果给保存起来,但是由于Java方法只能返回一个值,没法同时将宽度和高度一起返回,所以系统给我们提供一个setMeasuredDimension方法,我们把测量的结果传递过去即可。
-  在实际开发中,很少会像上面那样把MyView的尺寸写死在代码上,而是会依据widthMeasureSpec和heightMeasureSpec的值来动态的计算出MyView的尺寸。


  当然我们也可以不重写onMeasure方法,而是使用父类的实现:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
       
       
       
       
protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}
public static int getDefaultSize( int size, int measureSpec) {
int result = size;
int specMode = MeasureSpec.getMode(measureSpec);
int specSize = MeasureSpec.getSize(measureSpec);
switch (specMode) {
case MeasureSpec.UNSPECIFIED:
result = size;
break;
case MeasureSpec.AT_MOST:
case MeasureSpec.EXACTLY:
result = specSize;
break;
}
return result;
}


  总结一下onMeasure方法:

-  若没有重写onMeasure方法,则会按照View类的默认方式处理:
   -  通常情况下View对象的测量尺寸就是layout_width和layout_height所设置的值。
   -  在少数情况下,View对象的测量尺寸是getSuggestedMinimumWidth和getSuggestedMinimumHeight方法返回的。
-  若重写了onMeasure方法,则View对象的测量尺寸就是你在onMeasure方法里测量的结果。
   -  但是onMeasure方法测出的宽度和高度不一定就是View最终的宽高。
   -  测量宽高会受到View对象父View的约束,若父控件最大允许的宽度为100px,但子View测量的宽度为200px,最终子控件只会显示前100px的宽度,超出的部分不会被显示,除非加上滚动条。


  注意,视图实际拥有两对宽度和高度的值

-  第一对被称作测量宽度和测量高度。
   - 这两个尺寸表示View在其父View中需要的大小,也就是我们在onMeasure方法里计算出来的宽高。
   - View对象的measure()返回时,就可以通过getMeasuredWidth()和getMeasuredHeight()方法来获得测量宽高。
-  第二对被简单的称作宽度和高度,或绘制宽度和绘制高度   -  这两个尺寸表示View最终在屏幕上的实际大小,不过在少数情况下,绘制宽高可能与测量宽高不同。
   -  View对象的onLayout()被调用时,就可以通过getWidth()方法和getHeight()方法来获取视图的宽高了。


  说了这么多,也许你还是不知道怎么重写onMeasure方法,没关系,后面会有实战范例,不要慌!


ViewGroup的重写
  事实上,ViewGroup类并没有重写onMeasure方法,而是交给它的子类来重写了。

  下面是LinearLayout类的onMeasure方法:

       
       
       
       
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
       
       
       
       
protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
if (mOrientation == VERTICAL) {
measureVertical(widthMeasureSpec, heightMeasureSpec);
} else {
measureHorizontal(widthMeasureSpec, heightMeasureSpec);
}
}
void measureVertical( int widthMeasureSpec, int heightMeasureSpec) {
// 此处省略若干行代码
// 遍历测量每一个子View。
for ( int i = 0; i < count; ++i) {
// 此处省略若干行代码
measureChildBeforeLayout(
child, i, widthMeasureSpec, 0, heightMeasureSpec,
totalWeight == 0 ? mTotalLength : 0);
// 此处省略若干行代码
}
// 此处省略若干行代码
// 当所有子View都测量完毕后,再测量自己的尺寸。
mTotalLength += mPaddingTop + mPaddingBottom;
int heightSize = mTotalLength;
heightSize = Math.max(heightSize, getSuggestedMinimumHeight());
int heightSizeAndState = resolveSizeAndState(heightSize, heightMeasureSpec, 0);
heightSize = heightSizeAndState & MEASURED_SIZE_MASK;
// 此处省略若干行代码
setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),
heightSizeAndState);
// 此处省略若干行代码
}
void measureChildBeforeLayout(View child, int childIndex,
int widthMeasureSpec, int totalWidth, int heightMeasureSpec, int totalHeight) {
measureChildWithMargins(child, widthMeasureSpec, totalWidth, heightMeasureSpec, totalHeight);
}
protected void measureChildWithMargins(View child,
int parentWidthMeasureSpec, int widthUsed, int parentHeightMeasureSpec, int heightUsed) {
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
// 调用getChildMeasureSpec方法,综合自身和当前子View的尺寸信息,计算出子View最终的测量尺寸。
final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin + widthUsed, lp.width);
final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin + heightUsed, lp.height);
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}


  提示:父视图可能在它的子视图上调用一次以上的measure(int,int)方法。

布局阶段

  当所有View都测量完毕后,就需要设置它们的位置了,这个过程同样是从DecorView开始,调用的方法为layout()


  首先,我们来看下View.java中的layout()方法的源码:

       
       
       
       
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
31
32
33
34
35
36
       
       
       
       
public void layout( int l, int t, int r, int b) {
if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) {
onMeasure(mOldWidthMeasureSpec, mOldHeightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
int oldL = mLeft;
int oldT = mTop;
int oldB = mBottom;
int oldR = mRight;
// 调用setFrame或setOpticalFrame方法来修改当前View的位置。
// 注意:这个位置是当前控件在父View内的相对位置,原点是父View的左上角。
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
// 如果上面修改成功了,或者用户强制要求更新,则回调onLayout()方法。
onLayout(changed, l, t, r, b);
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;
ListenerInfo li = mListenerInfo;
// 回调所有注册过的(如果有的话)listener的onLayoutChange()方法。
if (li != null && li.mOnLayoutChangeListeners != null) {
ArrayList listenersCopy =
(ArrayList)li.mOnLayoutChangeListeners.clone();
int numListeners = listenersCopy.size();
for ( int i = 0; i < numListeners; ++i) {
listenersCopy. get(i).onLayoutChange( this, l, t, r, b, oldL, oldT, oldR, oldB);
}
}
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
}
语句解释:
-  从第3行代码可以看出来,在View的layout阶段也有可能调用onMeasure方法。


  关于onLayout()方法:

-  当需要确定当前View的所有子View的位置时,才会调用onLayout方法。
-  对于普通的View类来说,由于它是没有子View的,因此View类的onLayout()只是一个空实现。
-  对于ViewGroup类来说,在它内部onLayout方法被改为抽象方法了,即要求所有ViewGroup的子类都必须重写它。


  接着我们来看下ViewGroup.java中的layout()onLayout()方法的源码:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
       
       
       
       
public final void layout( int l, int t, int r, int b) {
if (!mSuppressLayout && (mTransition == null || !mTransition.isChangingLayout())) {
if (mTransition != null) {
mTransition.layoutChange( this);
}
super.layout(l, t, r, b);
} else {
// record the fact that we noop'd it; request layout when transition finishes
mLayoutCalledWhileSuppressed = true;
}
}
protected abstract void onLayout( boolean changed, int l, int t, int r, int b);
语句解释:
-  相比之下ViewGroup增加了LayoutTransition的处理:
   -  若当前ViewGroup未添加LayoutTransition动画,或者动画此刻并未运行,那么调用super.layout(l, t, r, b)。
   -  否则将mLayoutCalledWhileSuppressed设置为true,等待动画完成时再调用requestLayout()。
-  除此之外,还有两个地方需要注意:
   -  layout()方法增加了final关键字,这意味着它的所有子类无法重写layout()方法。
   -  onLayout()方法使用abstract关键字修饰了,这意味着它的所有子类必须重写此方法。


  我们来看下LinearLayoutonLayout方法:

       
       
       
       
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
31
32
33
34
35
36
37
       
       
       
       
// 参数 changed 表示当前ViewGroup的尺寸或者位置是否发生了改变。
// 也就是说ViewGroup的尺寸和位置没有发生变化时,此方法也有可能被调用。
protected void onLayout( boolean changed, int l, int t, int r, int b) {
// 依据方向来调用不同的方法进行layout。
if (mOrientation == VERTICAL) {
layoutVertical(l, t, r, b);
} else {
layoutHorizontal(l, t, r, b);
}
}
void layoutVertical( int left, int top, int right, int bottom) {
// 此处省略若干行代码
int childTop;
int childLeft;
// 此处省略若干行代码
for ( int i = 0; i < count; i++) {
final View child = getVirtualChildAt(i);
if (child == null) {
childTop += measureNullChild(i);
} else if (child.getVisibility() != GONE) {
// 获取到我们之前测量出来的尺寸。
final int childWidth = child.getMeasuredWidth();
final int childHeight = child.getMeasuredHeight();
// 此处省略若干行代码
// 调用setChildFrame()方法来设置子控件的位置
setChildFrame(child, childLeft, childTop + getLocationOffset(child), childWidth, childHeight);
// 由于是垂直排列元素,因此这里需要更新childTop变量的值,以便下一个子View进行布局。
childTop += childHeight + lp.bottomMargin + getNextLocationOffset(child);
i += getChildrenSkipCount(child, i);
}
}
}
private void setChildFrame(View child, int left, int top, int width, int height) {
child.layout(left, top, left + width, top + height);
}
语句解释:
-  从第23行代码可以看出,LinearLayout的子View最终的显示的宽和高,是由该子View的measure过程的结果来决定的。
-  因此measure过程的意义就是为layout过程提供视图显示范围的参考值。

绘画阶段

  布局阶段执行完毕后,框架就会调用DecorView的draw()方法开始绘制View树。但是每次绘图时,并不会重新绘制整个View树中的所有View,而只会重新绘制那些“需要重绘”ViewView类内部变量包含了一个标志位DRAWN,当该视图需要重绘时,就会为该View添加该标志位。


  通过查看源码可以知道,View类的绘制流程由六步构成:

-  第一,绘制当前View的背景-  第二,如果有必要,则为稍后绘制渐变效果做一些准备操作(大多数情况下,不需要)。
-  第三,调用onDraw()方法绘制视图本身   -  View类的onDraw()方法是空实现,ViewGroup类没有重写此方法。
-  第四,调用dispatchDraw()方法绘制子视图。
   -  View类的dispatchDraw()方法是空实现,因为对于不包含子View的控件来说不需要重写此方法。
   -  ViewGroup类已经为我们重写了dispatchDraw()的功能实现,因此ViewGroup的子类一般不需要重写该方法。
-  第五,如果第二步被执行了,那么第五步也会被执行。第五步用来绘制渐变效果以及绘制渐变效果之后的一些收尾工作。
-  第六,绘制滚动条。
   -Android中不管是Button还是TextView,任何一个视图都是有滚动条的,只是一般情况下我们都没有让它显示出来而已。


  总而言之,每一个具体的View都应该重写onDraw()方法,并且不论是View还是ViewGroup的子类,一般不需要重写dispatchDraw()方法。

  绘制的时候主要是借助Canvas这个类,它会作为参数传入到onDraw()方法中,供给每个视图使用。
  Canvas这个类的用法非常丰富,基本可以把它当成一块画布,在上面绘制任意的东西,那么我们就来尝试一下吧。


  范例1:初步使用画笔和画布。

       
       
       
       
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
       
       
       
       
public class MyView extends View {
private Paint mPaint;
public MyView(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
protected void onFinishInflate() {
mPaint = new Paint();
}
@Override
protected void onDraw(Canvas canvas) {
// 设置画笔颜色为黄色
mPaint.setColor(Color.YELLOW);
// 使用画笔绘制一个黄色的矩形
canvas.drawRect( 0, 0, getWidth(), getHeight(), mPaint);
// 设置画笔颜色为蓝色
mPaint.setColor(Color.BLUE);
// 设置画笔的字体大小
mPaint.setTextSize( 20);
String text = "Hello View";
// 将一行文本绘制到画布中去,字体的颜色是蓝色,字体的大小是20px。
canvas.drawText(text, 0, getHeight() / 2, mPaint);
}
}

  布局文件的内容为:

       
       
       
       
1
2
3
4
5
6
       
       
       
       
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width= "match_parent" android:layout_height= "match_parent" >
<com.cutler.demo.common.view.MyView
android:layout_width= "200dp"
android:layout_height= "100dp" />
LinearLayout>
语句解释:
-  Paint表示一个画笔,Canvas表示一个画布。 
-  另外,由于MyView类没有重写onMeasure方法,则系统使用默认的策略来计算它的测量尺寸,即使用XML中设置的尺寸。

  运行效果如下图所示:




View重绘
  虽然View会在Activity加载完成之后绘制到屏幕上,但是在程序的运行时View的状态是会改变的。当改变发生时,之前绘制出的内容其实就已经过期了,此时应该对视图进行重绘。

  调用视图的setVisibility()setEnabled()setSelected()等方法时都会导致视图重绘,而如果我们想要手动地强制让视图进行重绘,可以调用invalidate()方法来实现。

-  setVisibility、setEnabled、setSelected等方法的内部其实也是通过调用invalidate方法来实现的。
-  这里的重绘是指谁请求invalidate方法,就重绘该视图(View的话只绘制该View,ViewGroup则绘制整个ViewGroup)。

  invalidate()只可以在主线程中调用,如果你需要在子线程中重绘View,那么可以调用postInvalidate()方法。


  如果你需要定时重绘,那么你可以使用postInvalidateDelayed(long delayMilliseconds)方法,当倒计时结束后,该方法会有如下判断:

-  若调用该方法的View依然显示在屏幕中,则该方法会在主线程中调用invalidate()方法执行重绘。
-  若调用该方法的View已经不显示了,则这个重绘任务会被挂起,等到该View再次显示时,才会触发重绘。

  比如,对于一个计时器View来说,每秒钟都需要重绘一次,如果通过开启Thread来定时调用postInvalidate()方法来实现计时的话,有两个缺点:

-  第一,开启Thread类需要消耗一定资源。
-  第二,若计时器View当前不再屏幕中(比如用户把App切换到后台了),那么线程仍然在跑,View仍然是每秒钟都重绘一次,浪费大量资源。


  如果你不需要定时重绘,那么最好也去使用postInvalidate()方法,当View不再显示时,它同样不会立刻执行重绘操作,它的源码为:

       
       
       
       
1
2
3
       
       
       
       
public void postInvalidate() {
postInvalidateDelayed( 0);
}

其它常用方法

定位

  View的几何形状是矩形的,视图的位置使用左上坐标系表示,尺寸宽和高表示,位置和尺寸以像素为单位。我们可以通过getLeft()getTop()函数取得视图的位置

-  前者返回视图的左侧位置(横坐标X)。
-  后者返回视图的顶部位置(纵坐标Y)。

  这两个方法返回视图相对于其父视图的位置,例如getLeft()返回20,代表视图在其直接父视图左侧边的右侧20像素的位置

  另外,为了避免不必要的计算,提供了一些便利的方法,它们是getRight()getBottom()。这些方法返回代表视图的矩形的右侧和底边的坐标。例如,调用getRight()比调用getLeft() + getWidth()要简单。


跳过绘制

  View类有一个特殊的方法setWillNotDraw,先来看一下的它的源码:

       
       
       
       
1
2
3
4
5
6
7
8
9
10
11
12
13
       
       
       
       
/**
* If this view doesn't do any drawing on its own, set this flag to
* allow further optimizations. By default, this flag is not set on
* View, but could be set on some View subclasses such as ViewGroup.
*
* Typically, if you override {@link #onDraw(android.graphics.Canvas)}
* you should clear this flag.
*
* @param willNotDraw whether or not this View draw on its own
*/
public void setWillNotDraw( boolean willNotDraw) {
setFlags(willNotDraw ? WILL_NOT_DRAW : 0, DRAW_MASK);
}
语句解释:
-  从注释可以看出来,如果一个View不需要绘制任何内容,那么设置这个标记位为true后,系统就会进行相应的优化。
-  默认情况下,View没有启用这个优化标记位,但是ViewGroup会默认启用这个标记位。


从窗口中添加和移除

  当View和其所在的Activity建立和断开连接时,系统会调用如下两个方法:

-  Activity关闭或者ViewActivity中移除时,View的onDetachedFromWindow方法会被调用。
   -  通常在此方法中关闭线程和停止动画,从而避免内存泄漏。
-  View被添加到Activity中时,它的onAttachedToWindow方法会被调用。


大小改变

  在View类中还有一个比较有用的方法是onSizeChanged,当View的尺寸改变时就会调用它。

-  一般情况下,我们在自定义控件的时候会依据View的尺寸来确定绘制的大小,但是程序在运行的时候不可避免的因为一些外力而导致View的尺寸发生变化(比如横竖屏切换、输入法弹出等)。

  因此通常的做法是重写onSizeChanged方法,并在其内部更新变量的值,并调用进行invalidate方法重绘。


本章参考阅读:

  • Android LayoutInflater原理分析,带你一步步深入了解View(一)
  • Android视图绘制流程完全解析,带你一步步深入了解View(二)
  • Android视图状态及重绘流程分析,带你一步步深入了解View(三)
  • Android自定义View的实现方法,带你一步步深入了解View(四)
  • Android如何绘制视图,解释了为何onMeasure有时要调用多次
  • How Android Draws Views
  • Android中layout过程详解

你可能感兴趣的