Android-invalidate原理分析

Posted 2023-05-17

参考技术A 其实postInvalidate最终也是调用的invalidate来实现。

AttachInfo.mViewRootImpl其实就是ViewRootImpl对象

这里的mHandler对象，其实是ViewRootImpl内部类ViewRootHandler对象，

而这里的msg.obj其实就是View对象

从网上拿来用的一张图，自己就不画了。

根据查找ViewParent接口实现我们可以知道，ViewGroup是ViewParent的实现类，所以这里是调用了ViewGroup.invalidateChild()

因为parent是在invalidateChild中赋值的，其实就是ViewGroup本身，所以是调用的ViewGroup的invalidateChildInParent方法

但是因为ViewGroup.invalidateChild方法中执行的是一个do-while循环，不断的循环返回View的mParent，而ViewGroup最终的mParent其实是DecorView，而DecorView.mParent其实就是ViewRootImpl，所以这里最终会调用到ViewRootImpl.invalidateChildInParent

scheduleTraversals()方法内部通过调用Choreographer.postCallback方法，其内部就是通过Handler，然后在doFrame中调用doCallbacks，通过遍历CallbackRecord这个链表，执行保持在CallbackRecord中的action（即Runnable）的run方法。就是TraversalRunnable对象mTraversalRunnable

CallbackRecord是一个链表结构，在这里最终就会判断是否是帧callback token，如果不是，则调用action.run()，这里的action其实就是TraversalRunnable

执行到TraversalRunnable的run()

调用了ViewRootImpl.doTraversal()

在这里会调用performTraversals()

performTraversals方法比较长，所以看一部分

这个方法主要是做了三个操作，即调用performMeasure、performLayout、performDraw，而invalidate流程是否会触发performMeasure和performLayout姑且不论，因为这里需要经过繁琐的标志位的判断，但是会执行performDraw。而performMeasure和performLayout分别是measure过程和layout过程，是由View.requestLayout()或者WindowManagerImpl.addView调用WindowManagerGlobal.addView这个两种情况最终调用了ViewRootImpl.requestLayout来触发调用performMeasure和performLayout。

在这里调用了ViewRootImpl.draw()

从这里可以看出，最终是调用了View.draw()方法。
其实invalidate()方法的使用，就是重新触发一次draw流程，进行绘制。通过View.invalidate()方法在ViewGroup的invalidateChild()方法中执行一个do-while循环，最终调用了ViewRootImpl.invalidateChildInParent()，而在ViewRootImpl.invalidateChildInParent()方法中最终触发调用了ViewRootImpl.scheduleTraversals()，又一次执行了与measure过程和layout过程一致的流程，因为scheduleTraversals()方法会通过一系列的调用最终调用TraversalRunnable.run()方法，在TraversalRunnable.run()方法中会调用performTraversals()，这个方法其实就是做了三件事：measure、layout和draw

参考下
https://www.jianshu.com/p/33b855dcde5a

kubeadm工作原理-kubeadm init原理分析-kubeadm join原理分析

kubeadm工作原理-kubeadm init原理分析-kubeadm join原理分析。kubeadm是社区维护的Kubernetes集群一键部署利器，使用两条命令即可完成k8s集群中master节点以及node节点的部署，其底层原理是利用了k8s TLS bootstrap特性。

kubeadm概述

kubeadm是社区维护的Kubernetes集群一键部署利器，使用两条命令即可完成k8s集群中master节点以及node节点的部署，其底层原理是利用了k8s TLS bootstrap特性。

kubeadm部署k8s集群示例

（1）k8s master节点部署：

$ kubeadm init

此外，我们也可以自己编写yaml文件来自定义kubeadm的启动过程和一些组件的启动参数等等

$ kubeadm init --config xxx.yaml

（2）k8s node节点部署（将一个node节点加入到已有集群当中）：

$ kubeadm join <kube-apiserver的ip + 端口> --token <token>

此外，我们也可以自己编写yaml文件来自定义kubeadm的启动过程和一些组件的启动参数，包括kube-apiserver的ip与端口、token等

$ kubeadm join --config xxx.yaml

关于自定义yaml文件以及更多的kubeadm用法请参考：https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

k8s TLS bootstrap概述

