Android开发艺术探索读书笔记(三)

日以继夜近两个星期,终于完成这篇了,之所以自己这么看重,是因为这篇应该是读书笔记里最重要的一篇了,这篇能吃透的话,基本安卓app层玩的机制都能理解的很清楚了,所以我也倾注了全部的心血来写这篇,希望跟大家一起分享。
简单先说下:这里将第九章(四大组件的工作过程),第十章(Android的消息机制)放在第八章(理解Window和WindowManager)前面的原因是:学习理解Window的知识最好需要先了解Activity的运行机制以及handler的工作原理,所以大家读主席这本书的时候也建议按照这个顺序来读这三章,对window的理解会更水到渠成,以上。如果看这篇前你还没有去看第二章的IPC机制,我强烈建议你看懂IPC再回来看这篇,会发现一切都变得非常清晰。热切期盼各位看完能有收获,有任何错误或者疑问都可在评论中给出,我会一一回复,感谢~

Chapter-9 四大组件的工作过程

  1. 先说两句,玉刚的书中主要侧重的是过程分析和代码讲解,这样一页一页的翻完之后总有一种意犹未尽却不够清晰的感觉,一开始我依然是用文字list的方式来梳理,后来发现看起来还是有点不够清晰,达不到我想要的效果,所以改了两版后我决定用图 + 文字说明的方式来表现,希望大家可以看得更清晰。注意这里左侧是用UML画的流程图,发现还挺方便的,类中的方法是按照调用顺序排列的,右侧的UML图则是真正的UML图,会标注出一些重要类的结构关系,排除各位看书时看到各种A继承B,B继承C时晕了的感觉。
  2. 四大组件概述:
    1) Activity的主要作用是展示一个界面并和用户交互,它扮演的是一种前台界面的角色。
    2) Service是一种计算型组件,用于在后台执行一系列计算任务,但因为其本身还是运行在主线程中的,因此耗时的后台计算仍然需要在单独的线程中去完成。
    3) BroadcastReceiver是一种消息型组件,用于在不同的组件乃至不同的应用之间传递消息。广播注册有两种方式,动态注册通过Context.registerReceiver()来实现,必须要应用启动才能注册;静态注册则在AndroidManifest文件中进行,应用安装时会被系统解析,不需要启动应用就可接收广播。
    4) ContentProvider是一种共享型组件,用于向其他组件乃至其他应用共享数据。
  3. Activity的工作过程
    这里写图片描述
  4. Service
    启动:
    这里写图片描述
    绑定:
    这里写图片描述
  5. BroadcastReceiver
    注册(动态):
    这里写图片描述
    发送和接收:
    这里写图片描述
  6. ContentProvider
    1) 当ContentProvider所在的进程启动的时候,它会同时被启动并被发布到AMS中,这个时候它的onCreate要先去Application的onCreate执行。
    2) 启动方式请看page363,这里就不画了,书上画的非常清晰易懂,就写几个tips 吧。
    a. 应用启动的入口为ActivityThread的main方法,main方法会创建ActivityThread实例并创建主线程消息队列。
    b. attach方法中远程调用AMS的attachApplication方法,并提供ApplicationThread用于和AMS的通信。
    c. attachApplication方法会通过bindApplication方法和H来调回ActivityThread的handleBindApplication,这个方法会先创建Application,再加载ContentProvider,然后才会回调Application的onCreate方法。
    d. ContentProvider的multiprocess属性决定了ContentProvider是否是单例(false时),一般都用单例。
    e. ContentResolver的具体类是ApplicationContentResolver,当ContentProvider所在进程未启动时,第一次访问它会触发ContentProvider的创建以及进程启动。
    3) query流程
    这里写图片描述

