Android 开发艺术探索笔记 前四章

Android 开发艺术探索笔记

这几天看了Android 开发艺术探索这本书,感觉是一本很好的书。我目前看了前4章。Activity的生命周期、Android的IPC机制、Android事件分发机制、Android的View绘制机制。这些都是Android开发者从中级迈向高级所必须的知识。书中很多篇幅是源码解析,有些人看起来可能会有些吃力,所以我写了这篇笔记,不仅仅是帮助自己巩固知识,也希望能帮助大家更快的了解书中的源码分析。在笔记中我也整合了一些看书过程中所查阅的博客,还有我以前看过的Android书籍中的知识点,完善了书中的一些描述不清楚的地方,相信大家如果能结合这篇博客一起看书的话,肯定是大有裨益的,毕竟读者总是更了解读者的。关于后续的章节,我会在接下来的1个月里陆续啃完发出来,大家如果对于书中的知识有什么不了解的地方,欢迎和我一起讨论。

第一章 Activity的生命周期和启动模式

1.Activity的生命周期全面分析

Activity的生命周期分为两部分:1.典型生命周期,即正常情况下有用户参与的生命周期 2.Activity被销毁重建之后的生命周期
先来说说典型生命周期:

activirty生命周期图

activity的典型生命周期对于大部分开发者来说是再熟悉不过了,所以就上一张图。

书中提到了两个问题:1.onStart和onResume、onPause和onStop有什么区别。答:onStart和onStop是从Activity是否可见这个角度来回调。而onResume和onPause则是从Activity是否位于前台的角度来进行回调。 2.从Activity1启动Activity2,是Activity1的onPause先调用还是Activity2的oResume先调用。答:是Activity1的onPause先调用,然后启动Activity2,最后调用Activity1的onStop。

再来说说异常生命周期:

  • 系统配置发生改变导致Activity被杀死,例如:旋转了屏幕。
    • 1.当旋转了屏幕老的Acrivity会被销毁新的Activity会生成,在老Activity调用onStop之前会调用onSaveInstanceState用来保存当前Activity的状态和开发者自定义保存的数据。
    • 2.在新Activity调用onStart之后会调用onRestoreInstanceState,让开发者恢复在onSavaInstanceState中保存的数据。
    • 3.onSaveInstanceState和onRestoreInstanceState在普通Activity销毁的时候都不会调用 。
    • 4.系统会默认恢复Activity视图中的一些View的数据,比如说文本框中的数据等等,每个View都有onSaveInstanceState和onRestoreInstanceState这两个方法,可以查看这两个方法了解某5.些View会保存哪些数据。
    • 一般建议在onRestoreInstanceState中恢复数据,因为onCreate中的bundle在正常启动的时候为空,onRestoreInstanceState只有在异常销毁Activity的时候才会调用,所以bundle不会为空
  • 内存资源不足导致优先级低的Activity被杀死
    • 1.处于onResume的Activity优先级最高,即正在和用户交互。2.处于onPause的Activity优先级第二,即弹出了对话框但Activity依然可见。3.处于onStop的Activity优先级最低,即不可见的处于后台的Activity。
    • 注意:一些后台工作不适合独立运行在后台,因为脱离了四大组件,单独的线程很容易在内存不足的时候被系统杀死,所以比较好的方法是放入Service之中

2.Activity的启动模式

  • 1.standard:标准模式,每次启动一个Activity都会创建一个新的实来例。
  • 2.singleTop:栈顶复用模式,每次启动一个Activity,如果栈顶就是这个Activity的话,调用这个Activity的onNewIntent方法,获取新的请求信息,然后调用onResume。
  • 3.singleTask:栈内复用模式,每次启动一个Activity,会在栈内寻找是否有该Activity,如果找到,就将该Activity上面的Activity全部出栈,然后和singleTop一样。
  • 4.singleInstance:单例模式,在singleTask之上还加强了一点,就是此种模式下,Activity单独位于一个任务栈内。

3.IntentFilter的匹配规则

第二章 IPC机制

1.Android IPC简介

2.Android中的多进程模式

  • 1.如何开启多进程呢?在AndroidMenifest中的四大组件中指定android:progess属性。
  • 2.Android系统为每个进程都分配了一个虚拟机,如果同一个应用中有两个进程的话,那么每个进程中都会分配一个类,这两个进程中的类是独立的。也就是说处于不同进程的组件要通过内存来共享数据都会失败。注意多进程会出现如下几个问题:
    • 1.静态成员和单例完全失效(因为每个进程都会分配一组)。
    • 2.线程同步会失效(因为不在一块内存了)。
    • 3.SharedPreferences可靠性失效(其不支持两个进程同时去执行写操作,因为其底层是是通过写xml文件实现的)。
    • 4.Application会多次创建(原因同1,单例失效)。