当k8s集群开启了TLS认证后，每个节点的kubelet组件都要使用由kube-apiserver的CA签发的有效证书才能与kube-apiserver通信；当节点非常多的时候，为每个节点都单独签署证书是一件非常繁琐而又耗时的事情。

此时k8s TLS bootstrap功能应运而生。

k8s TLS bootstrap功能就是让kubelet先使用一个预先商定好的低权限token连接到kube-apiserver，向kube-apiserver申请证书，然后kube-controller-manager给kubelet动态签署证书，后续kubelet都将通过动态签署的证书与kube-apiserver通信。

关于k8s TLS bootstrap的详细分析这里暂时不展开。

kubeadm原理解析

大致流程

在k8s master中，会先启动一个kubelet，控制面组件通过kubelet static pod特性启动，在k8s master控制面组件启动成功后，其他节点需要加入到k8s集群时，使用TLS bootstrap来简化加入的过程，先通过bootstrap-token与kube-apiserver通信，自动从kube-controller-manager处签发拿到与kube-apiserver通信的证书，然后自动生成与kube-apiserver通信的kubeconfig文件，后续将使用kubeconfig文件与kube-apiserver进行通信。

详细流程解析

1.kubeadm init

kubeadm init的结果是完成一个k8s master节点的部署，包括kube-apiserver、kube-controller-manager、kube-scheduler、etcd等控制面组件以及kubelet数据面组件，即该master节点既是控制面又是数据面，所以master节点上也是可以运行pod的；

以下为kubeadm init的处理流程代码（基于k8s v1.17.4版本），一共13步：

// cmd/kubeadm/app/cmd/init.go-NewCmdInit()
    ...
    // initialize the workflow runner with the list of phases
	initRunner.AppendPhase(phases.NewPreflightPhase()) // 1.环境检查
	initRunner.AppendPhase(phases.NewKubeletStartPhase()) // 2.配置并启动kubelet
	initRunner.AppendPhase(phases.NewCertsPhase()) // 3.证书生成
	initRunner.AppendPhase(phases.NewKubeConfigPhase()) // 4.kubeconfig文件生成
	initRunner.AppendPhase(phases.NewControlPlanePhase()) // 5.控制面组件yaml生成
	initRunner.AppendPhase(phases.NewEtcdPhase()) // 6.etcd组件yaml生成
	initRunner.AppendPhase(phases.NewWaitControlPlanePhase()) // 7.等待控制面组件运行
	initRunner.AppendPhase(phases.NewUploadConfigPhase()) // 8.上传配置
	initRunner.AppendPhase(phases.NewUploadCertsPhase()) // 9.上传CA证书/私钥
	initRunner.AppendPhase(phases.NewMarkControlPlanePhase()) // 10.master节点打污点
	initRunner.AppendPhase(phases.NewBootstrapTokenPhase()) // 11.生成bootstrap token和ca证书configmap
	initRunner.AppendPhase(phases.NewKubeletFinalizePhase()) // 12.更换kubelet证书
	initRunner.AppendPhase(phases.NewAddonPhase()) // 13.安装Addon
	...

（1）环境检查。检查项包括操作系统内核版本、k8s组件暴露服务的指定端口是否被占用、docker是否安装、iptables命令是否安装等等，其实这一步还包括了拉取kubeadm部署所需的镜像；

（2）配置并启动kubelet。创建kubelet启动所需的配置文件，并启动kubelet，kubeadm使用了systemd的方式部署启动kubelet；

# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; disabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) ...

为什么master上还需要配置启动kubelet呢？

因为kubeadm init的时候需要将master控制面组件kube-apiserver、kube-controller-manager、kube-scheduler、etcd以pod的方式运行起来，而现在又没有在运行的控制面以及kubelet，怎么办呢，kubeadm的做法是，给master节点上也安装启动kubelet，然后使用kubelet static pod特性将master控制面组件运行起来。

关于static pod，详细内容可参考：https://kubernetes.io/zh/docs/tasks/configure-pod-container/static-pod/

（3）证书生成。即生成kubernetes对外提供服务所需的各种证书，放到/etc/kubernetes/pki目录下；

# ls /etc/kubernetes/pki
apiserver.crt  apiserver-etcd-client.crt  apiserver-etcd-client.key  apiserver.key  apiserver-kubelet-client.crt  apiserver-kubelet-client.key	ca.crt	ca.key	etcd  front-proxy-ca.crt  front-proxy-ca.key  front-proxy-client.crt  front-proxy-client.key  sa.key  sa.pub