Chapater-10 Android的消息机制

  1. 三大件:Hanlder,MessageQueue,Looper。
  2. MessageQueue内部的数据结构并非队列,而是单链表,它只是用来存储数据。
  3. Looper是真正的数据处理者,线程默认没有Looper,使用Handler必须为线程创建Looper,UI线程也就是ActivityThread创建时会初始化Looper,所以主线程中默认可以直接使用Handler。
  4. UI线程检查当前线程的操作在ViewRootImpl的checkThread方法中,我们常见的不能在子线程中访问view的异常就是在这里抛出的。
  5. 不允许子线程访问主线程的原因是UI控件不是线程安全的,而加锁又会导致UI的操作过于复杂。
  6. Handler的工作过程,图(page374),我简单概括一下就是:假设创建Handler的线程是A,耗时操作的线程是B,B线程中拿到handler实例发送消息或者post一个Runnable,实际是调用了MessageQueue的enqueueMessage方法,进入了消息队列,线程A中的Looper发现了这个消息,就会处理这个消息,也就是消息中的Runnable或者handler的handleMessage方法会被调用,这样handler中的业务逻辑就被切换到线程A中去了。
  7. ThreadLocal我用一句大白话来讲解,就是看上去只new了一份,但在每个不同的线程中却可以拥有不同数据副本的神奇类。其本质是ThreadLocal中的Values类维护了一个Object[],而每个Thread类中有一个ThreadLocal.Values成员,当调用ThreadLocal的set方法时,其实是根据一定规则把这个线程中对应的ThreadLocal值塞进了Values的Object[]数组中的某个index里。这个index总是为ThreadLocal的reference字段所标识的对象的下一个位置。
  8. MessageQueue的工作原理:主要方法为enqueueMessage和next。
    a. enqueueMessag主要就是一个单链表的插入操作,
    b. next方法是一个无限循环,如果消息队列中没有消息,next方法就阻塞,有新消息到来时,next方法会返回这条消息并将其从单链表中删除。
  9. Looper的工作原理:
    a. prepare方法,为当前没有Looper的线程创建Looper。
    b. prepareMainLooper和getMainLooper方法用于创建和获取ActivityThread的Looper。
    c. quit和quitSafely方法,前者立即退出,后者只是设定一个标记,当消息队列中的所有消息处理完毕后会才安全退出。子线程中创建的Looper建议不需要的时候都要手动终止。
    d. loop方法,死循环,阻塞获取msg并丢给msg.target.dispatchMessage方法去处理,这里的target就是handler。
  10. Handler的工作原理:
    a. 无论sendMessage还是post最终都是调用的sendMessageAtTime方法。
    b. 发送消息其实就是把一条消息通过MessageQueue的enqueueMessage方法加入消息队列,Looper收到消息就会调用handler的dispatchMessage方法。它的处理过程参考书page388的流程图,一看就懂~
    c. 这里我补充一个东西,当我们直接Handler h = new Handler()时,本质调用的是Handler(Callback callback, Boolean async)构造方法,这个方法里会调用Looper.myLooper()方法,这个方法其实就是返回的ThreadLocal里保存的当前线程的Looper,这也就解释了为什么我们在主线程中这样new没有问题,子线程中如果不先Looper.prepare会抛出异常的原因,前面多次说了,因为ActivityThread会在初始化的时候创建自己的Looper。
  11. 主线程的消息循环:
    这里写图片描述