3.IPC基础概念介绍

  • 1.Serializable接口,java提供的序列化接口,只需implement接口即可。注意:serialVersionUID最好自己指定,因为这样的话在增加或者减少成员变量之后,还是能反序列化成功。
  • 2.Parcelable接口,Android提供的接口,implement之后,对象能够通过Intent和Binder传递,基本类型和String不需要实现序列化,但是如果是自己定义的类型被当成成员变量的时候,自己定义的类型也需要实现序列化。注意:系统提供了许多已经实现了Parcelable接口的类比如说Intent、Bundle、Bitmap、List和Map(不过List和Map中的元素也必须是已经序列化的)。
  • 3.Binder类,Android开发中Binder主要用在Service的通信上(无论是在同一进程还是不同进程)。一般常用的AIDL和Messager的底层都是基于Binder。所以可以从AIDL来分析Binder。

    • 1.编写AIDL文件需要注意几点规则:
      • 1.接口和方法前面不需要加访问权限修饰符,也不能用final,static等等。
      • 2.AIDL支持java基本类型,和String,Map,List和CharSequence不需要导包,而自定义的类型需要显示import无论是不是在一个包内。
      • 3.AIDL中使用的类型都必须是已经Parcelable。
      • 4.AIDL中所有非基本类型的参数前面必须加上in、out、inout、标记以指明参数是输入参数还是输出参数还是输入输出参数。
      • 5.如果AIDL中用到了自定义的Parcelable类,那么定义一个和它同名的AIDL文件,并在里面声明它为Parcelable类型。并且这个文件的路径要和那个自定义的类型完全一致
    • 2.Android Studio会自动根据AIDL文件生成相应的Java接口,而接口里除了AIDL中定义的方法,就只用一个抽象类Stub。(这个类继承了Binder并且实现了AIDL文件生成的接口。也就是说其内部有着Binder的能力,能够与不同进程的组件交互的能力(不过这一切都是底层实现好然后封住给开发者用的)然后其还implement了AIDL生成的Java接口,这就是我们的业务逻辑。其内部又包括了一下内容。):

      • 1.DESCRIPTION:Binder的唯一标识,表明当前ADIL生成接口的类名。
      • 2.多个int值:用来标记AIDL接口的方法。
      • 3.Proxy类:实现了AIDL接口的类,里面有个Binder,是Binder类的代理类。Proxy类实现的AIDL接口的方法:这些方法是运行在客户端的,当在客户端调用了这个方法的时候会创建Parcel对象data和reply,然后把该方法的参数写入data中(如果有参数),接着调用Bidner方法的transact()来发起远程调用(RPC)请求,同时当前线程挂起(所以一般这些方法需要放在子线程)。然后调用后面要讲的onTransact(),直到RPC过程返回之后,当前线程继续执行,并且reply取出中写入的结果返回。
      • 4.asInterface(IBinder obj):将Service的Binder对象转换成客户端所需要的AIDL接口对象。如果是同一进程的话就是Stub对象本身,如果是不同进程则返回Stub.Proxy对象,即Stub的代理对象。
      • 5.asBinder(): 返回当前的Binder对象。
      • 6.boolean onTransact(int code,Parcel data,Parcel reply,int flags):该方法运行在Service的Binder线程池中,当客户端发起跨线程请求的时候(即调用前面Proxy的AIDL接口实现方法)经过底层封装最后会调用这个方法。从data中取客户端传的参数(如果客户端有传),通过code和Stub中定义的方法标识来确定调用哪个方法,从reply中写入返回值(如果有返回值)。当onTransact()返回为false的时候,用户端请求失败。
    • 3.最后再来介绍Binder了两个方法linkToDeath()和unlinkToDeath()。通过Service与客户端的Binder的linkToDeath(DeathRecipient,int)我们可以注册Binder的死亡监听。如果Service与客户端之间的连接断了,就会调用DeathRecipient的binderDied(),而我们可以重写这个方法来调用Binder的unlinkToDeath()来重新建立连接。

总的来说AIDL生成的代码可以拆分为三个文件:1.AIDL的java接口。2.同一进程使用的Stub类。3.不同进程使用的Proxy类。当客户端和Service在同一进程的时候,两个部分能够共享内存,此时客户端能够直接使用Service中定义的Stub类,这个时候的交互就和普通交互一样。而当客户端和Service处于不同的进程时,在客户端本地内存中是没有Service中定义的Stub实例的,此时客户端就创建一个Stub.Proxy类,用来代理Stub类,通过onTransact()方法来调用Service中的Stub实例中的方法。所以通过上面的分析,其实不需要ADIL文件,我们自己也可以写出能进程间交互的Binder来。