（4）kubeconfig配置文件生成。即生成master节点上kube-controller-manager、kube-scheduler、kubelet组件等访问kube-apiserver的kubeconfig文件，放到/etc/kubernetes目录下，文件包含了apiserver的地址、监听端口、证书等信息，使用该kubeconfig文件即可直接与kube-apiserver通信；

# ls /etc/kubernetes
admin.conf  controller-manager.conf  kubelet.conf  manifests  pki  scheduler.conf

master上的kubelet启动后，使用kubeadm生成的kubeconfig与kube-apiserver进行通信，通过证书轮换，向kube-apiserver申请新的证书，由kube-controller-manager签发证书返回。

注意：这里master上的kubelet不会使用TLS bootstrap特性。

（5）控制面组件yaml文件生成。即kubeadm为4个控制面组件kube-apiserver、kube-controller-manager、kube-scheduler生成pod yaml文件，放到/etc/kubernetes/manifests目录下，然后kubelet会根据static pod特性，使用pod的方式将它们部署起来；

# ls /etc/kubernetes/manifests
kube-apiserver.yaml	kube-controller-manager.yaml  kube-scheduler.yaml

（6）etcd组件yaml文件生成。即kubeadm为etcd组件生成pod yaml文件，放到/etc/kubernetes/manifests目录下，然后kubelet会根据static pod特性，使用pod的方式将etcd部署起来；

# ls /etc/kubernetes/manifests
etcd.yaml  kube-apiserver.yaml	kube-controller-manager.yaml  kube-scheduler.yaml

（7）等待控制面组件运行。kubeadm会不间断检查localhost:6443/healthz这个url，等待master组件完全启动；

（8）上传配置。这里会创建2个configmap有，都创建在kube-system命名空间下，名称分别是kubeadm-config、kubelet-config-xxx（k8s版本），分别存储着kubeadm的集群配置信息、kubelet的配置信息；

（9）上传CA证书/私钥。该步骤默认不执行，通过增加——upload-certs参数启用，它会将相关的CA证书/私钥加密后作为data，在kube-system命名空间下创建名称为kubeadm-certs的secret，给后续的master节点kubeadm join使用，这样join时可以直接从secret中解密出CA证书/私钥，然后签发其他证书，而无需手工复制相关CA证书/私钥；

kubeadm init执行完成后，会输出一个名称为certificateKey的值，然后在其他master节点join时，加上--certificate-key参数即可。

certificateKey是在添加新的master节点时用来解密kubeadm-certs secret中的证书的秘钥。

kubeadm-certs示例如下，其中的证书和私钥均已加密，通过certificateKey解密即可使用：

apiVersion: v1
data:
  ca.crt: KfdZpEDF1wJfaexXls5...
  ca.key: VXfm7luIyM3QT+Rd04+...
  etcd-ca.crt: wwSzqCcltkrP26...
  etcd-ca.key: gqusZazZLF33Ip...
  front-proxy-ca.crt: EmfgKP6...
  front-proxy-ca.key: wKMYSrk...
  sa.key: pscxeFTGoCFZ6hrE1XK...
  sa.pub: keey1WPkWdj2TjEb/oM...
kind: Secret
metadata:
  name: kubeadm-certs
  namespace: kube-system
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Secret
    name: bootstrap-token-xxxxxx
    ...
  ...
type: Opaque

注意：secret kubeadm-certs和解密密钥certificateKey会在两个小时后失效。

（10）master节点打污点。将该master节点打上污点，不作为计算节点数据面使用；

（11）生成bootstrap token和ca证书configmap。

kubeadm会为该k8s集群生成一个bootstrap token并打印出来，后续的node节点通过这个token，通过kubeadm join命令，使用TLS bootstrap特性即可加入到这个k8s集群中，当然，这里还包括了为该token创建RBAC的各个对象，赋予该token创建CSR证书签名请求的权限、自动批复CSR请求的权限、轮换证书请求自动批复的权限等，这里不展开介绍，后续分析k8s TLS bootstrap原理时再做分析；

kubeadm init执行完成后，也可以通过以下命令获取token：

# kubeadm token list