Chapter-8 Window和WindowManager

  1. 一些基础知识:
    1) Window的实现类是PhoneWindow。
    2) Window的具体实现位于WindowManagerService中,WindowManager和WindowManagerService的交互是一个IPC过程。
    3) Window实际是View的直接管理者。
  2. 常用的WindowManager.LayoutParams的Flag和Type
    1) FLAG:
     FLAG_NOT_FOCUSABLE,当前Window不获取焦点,也不接收各种输入事件,会同时启用FLAG_NOT_TOUCH_MODAL,事件会传递给下层具有焦点的Window。
     FLAG_NOT_TOUCH_MODAL,当前Window区域外的单击事件传递给底层,区域内的单击事件自己处理,一般都需要开启。
     FLAG_SHOW_WHEN_LOCKED,可以让Window显示在锁屏界面上。
    2) Type:
     应用Window,一般对应一个Activity。层级范围1~99。
     子Window,不能单独存在,需要特定的父Window,比如一般的Dialog。层级范围1000~1999。
     系统Window,需要权限声明,比如Toast。层级范围2000~2999。一般可以选用WindowManager.LayoutParams.TYPE_SYSTEM_ERROR,同时声明权限。
    3) WindowManager提供的功能:addView,updateViewLayout,removeView
  3. Window的内部机制:Window并不实际存在,以View的形式存在。每个Window对应着一个View和ViewRootImpl,Window和View通过ViewRootImpl建立联系。所以在实际使用中其实我们并不能访问到真正的Window,而只能通过WindowManager。
    1) 几个重要的window类的关系(发现主席不大爱画UML,我就代工了)
    这里写图片描述
    2) Window的添加过程
     WindowManagerGlobal中的addView:
     检查参数是否合法;
     如果子Window还需要调节布局参数;
     创建ViewRootImpl并将View添加到列表中;
     通过ViewRootImpl的setView来更新界面并完成Window的添加过程:requestLayout中的scheduleTraversals是View绘制的入口,最终通过WindowSession来完成Window的添加过程,注意其实这里是个IPC过程,最终会通过WindowManagerService的addWindow方法来实现Window的添加。
    3) Window的删除过程
     WinodwManagerGlobal中的removeView;
     findViewLocked来查找待删除待View的索引,再调用removeViewLocked来做进一步删除;
     removeViewLocked通过ViewRootImpl的die方法来完成删除操作,包括同步和异步两种方式,同步方式可能会导致意外的错误,不推荐,一般使用异步的方式,其实就是通过handler发送了一个删除请求,将View添加到mDyingViews中;
     die方法本质调用了doDie方法,真正删除View的逻辑在该方法的dispatchDetachedFromWindow方法中,主要做了四件事:垃圾回收,通过Session的remove方法删除Window,调用View的dispatchDetachedFromWindow方法同时会回调View的onDetachedFromWindow以及onDetachedFromWindowInternal,调用WindowManagerGlobal的doRemoveView刷新数据。
    4) Window的更新过程
    WindowManagerGlobal的updateViewLayout;
    更新View的LayoutParams;
    更新ViewImple的LayoutParams,实现对View的重新测量,布局,重绘;
    通过WindowSession更新Window的视图,WindowManagerService.relayoutWindow()。
  4. Window的创建过程
    1) Activity
     Activity的attach方法中,系统会创建Activity所属的Window并为其设置回调;
     Window对象的创建通过PolicyManager的makeNewWindow方法;
     Window的具体实现是PhoneWindow类;
     Window创建好之后,通过PhoneWindow的setContentView将Activity与Window进行关联,这个方法大致步骤:
    a. 如果没有DecorView就创建,id是android.R.id.content;
    b. 将Activity设置的ContentView设置到DecorView的mContentParent中;
    c. 回调Activity的onContentChanged方法通知Activity视图已经发生改变;
    d. Activity onResume的时候会调用Activity的makeVisible方法真正完成DecorView的添加和显示。
    2) Dialog
    a. 通过PolicyManager的makeNewWindow方法创建Window;
    b. 初始化DecorView,和Activity类似;
    c. Dialog的show方法中,通过WindowManager将DecorView添加到Window中;
    d. Dialog关闭时,会通过WindowManager来移除DecorView,方法为removeViewImmediate(mDecor);
    e. 想要创建一个使用application context的Dialog可按照本章2-2的方法设置,dialog.getWindow.setType(WindowManager.LayoutParams.TYPE_SYSTEM_ERROR),记得在manifest中设置权限。
    3) Toast
    a. Toast内部有两类IPC:Toast访问NotificationManagerService;NotificationManagerService(下文简称NMS)访问Toast的TN接口;
    b. Toast属于系统Window,内部视图mNextView一种为系统默认样式,另一种通过setView方法来指定一个自定义View。
    c. TN是一个Binder类,NMS处理Toast的显示隐藏请求时会跨进程回调TN中的方法,所以TN运行在Binder线程池中,所以需要handler切换到当前发送Toast请求的线程中,也就是说没有Looper的线程是无法弹出Toast的。
    d. Toast的show方法调用了NMS的enqueueToast方法,该方法先将Toast请求封装成ToastRecord并丢入mToastQueue队列中(非系统应用最多塞50个)。
    e. NMS通过showNextToastLocked方法来显示当前View,Toast显示由ToastRecord的callback方法中的show方法完成,callback其实就是TN对象的远程Binder,所以最终调用的是TN中的方法,并运行在发起Toast请求应用的Binder线程池中。
    f. 显示以后,NMS通过scheduleTimeoutLocked方法发送延时消息,延时后NMS通过cancelToastLocked方法来隐藏Toast并从队列中移除,隐藏依然通过ToastRecord的callback中的hide方法实现。
    g. callback回调TN的show和hide方法后,会通过handler发送两个Runnable,里面的handleShow和handleHide方法是真正完成显示和隐藏Toast的地方。handleShow方法中将Toast的视图添加到Window中,handleHide方法将Toast视图从Window中移除。
阅读更多

没有更多推荐了,返回首页