4.Android中的IPC方式

  • 1.使用Bundle:Android中的四大组件都可以通过Intent中放入Bundle来传递数据,不过Bundle的传递只能在使用了Intent的时候才能使用
  • 2.使用文件共享:在Android中支持多个线程一起对文件进行并发的读写(尽管这样容易出现问题)。所以以我们可以通过将序列化的类写在文件中,然后让在另一个进程中读取。(这样也容易出问题,因为这样的话必须两个操作有严格的先后顺序,而很多情况下两个进程中的操作是没有严格先后顺序的。)另一个例子就是SharedPreferences,虽然其底层是基于读写xml文件来实现储存的,但是由于其会在内存中保留一份缓存,所以一般不建议在进程中通信使用它。
  • 3.使用Messager:由于Messager是系统已经封装好的基于AIDL的轻量级IPC方案,所以我们可以很容易的使用它进行IPC交互,并且由于它一次性处理一个请求,因此在服务端我们不用考虑线程同步的问题。建立一个能够双向传递数据的IPC通道需要下面几个步骤:

    • 1.创建一个Service,并且在Service中创建一个Handler对象。
    • 2.用一个Handler对象创建一个属于Service的Messager对象。
    • 3.在Handler中根据Message.replyTo()获取客户端传过来的Messager对象,然后就可以通过这个Messager对象向客户端发送消息。
    • 3.在Service的onBind()对象中返回Messager.getBinder()。
    • 4.在客户端中根据返回的Messager.getBinder()创建一个和Service联系的Messager对象。
    • 5.然后就可以通过客户端中的Service的Messager对象发送Message实例给Service了。
    • 6.而对于接收信息也需要像Service中一样,创建一个Handler。
    • 7.根据Handler创建一个属于客户端的Messager,并且要在Message实例中传入属于客户端的Messager。

    经过上面的7个步骤就能建立一个IPC双向通道,其实总的来说就是在客户端和Service中各自建立一套属于自己的Messager和Handler,然后通过互相获取各种的Messager来传递Message实例,然后在Handler中解析Message。

  • 4.使用AIDL:使用AIDL进行IPC通讯可以分为两种情况 1.在客户端调用Service的服务。2.在客户端监听Service。

    • 1.主动调用需要以下步骤
      • 1.新建AIDL文件1并在其中定义需要的函数。
      • 2.生成AIDL接口1之后,在Service中实现Stub的抽象函数。
      • 3.在Service的onBind中返回实现的Stub实例。
      • 4.在客户端中根据返回的Stub实例,调用Stub的asInterface。获取AIDL接口1的实现类。
      • 5.最后就可以在客户端通过调用AIDL接口的实现类的函数来调用Service的服务了。
      • 6.需要注意的是由于Service中AIDL接口的所有方法都是运行在Binder的线程池中的,所以不需要关心阻塞问题,但是需要关心线程同步的问题。(CopyOnWriteArrayList和ConcurrentHashMap能够并发读写,可以有效解决这个问题)
    • 2.在客户端监听Service,这个问题其实就是一种观察者模式,也就是说客户端定义一个Listener,然后传给Service当Service发生变化的时候,就回调Listener的方法。只不过这里是跨进程的监听,需要用到的接口也不是普通的接口,而是AIDL接口。在主动调用的基础上我们还需要以下步骤才能进行跨进程监听。
      • 1.新建一个AIDL文件2,并在其中定义监听函数。
      • 2.在之前定义的AIDL文件1中加入两个新的函数,分别用来注册监听接口和解绑监听接口。
      • 3.在Service中建立一个Listener的List以便绑定和解绑。
      • 4.实现AIDL文件1新增的两个函数,大概就是在List中添加和删除Listener。
      • 5.在客户端中实现AIDL接口2的逻辑并生成Listener实例,通过之前实现的AIDL接口1的实现类注册Listener。
      • 6.经过上述步骤之后,在Service中调用Listener的方法就能实现监听。
      • 7.需要注意一个问题:我们使用了一个List储存Listenner,当注册添加的时候还行,但是一旦要解绑删除的时候就会出现一个问题:由于Binder在传输的时候,不是保持原来的对象,而是复制出一个数据相同的全新对象。这样一来就不能用一般的List来储存Listener。系统提供了一个RemoteCallBackList专门用来添加和删除跨进程Listener接口。
  • 5.使用ContentProvider:这个放在后面讲其细节的时候再写。

  • 6.使用Socket:这个用的很少,所以不用深入了解。
  • 5.Binder连接池

    在讲这个之前,首先提出一个问题:目前我们是有一个AIDL服务就生成一个Service,如果项目复杂起来之后有许多AIDL服务的话,那是不是要生成同等数量的Service呢?Binder连接池就是解决这个问题。让我们无论多少个AIDL服务,都只需要建立一个Service。

    实现步骤:

    • 1.首先,为每个业务模块创建AIDL接口并实现此接口及其业务方法。
    • 2.创建IBinderPool的AIDL接口,定义IBinder queryBinder(int BinderCode)方法。外部通过调用此方法传入对应的code值来获取对应的Binder对象。
    • 3.创建BinderPoolService,通过new BinderPool.BinderPoolImpl实例化Binder对象,通过onBind方法返回出去。
    • 4.创建BinderPool类,单例模式,在构造方法中绑定Service,在onServiceConnected方法获取到BinderPoolImpl对象,这个BinderPoolImpl类是BinderPool的内部类,并实现了IBinderPool的业务方法。BinderPool类中向外暴露了queryBinder方法,这个方法其实调用的是BinderPoolImpl对象的queryBinder方法。

    6.选用合适的IPC方式

    书上的图很清晰。

    第三章 View事件体系

    1.View的基础知识

    • 1.什么是View:略
    • 2.View的位置参数:Android中有两套坐标体系,我们分别来说一下。

      • 1.屏幕坐标体系:这套体系是以屏幕的左上角为原点,从原点向右是x轴的正半轴,从原点向下是y轴的正半轴。MotionEvent有以这个坐标系为基准的函数:getRawX(),getRawY()分别获取x,y坐标。
      • 2.父视图坐标体系:这套体系是以父视图的左上角为原点,从原点向右是x轴的正半轴,从原点向下是y轴的正半轴。MotionEvent有以这个坐标系为基准的函数:getX(),getY()分别获取x,y坐标。除此之外,子View的位置也是基于这套坐标系。View有getLeft()和getTop(),getRight()和getBoom()这几个函数,分别获取View的左上顶点的x,y坐标,View的右下顶点的x,y坐标。
      • 3.需要注意的是:View还有几个参数也是很重要的分别是x、y、translationX、translationY。这几个参数View都提供了get/set方法。x、y是View左上角的坐标(屏幕坐标系)。translationX、translationY是View左上角相对父View的偏移量。有这个公式:View.getX()=View.getLeft()+View.getTranslationX,Y轴也是一样。所以我们可以发现在View移动的过程中getLeft()和getTop()等标识原始左上角位置信息是不会改变的,此时发生改变的是x、y、translationX、translationY这四个参数。
    • 3.MotionEvent和TouchSlop

      • 1.MotionEvent:这个很简单略过。
      • 2.TouchSlop:这个是系统能识别出来的最小滑动距离,和设备有关可以通过ViewConfiguration.get(getContext()).getScaledTouchSlop()获取。
    • 4.VelocityTracker、GestureDetector和Scroll

      • 1.VelocityTracker:这个类可以用于速度追踪,要使用有以下几个步骤

        • 1.调用VelocityTracker.obtain()获取实例。
        • 2.通过computeCurrentVelocity(int),设置速度单位,比如输入1000就是以1000毫秒为单位。
        • 3.通过getXVelocity()获取速度,如果以步骤2为基础的话那么单位就是:像素/1000毫秒。
        • 4.需要提醒的是:向左为负速度,向右为正速度。并且当不需要的时候要调用clear()和recycle()来回收内存。
      • 2.GestureDetector:手势检测,用于辅助用户的单击、滑动、双击、长按等行为。

        • 1.建立实例并且调用setIslongpressEnabled(false)。
        • 2.在目标View的onTouchEvent()方法中调用实例的onTouchEvent(MotionEvent)方法。
        • 3.最后我们就可以通过设置OnGestureListener和OnDoubleTapListener这两个监听器,再通过其回调来检测手势了。
      • 3.Scroll:后面会讲它,所以先略过。

    2和3.View的滑动

    • 1.layout():可以重写onTouchEvent(),计算手指偏移量offsetX,offsetY。然后获取View的长和宽,带入到layout()中即可完成滑动。需要注意的是layout()这个方法是瞬间变化的,也就是说如果偏移量过大,会导致类似卡顿的现象。
    • 2.offsetLeftAndRight()和offsetTopAndBottom():同方法一,也是计算出offsetX,offsetY,然后分别传入两个方法。偏移过大也会有类似卡顿现象,总的来说就是layout()方法的简单版。
    • 3.LayoutParams:这是一个类,保存了View在父View的布局参数,所以需要在父View中获取实例,然后修改参数再传回到父View中。
    • 4.scrollBy():也是计算了offsetX,offsetY之后传入,不过这个函数是调用父View的,也就是说是参考系整个发生移动,所以一般计算了偏移量之后需要价格负号。
    • 5.scrollTo():这个也是作用于父View上的,不过需要提供左上角坐标,和右下角坐标,4个参数。
    • 6.Scroll:这是一个类,可以把一段指定的距离分成微小的间距,最后再调用上面的几个方法进行移动。其实就是代替onTouchEvent()中在MotionEvent.ACTION_MOVE中不断计算。整体需要三个步骤1.创建一个Scroll的实例 2.重写View的computeScroll(),在其中判断滑动是否结束,并且不断调用上面几个方法的一种 3.调用start()传入起始位置,和长距离的offsetX,offsetY。注意有一点就是在computeScroll()最后必须调用invalidate(),因为调用这个就会触发computeScroll()的调用,直到滑动完毕。
    • 7.ViewDragHelper:这个方法总的来说就是把父View的触摸事件交给ViewDragHelper来处理,然后让开发者通过其暴露出来的几个接口结合其内部的Scroll类进行子View的滑动。书上讲的是一个侧滑控件,不过讲的不是很完全,有一些回调函数,比如触摸边缘的回调等等都没有涉及。所以建议大家看完这一节,去百度一些博客加深理解。大家可以看看这个我当时看的博客ViewDragHelper

    4.View的事件分发机制

    看了这以小结之后真的感觉这是很重要的一节,所以花了点时间找了一些大牛的博客结合本节再加上阅读了源码,画出了一张图:View事件分发源码解析图,大家可以保存下来结合源码和书慢慢啃。
    Android 开发艺术探索笔记 前四章_第1张图片

    我总结了一下View事件分发的几点策略,以下策略都可以在上面的图中找到依据。

    1. 从手指触摸屏幕到离开屏幕会产生:down->move->…->move->up。这一系列事件,android系统倾向于让某一个View处理这一整个事件序列。
    2. ViewGroup中,每次down事件都会让ViewGroup的标记重置。
    3. View一般来说是不需要拦截事件的,因为当事件传递到View的时候,其要么消耗要么返回给父ViewGroup。而ViewGroup如果需要先子View处理事件的话,就可以拦截事件。一旦ViewGroup选择了拦截事件,那么后面同一序列的事件将不会继续下传,都给本ViewGroup处理。(注意:这里有个前提条件就是事件能够传到本ViewGroup中,若其上层的ViewGroup拦截了事件的话,那么同样序列的事件都会给上层ViewGroup处理)
    4. 若一个ViewGroup决定开始拦截事件的话,那么其onInterceptTouchEvent()方法就不会再调用,这个可以看成(2)的补充。
    5. 如果最底层的View不消耗down,那么事件会重新返回到其父ViewGroup并调用父ViewGroup的onTouchEvent(),同理可以把父ViewGroup看作View,重复刚刚的行为直到传到Activity的onTouchEvent()。需要注意的是:View不消耗down事件之后,那么同一事件序列的其他事件都不会再交给该View了,而是转交给上一次消耗了down事件的ViewGroup,除非事件在向下传递的时候已经被拦截了。
    6. 如果底层的View只消耗down事件的话,那么其还是能接受到其他同一序列的事件的。但是此时,同一序列的其他事件就不会再给ViewGroup了,而是直接给Activity的onTouchEvent()
    7. ViewGroup默认不拦截任何事件即,onInterceptTouchEvent()默认返回false。
    8. View的onTouchEvent()默认都是会消耗事件的,即默认返回true。除非该View既不可点击,又不可长按。
    9. View的属性enable不影响onTouchEvent()的返回值,哪怕该View是disable的,只要能点击或者长按onTouchEvent()就会返回true。
    10. 当android系统处理down事件的时候,会维护一条View链表,这条链表是down事件走过的View形成的。所以在down事件之后,系统无需再遍历当前的View树,寻找事件所在的View区域。

    另外我独开了一篇博客专门放这个图片大家可以点进去看看:View事件分发源码解析图

    5.View的滑动冲突

    • 1.常见的滑动冲突场景:

      • 1.内外滑动方向不一致:像这种问题可以通过重写外面的ViewGroup的onIntercreptTouchEvent(),拦截move事件判断是左右滑,还是上下滑。来决定将事件给谁处理。
      • 2.内外滑动方向一致:一般这样的情景我们需要确立业务逻辑是怎样的,比如说优先将内部的ViewGroup画到顶部和底部之后再让外部的ViewGroup滑动。确立了逻辑之后就按照第一种办法处理即可。只不过换一下拦截move事件的逻辑而已。
      • 3.上面两种情况一起的3重嵌套:这种情况也是优先确立业务逻辑,然后套用方法一更换拦截逻辑。
    • 2.拦截的两种方法:

      • 1.外部拦截法:顾名思义根据事件传递的规则,在事件传到子View之前先判断是否拦截事件。
        • 1.重写onIntercreptTouchEvent()方法。
        • 2.当事件为down时不拦截:原因是如果这个时候拦截了事件,那么之后的事件序列就都交由该ViewGroup处理了,而当事件是down的时候我们的所知道的滑动信息是很少的,此时很难判断出是否应该交给ViewGroup处理。
        • 3.当事件为move的时候处理逻辑,判断是否应该拦截:此时刚好和down的时候不一样,因为我们已经可以根据滑动的信息判断室是否应该滑动ViewGroup了。
        • 4.当事件为up的时候不拦截:假如前面ViewGroup的时候已经拦截过了事件的话,那么此时无需拦截事件,up自然会交由ViewGroup处理。反之如果之前ViewGroup没有拦截事件,那么up事件就传不到View中了,我们前面分析事件分发的时候了解到:View的onClickListener的onClick()事件是在up的时候调用的,所以这时会造成View的点击失效的情况。
      • 2.内部拦截法:这种方法主要是通过在子View中设置ViewGroup的FLAG_DISALLOW_INTERCERT标记。因为设置了之后可以让父亲View不拦截任何事件,将所有事件交给View处理,让View决定是否消耗事件,如果不消耗事件则将事件再返回给ViewGroup让其处理。不过这种方法有点违反android系统的事件分发原则,所以建议使用第一种方法来进行外部拦截法。

    以上就是从书中精简下来的总结,建议能实现一下书中的代码加深理解。

    第四章 View的工作原理

    1.初识ViewRoot和DecorView

    我们都知道Activity中有个Window,Window中添加了一个顶级ViewGroup名为DecorView。在ActivityThread中,当Activity对象被创建完毕之后,会将DecorView添加到Window中,同时创建一个ViewRoot的实现类ViewRootImpl并与DecorView建立关系。而View的绘制就是从ViewRoot的performTraversals()方法开始的

    上一张View绘制流程框架图
    Android 开发艺术探索笔记 前四章_第2张图片

    由图可以看出几点View绘制的基本策略:

    • 1.ViewRootImpl的performTraversala()方法会依次调用performMeasure()、performLayout()和performDraw()来完成DecorView的绘制。
    • 2.DecorView是一个ViewGroup,所以其在measure()、layout()和draw()过程中会调用子View的measure()、layout()和draw()方法,从而把绘制传到子View中。
    • 3.(2)中说的子View可能是ViewGroup也可能是View,像这样最终会遍历整个View树,完成View的绘制。

    2.理解MeasureSpec

    • 1.先来说说MeasureSpec这个类:
      • 1.View通过两个数据来调整自身的大小分别是mode和size。
      • 2.mode分为三种:
        • 1.MeasureSpec.EXACTLY,即精确测量模式,当xml中设置layout_width、layout_height和match_parent调用。
        • 2.MeasureSpec.AT_MOST,即最大尺寸模式,当xml中设置wrap_content的时候使用。
        • 3.MeasureSpec.UNSPECIFIED,不指定测量模式,在自定义View的时候使用。
        1. mode和size是整合在一个32位的int值中的,高2位是mode低30位是size。类MeasureSpec的两个方法能获取mode和size,分别是MeasureSpec.getMode(int)和MeasureSpec.getSize(int)。
    • 2.MeasureSpec和LayoutParams的对应关系
      • 1.在View测量的时候,系统会将LayoutParams在父View的约束下转换成对应的MeasureSpec,然后再根据这个MeasureSpec来确定View的测量后的宽高。需要注意的是:MeasureSpec并不是由LayoutParams唯一决定的,父View也是会和LayoutParams共同作用出MeasureSpec
      • 2.对于顶级View(DecorView)和普通View来说,MeasureSpec的产生略有不同。
        • 1.对于DecorView,其MeasureSpec由窗口尺寸和其LayourParams决定。
        • 2.而对于普通View则是上面说的:其MeasureSpec由父View的MeasureSpec和自身的LayoutParams决定。
      • 3.来具体说一下DecorView的MeasureSpec产生的过程,ViewRootImpl中有个getRootMeasureSpec(int,int)方法,分别传入屏幕尺寸和LayoutParams的宽高类型。最后有如下几种选择:
        • 1.当宽高类型为ViewGroup.LayoutParams.MATCH_PARENT时:大小就是窗口大小。
        • 2.当宽高类型为ViewGroup.LayoutParams.Wrap_CONTENT时:需要获取子View的大小后才能得出自己的大小,但是不超过屏幕的大小。
        • 3.当宽高类型书是上述两种的时候:大小就是LayoutParams中定义的大小。
      • 4.再来说说普通View的MeasureSpec产生的过程,View的measure方法是由ViewGroup调用的,所以其MeasureSpec也是由ViewGroup产生的,我们可以在ViewGroup中找到一个getChildMeasureSpec(int,int,int)的函数,传入的参数分别为ViewGroup的MeasureSpec、ViewGroup的两个padding与View的两个margin的和、View的LayoutParams的宽高类型。先上一个图:Android 开发艺术探索笔记 前四章_第3张图片这个图就是ViewGroup的getChildMeasureSpec(int,int,int)方法的总结表,我再用语言归纳一下:
        • 1.首先UNSPECIFIED这一列我们可以不去看它,因为这个模式主要用于系统内部的多次Measure情形,一般来说我们不需要关注此模式。
        • 2.这个的childSize是只View的LayoutParams中定义了的大小。这里的parentSize 是指,ViewGroup中可用的大小(注意我们前面说过,在getChildMeasureSpec方法的第二个参数是各种边界值的和,所以这里的可用大小就是ViewGroup从其MeasureSpec中解析出来的size与第二个参数的差。)
        • 3.我们可以先来看看第二行的情况:可以得知当我们设置死了View的大小的时候,不管ViewGroup的MeasureSpec的mode是什么样,View都是精确模式,且大小等于在LayoutParams中设置过的大小。
        • 4.再来看看第三行:可知当ViewGroup为精确模式的时候,View也为精确模式,且其大小为ViewGroup剩下的大小。当ViewGroup为最大值模式的时候,View也为最大值模式,且大小不超过ViewGroup的大小。
        • 5.在来看看最后一行:我们发现不管ViewGroup的模式是精确模式还是最大值模式,View的模式始终是最大值模式且其大小不超过ViewGroup。(在这里有个疑问,我实际操作了一下,发现当ViewGroup为精确模式的时候,内部是View还是TextView的结果是不同的,当为View时View的大小是ViewGroup的大小,当为TextView的时TextView的大小是其内部字的大小。这个问题需要等到后面才能知道。)
        • 6.最后再总结一下:在View精确的设置了宽高的时候,ViewGroup是不能影响View的。在View设置为wrap_content的时候,其模式是随着自己的。在View设置为match_parent的时候其模式是随着ViewGroup的。而除了精确设置以外,View的大小都是随着ViewGroup的、。

    3.View的工作流程

    View的工作流程主要分为三大块:measure、layout和draw。我们一个个来分析。

    • 1.measure过程,如果是仅仅是一个View的话,那么通过measure方法就完成了其测量过程,但是如果是一个ViewGroup的话,那么它除了完成自己的测量过程还需要遍历子View来完成所有子View的measure方法,各个子View再去递归执行这个流程,所以我们分成两部分来分析:
      • 1.View的measure流程由一个final的方法measure()来完成。在View的measure()方法中会去调用View的onMeasure()方法,而onMeasure()方法中只调用了setMeasureDimension(int,int)方法,这个方法分别传入测量出来的宽和高。而View是通过getDefualtSize(int,int)来获取测量的宽高的。所以我们只要看这个函数就行了。
        • 1.首先这个函数传入了getSuggesteMinnimum(Width/Height)()的返回值和(width/height)MeasureSpec。
        • 2.getSuggesteMinnimum(Width/Height)()的逻辑是:如果View没有设置背景,那么就返回android:min(Width/Height)这个属性的值,默认为0。如果View设置了背景,则返回android:min(Width/Height)和背景值这两个中的最大值。而getSuggesteMinnimum(Width/Height)()返回的值就是View在UNSPECIFIED模式下测出的宽高。
        • 3.我们接着就可以看getDefualtSize(int,int)这个方法了,在这个方法中我们可以看到当specMode为EXACTLY的时候,则返回specSize。当specMode为UNSPECIFIED时则返回我们2中提到的大小。而当specMode为AT_MOST的时候我们发现处理方式和EXACTLY一样。(在这里我们可以解决我在前面提到的View和TextView的疑问了,我们从前面的表可以知道当View中使用wrap_content的时候其specMode是AT_MOST,其specSize等于parentSize。所以此时View设置wrap_content和设置match_parent的效果是完全一样的。而TextView中有对设置成wrap_content的判断,所以最终测量的结果不是parentSize)
        • 4.我们通过3可以知道,当我们需要自定义View的时候,需要重写onMeasure()这个方法,给wrap_content设置判断设置一个最小值,要么wrap_content这个设置就不起作用了。
      • 2.再来说说ViewGroup的measure:我们前面说了ViewGroup除了measure自己还得measure子View,ViewGroup是一个抽象类,其没有重写View的onMeasure()方法,而是提供了一个measureChildren()的方法。 我们就来分析一下这个方法。
        • 1.measureChildren()是遍历子View然后挨个调用measureChild(View,int,int)方法,第一个参数是每个子View,第二个和第三个参数是ViewGroup的measureSpec。
        • 2.measureChild(View,int,int)方法的思想很简单:就是取出子View的Layoutparams,然后通过getChildMeasureSpec()来创建子View的MeasureSpec。这个getChildMeasureSpec()在前面已经分析过了,所以现在已经很清晰了。
        • 3.我们知道android中有许多不同的布局,所以ViewGroup的onMeasure()方法被设置为一个抽象方法,让不同的布局去实现它。
      • 3.我们在2中说了ViewGroup的measure过程,但是没有举出具体的例子,所以这里来说说LinearLayout的onMeasure()方法的流程。其我们都知道LinearLayout有横着和竖着两种模式,所以其onMeasure()方法中也有两种测量方式,我们就以measureVertical()来作为分析。
        • 1.该方法首先。会遍历子元素并对每个子元素执行measureChildBeforeLayout()方法,这个方法内部会调用子元素的measure方法。
        • 2.系统会在1遍历的时候用mTotalLength这个变量来储存LinearLayout在竖直方向初步的高度,而每测量一个子ViewmTotalLength就会增加子View的高度+子元素在数值方向上的margin等。
        • 3.当子View测量完毕之后mTotalLength会加上LinearLayout的padding,然后设置自己的高度,针对竖直LinearLayout而言,它在水平方向的测量过程遵循View的测量过程。而数值方向上如果他采用的是match_parent,则也是和View一样,但是如果是采用wrap_content的话,那么其高度是mTotalLength,当然此时高度不能超过父ViewGroup的剩余高度。
      • 4.我们知道当一个View经过了measure()方法之后,其大小一般就是View的最终大小了(这里留下一个疑问:在什么时候测量大小不等于View的大小呢?)。所以我们常常去获取View的测量大小来使用,但是我们可以在什么时候获取测量大小呢?是在Activity的onCreate()、onStart()还是onResume()?大家可以去试试,最终答案是都不行。因为View的measure过程和Activity的生命周期是不同步的,也就是说可能在Activity的onResume()方法时,View的measure还没完成,那就更别说onCreate()和onStart(),而如果View还没measure完的话,那获取的测量大小都是0。下面有4中方法解决这个问题:
        • 1.Activity#onWindowFocusChanged():这个方法的在View全部被初始化完毕的时候调用,而且当Activity频繁的执行onResume()和onPause()这两个方法,那么onWindowFocusChanged()就会频繁的被调用。
        • 2.View#post(Runnable):这个方式是将消息投递到消息队列的尾部,当Looper调用此Runnable的时候,View也初始化好了,我们可以再Runnable内部获取测量的数值。
        • 3.使用ViewTreeObserver的回调来获取。
        • 4.在View的measure()方法中手动获取。
    • 2.layout过程:layout的作用是ViewGroup来确定子View的位置的。当ViewGroup的位置被确定之后,ViewGroup会在onLayout()方法中遍历所有子元素并调用子元素的layout()方法,然后layout()方法再调用onLayout()方法,像这样循环一直等到整个View树全部被Layout。由于ViewGroup的layout()方法是继承于View的,所以我们只需要看View的layout()方法就可以了。
      • 1.在ViewGroup调用View的layout()时,会传入四个int参数,分别为距离ViewGroup左边,顶上,右边,下面的距离。
      • 2.layout()内部首先会调用setFrame()来通过layout()传入的四个参数来设置View的四个定点在ViewGroup中的位置。接着会调用onLayout()方法,这个方式是为了让父View确定子View的位置而写的。而确定子View的位置方式与具体的ViewGroup有关,所以View和ViewGroup都没有onLayout()的具体实现
      • 3.我们来看看LinearLayout中的onLayout()是怎么实现了:
        • 1.根据模式的不同,onLayout()内调用的方法也不同,我们这里说说当为VERTICAL模式的时,会调用layoutVertical()传入四个int参数。
        • 2.layoutVertical()方法也很简单,就是遍历子View,然后计算出子View距LinearLayout四个边缘的距离,然后调用setChildFrame(),将四个参数传进去。
        • 3.setChildFrame()内部就是调用子View的layout()方法。值得注意的是,这里用到了measure完毕之后产生的View的宽高,用于计算View的四边距离ViewGroup的四边的距离。而我们最终的View的大小就是,这里传入的参数两两的差值。所以我们可以解决上面所说的疑问,在什么时候measure的大小不等于View的大小呢?我们可以自己定义layout()方法中传递进去的四个参数,这样一来的话,测量出来的大小就和最终View的大小不一样了,但是这样没有任何实际用处。
    • 3.draw过程:draw的过程就简单了主要就是以下几步
      • 1.drawBackground(canvas):画背景,如果需要的话
      • 2.onDraw(canvas):绘制自己
      • 3.dispatchDraw(canvas):绘制children
      • 4.onDrawScrollBars(canvas):绘制装饰

    4.自定义View

    • 1.自定义View的分类:
      • 1.继承View重写onDraw()方法:采用这种方式的时候记得实现wrap_content这种模式原因之前讲过了,还有就是padding也可以处理一下。
      • 2.继承ViewGroup:这种ViewGroup实现起来比较复杂:我们必须根据自己的需求重写onMeasure()和onLayout()这两个方法,并且处理好子View的测量和布局。
      • 3.继承特定的View(如TextView)还有ViewGroup(比如LinearLayout):这种方法还是比较简单的。
    • 2.自定义View的须知:
      • 1.尽量不要在View中使用Handle来发送消息,因为View内部已经提供了post系列的方法来代替Handle。
      • 2.View中如果有动画或者线程的话需要及时停止:包括但不限于包含此View的Activity退出了、View被remove了或者是View不可见了等等。而在这个时候View#onDetachedWindow()会被调用,所以这是一个退出的好时机。与之相对的则是View#onAttachedWindow()方法。
      • 3.当View中有滑动的时候,必须处理好滑动冲突,具体参见事件分发那一小节。
    • 3.自定义属性
      • 1.在attr文件中用declare-styleable标签定义属性
      • 2.在构造函数中定义TypedArray ta=Context.obtainStyleAttributes(AttributeSet,int),获取刚刚定义的属性
      • 3.调用ta的函数获取在xml中定义的属性值
      • 4.调用ta.recycle(),回收资源。
    • 4.View的孪生兄弟——SurfaceView
      • 1.首先使用SurfaceView的前提是,需要自定义View并且这个自定义View刷新频繁,适用于画板等需要展现实时画面动态的自定义View
      • 2.使用SurfaceView需要定义几个变量:SurfaceHolder、Canvas、Runnale、Boolean。
      • 3.在自定义的View中每个SurfaceView中已经有SurfaceHolder了所以直接调用getHolder()即可。
      • 4.SurfaceHolder中有Canvas,通过lockCanvas()获得。可以通过在这个Canvas上直接画图来使SurfaceView发生变化。
      • 5.而Runnale的作用就是开辟一个循环的线程,不断调用Canvas进行绘制,这样就能频繁的刷新自定义测View了。
      • 6.最后一个Boolean则是起flag的作用,用来判断是否在线程中进行绘制。

    你可能感兴趣的:(android源码)