kubeadm还会将ca.crt、apiserver url等信息，保存到一个configmap当中，给后续加入该k8s集群的node节点使用，configmap名称为cluster-info，位于kube-public命名空间下；

# kubectl get configmap -n kube-public -o yaml cluster-info
apiVersion: v1
data:
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F...
        server: https://192.168.1.10:6443
      name: ""
    contexts: null
    current-context: ""
    kind: Config
    preferences: 
    users: null
kind: ConfigMap
metadata:

（12）更换kubelet证书。前面说过，master上的kubelet启动后，使用kubeadm生成的kubeconfig与kube-apiserver进行通信，通过证书轮换，向kube-apiserver申请新的证书，由kube-controller-manager签发证书返回。而这里说的更换kubelet证书，其实就是将kubelet与kube-apiserver通信的kubeconfig文件中的证书替换成由kube-controller-manager签发返回的证书，即将kubeconfig文件中的client-certificate与client-key的值都替换成/var/lib/kubelet/pki/kubelet-client-current.pem；

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F...
    server: https://192.168.1.10:6443
  name: test-cluster
contexts:
- context:
    cluster: test-cluster
    user: system:node:test-cluster-master-1
  name: system:node:test-cluster-master-1
current-context: system:node:test-cluster-master-1
kind: Config
preferences: 
users:
- name: system:node:test-cluster-master-1
  user:
    client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
    client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

（13）安装Addon。安装coredns与kube-proxy，kubeadm init流程结束。

2.kubeadm join

kubeadm join的结果是完成一个k8s master节点或node节点加入一个已有的k8s集群。

以下为kubeadm join的处理流程代码（基于k8s v1.17.4版本），一共5步：

// cmd/kubeadm/app/cmd/join.go-NewCmdInit()
    ...
    joinRunner.AppendPhase(phases.NewPreflightPhase()) // 1.环境检查
	joinRunner.AppendPhase(phases.NewControlPlanePreparePhase()) // 2.控制面准备
	joinRunner.AppendPhase(phases.NewCheckEtcdPhase()) // 3.检查etcd是否健康
	joinRunner.AppendPhase(phases.NewKubeletStartPhase()) // 4.启动kubelet
	joinRunner.AppendPhase(phases.NewControlPlaneJoinPhase()) // 5.控制面操作
	...

（1）环境检查。检查项包括操作系统内核版本、k8s组件暴露服务的指定端口是否被占用、docker是否安装、iptables命令是否安装等等，但这里的环境检查与kubeadm init时的检查有点不同，这里会区分是join的master节点还是node节点，如果是node节点，则仅仅进行node相关的检查；

另外，这里还会获取kube-public命名空间下的configmap对象cluster-info，从中CA、master api等信息；

（2）控制面准备。如果是node的join，这一步的逻辑不会执行。这里会从kube-system命名空间中加载名称为kubeadm-certs的secret对象，然后生成控制面组件kube-apiserver、kube-controller-manager、kube-scheduler所需的证书，最后生成它们的部署yaml，放置到kubelet的static pod目录下，被kubelet使用static pod特性启动；

（3）检查etcd是否健康。

（4）启动kubelet。根据CA、bootstrap token等信息生成/etc/kubernetes/bootstrap-kubelet.conf文件，通过TLS bootstrap机制，kubelet使用bootstrap token来向kube-apiserver申请证书，由kube-controller-manager签发证书返回，然后kubelet根据返回的证书生成kubeconfig文件并写入到/etc/kubernetes/kubelet.conf文件，后续kubelet将会使用该kubeconfig文件来与kube-apiserver通信；

# cat /etc/kubernetes/kubelet.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F...
    server: https://192.168.1.10:6443
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    namespace: default
    user: default-auth
  name: default-context
current-context: default-context
kind: Config
preferences: 
users:
- name: default-auth
  user:
    client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
    client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

注意：bootstrap-kubelet.conf文件会在kubelet.conf文件生成后，被kubeadm删除掉；

（5）控制面操作。如果是node的join，这一步的逻辑不会执行。控制面操作包括生成etcd的static pod yaml、更新kube-system命名空间下的configmap对象kubeadm-config，将该控制节点信息更新进去、将该master节点打上污点，不作为计算节点数据面使用；至此，kubeadm join流程结束。