菜单管理，感觉上是个小模块，但实际做下来的感触是，要做的好用，不容易。
算法和数据结构，长期活跃在面试题中，实际业务中好像接触的不多，但如果能用好，可以解决大问题。

如上图，是我在开源世界找到的一个菜单管理的设计页面，其上可以看到，菜单管理主要管理一颗菜单树，可以增删改查、排序等功能。接下来，我们就一步一步的实现菜单管理的各个功能，这里我主要介绍后端的设计方案，不涉及前端页面的处理和展示。

type IMenu interface {

	MenuList(ctx context.Context, platformId int, menuName string, status int) ([]*model.MenuListResp, response.Error)

        GetMenuInfo(ctx context.Context, menuId int) (*model.MenuInfo, response.Error)

	EditMenu(ctx context.Context, params *model.MenuEditParams) response.Error

	DeleteMenu(ctx context.Context, platformId, menuId int) response.Error

	AddMenu(ctx context.Context, params *model.MenuAddParams) response.Error

        

	MenuExport(ctx context.Context, platformId int) ([]byte, response.Error)

        MenuImport(ctx context.Context,platformId int,jsonData []byte) response.Error

        

	MenuSort(ctx context.Context, platformId int, tree []*model.MenuTree) response.Error      

}

可以看到，菜单管理模块主要分三块，一是对菜单的增删改查、二是菜单的导入导出、三是菜单的排序。 由于菜单模块天然的就是一个树状结构，所以我就想到能不能在代码中用树作为处理菜单时的数据结构，把这个模块做完后，我发现这种思路是对的，可以解决菜单树的重排问题，无需在手动填写排序字段（就是人工为菜单的顺序赋值）。

首先我们设计数据库，由于我们确认了以树处理菜单的思路，所以在表设计时，我把菜单信息和菜单树剥离，首先避免了字段过多，其次在用menu_id去获取单个菜单信息时，就完全不用遍历树了，直接从菜单信息表中拿数据，而且表分开后，代码逻辑也更清晰了。

介绍一下表中的关键字段，其它字段可忽略：

一、 添加菜单

添加菜单接口所需的信息如下：

type MenuAddParams struct {

	PlatformId   int   `json:"platform_id" v:"required"`       // 平台ID

	Type         int64 `json:"type" v:"required|in:1,2,3,4,5"` // 菜单类型 1菜单2子菜单3按钮4页签5数据标签

	ParentMenuId int   `json:"parent_menu_id"`                 // 上级菜单，没有则传0



        // 菜单信息

	Name       string `json:"name" v:"required|length:3,20"` // 菜单名

	...

}

添加菜单很简单，由于前端参数中已经存在父菜单id，我们只需要把这个菜单节点加到这个父菜单的子节点列表的末尾即可。

这里唯一需要注意的就是，我们需要 select MAX(index) 获取父节点的子节点列表中index最大的值，然后+1作为新节点的index，这样就可以把新节点添加到列表末尾。但要注意并发问题，比如两个人同时添加菜单，有可能会导致index一样。

解决方案就是把newIndex放到redis里，然后在添加时判断redis里的index是否>=数据库的maxIndex，理论上一定成立，不成立则说明newIndex还未写进db，流程图如下：

使用分布式锁，或者修改select MAX(index)的事务隔离级别也可以实现。

二、菜单列表

菜单列表与其说是列表，不如说是菜单树，树状返回整个菜单结构，不分页，两个原因：一、我们要在菜单列表上做拖曳排序，需要整个菜单树结构；二、菜单数据有它本身的特点，再多也就千级别顶天了，而且我们在数据存储时就区分了菜单树表（menu_tree）和(menu_info)，这时获取菜单列表只需要访问 menu_tree，菜单信息可以懒加载，需要时再通过 menu_id 主键id获取，速度很快。

接口返回结构设计如下：

{

    "data": {

        "children": [

            {

                "children": [

                    {

                        "children": [],

                        "menu_id": 2,

                        "name": "子菜单1",

                        "type": 1

                    }

                ],

                "menu_id": 1,

                "name": "菜单1",

                "type": 1

            }

        ],

        "menu_id": 0,

        "name": "",

        "type": 0

    },

    "errmsg": "",

    "errno": 0

}

我们用一个 menu_id 为0 的节点作为根节点，因为树需要一个唯一的根。
这里有人可能会说，不对啊，你 menu_tree 表里没有name和type，你不还是得去menu_info里获取吗？确实，实践中我确实有访问menu_info，但我感觉这两个字段其实可以冗余存储到 menu_tree中，这样优化后，就真的不用访问 menu_info了，只不过我模块已经写完了，就懒得改了，哈哈。

这个数据返给前端，他直接渲染成树即可，点击树中某个节点，前端拿到这个节点的menu_id，去GetMenuInfo获取菜单信息，前面说过，这个获取很简单，就是主键id查找。

要建立这样一个返回结构，用如下关键代码实现即可：

type MenuTree struct {

	MenuId int    `json:"menu_id"` // 菜单ID

	Name   string `json:"name"`    // 菜单名

	Type   int64  `json:"type"`    // 菜单类型 1菜单2子菜单3按钮4页签5数据标签



	Children []*MenuTree `json:"children"` // 子菜单

}



func (s *sMenu) MenuTree(ctx context.Context, platformId int) (*model.MenuTree, error) {

        // 构造一个根节点

	root := &model.MenuTree{}



	err := s.menuTreeChildren(ctx, root)

        if err != nil{

            return nil, err 

        }

	return root, nil

}



func (s *sMenu) menuTreeChildren(ctx context.Context, node *model.MenuTree) (error) {

        if node.MenuId != 0{

            menuInfo, err := dao.MenuInfo.GetMenuInfo(

		ctx,

		node.MenuId,

		dao.MenuInfo.Columns().Id,

		dao.MenuInfo.Columns().Name,

		dao.MenuInfo.Columns().Type,

            )

            if err != nil {

		return gerror.Wrap(err, "")

            }

            node.Name = menuInfo.Name

            node.Type = menuInfo.Type

        }



        // 获取子节点列表

        // select * from menu_tree where platform_id = ? and parent_menu_id = ?

	childs, err := dao.MenuTree.GetMenuTreeChild(ctx, platformId, tree.MenuId)

	if err != nil {

		return gerror.Wrap(err, "")

	}



	treeChilds := make([]*model.MenuTree, len(childs))

	for i, e := range childs {

                tree := &model.MenuTree{

                    MenuId: e.Id,

                }

		err := s.menuTreeChildren(ctx, platformId, tree)

                if err != nil{

                    return err

                }

		treeChilds[i] = tree

	}



	node.Children = treeChilds

	return nil

}

这个构造过程有没有一点点熟悉？这不就是树的dfs前序遍历算法的递归版本吗？

通过这种方式，我们把数据库中的树加载到内存中，后续的很多操作，都依赖对树的遍历实现。

三、编辑菜单、获取菜单信息

这两个操作都是只针对 menu_info 表的，用menu_id主键操作就行，没什么技术含量。

四、删除菜单

删除怎么实现呢？前面说过，后续的很多操作都是在对树进行遍历，那么删除也就很简单了，我们通过menuId确定要删除的节点，并遍历它的所有子节点，放到 treeIds 这个收集器中，当子节点遍历完毕时，把treeIds中收集的id取出来，去删除这条记录即可。

// menuIds 负责在遍历过程中收集所有的 menus_ids，treeIds 负责在遍历过程中收集 menu_tree表的主键

func (s *sMenu) deleteMenuTree(ctx context.Context, platformId, menuId int, menuIds []int, treeIds []int) ([]int, []int, error) {

	// 把menuId从菜单树中删除，并递归删除它的所有子菜单

	child, err := dao.MenuTree.GetMenuTreeChild(ctx, platformId, menuId)

	if err != nil {

		return menuIds, treeIds, err

	}

	menuIds = append(menuIds, menuId)

	menuTree, err := dao.MenuTree.GetMenuTreeByMenuId(ctx, platformId, menuId, dao.MenuTree.Columns().Id)

	if err != nil {

		return menuIds, treeIds, err

	}

	treeIds = append(treeIds, int(menuTree.Id))



	for _, e := range child {

		menuIds, treeIds, err = s.deleteMenuTree(ctx, platformId, int(e.MenuId), menuIds, treeIds)

		if err != nil {

			return menuIds, treeIds, err

		}

	}

	return menuIds, treeIds, nil

}

后续的删除代码就不再展示了，主键都收集完毕了，DELETE FROM ... WHERE id IN () 一条语句搞定即可。

五、菜单排序

来到本文的重点，菜单重排序，很多系统都是直接让用户填排序字段，非常容易出错，用过的人都知道，不太好用。我们直接来实现拖曳排序，而且可以任意拖曳，把节点拖到其它父节点，把节点拖到顶级菜单等，都可以实现。

首先前端同学需要实现拖曳组件，然后直接把拖曳后的整个菜单树回给我们即可，我们负责检查树的节点发生了什么变动。

前端同学也可以直接检测被拖曳的菜单id，和拖曳后的位置，把这些信息发给后端即可。不过为了让前端同学早点下班，这些活还是我们交给我们来干把。

我们现在拿到了前端发回的树结构，字段和数据跟我们通过菜单列表返回的json数据一致，只是其中有一个被拖曳的节点，不再原来的位置，它可能跟兄弟节点交换了顺序，可能变更了父节点，也可能变为顶级菜单。如何找到被拖曳的是哪个节点，并找到它拖曳后的位置和顺序呢？

在算法知识中，有一个很重要的思想，就是分治，当我们碰到比较复杂的问题时候，就一定要把它拆解为几个子问题解决，针对这个场景，我们可以拆分为以下几个问题：

• 如果被拖曳的节点变更了父节点，我们如何找到它的位置和顺序？
  我们先序dfs遍历这个新的菜单树，每个节点都去数据库查询它的parent_menu_id，如果发现数据库的父节点id跟新菜单树的父节点id对不上，则可以断定这个节点是被拖曳过来的，同时也就知道了它的新位置和顺序。
• 如果被拖曳的节点未变更父节点，只是变更了顺序，我们如何找到它？
  我们后序dfs遍历这个新菜单树，收集当前节点的子节点列表list1，并且从数据库中拉出当前节点的子节点列表list2，
  1. 如果 list1.len < list2.len
     说明这个节点有子节点被拖曳走了，我们不需要管这个节点，因为我们不关注被拖曳节点原先在哪儿。这个情况直接忽略即可
  2. 如果 list1.len > list2.len 说明有节点被拖曳进来，那我们遍历list1和list2找不同即可。
  3. 如果 list1.len == list2.len 也是遍历list1和list2，看看它们两是不是完全一样。
• 找到被拖曳的节点以及它的新位置和顺序后，如何更新到数据库？
  更新这个节点的父节点id，并要判断它的顺序
  1. 它的新顺序就在父节点的子节点列表末尾
     子节点列表（有序的）最后一个节点的index + 1即可
  2. 它在子节点列表的开头或者中间
     它获得原节点的index，后续节点的index依次+1
  3. 原先就没有子节点，它是第一个
     那它的index设为1即可

具体的代码实现如下：

func (s *sMenu) MenuSort(ctx context.Context, platformId int, tree []*model.MenuTree) response.Error {

	s.lockSortMenu(ctx, platformId)

	defer s.unlockSortMenu(ctx, platformId)



	err = s.dfsTreeSort(ctx, platformId, &model.MenuTree{

		Children: tree,

	}, 0)

        if err != nil && err != StopDFS {

            return nil, response.NewErrorAutoMsg(

			http.StatusServiceUnavailable,

			response.ServerError,

		).WithErr(err)

        }

	return

}



var StopDFS = gerror.New("STOP")



// 这个dfsTreeSort遍历时有个隐含条件，由于我们知道被拖曳的节点只有一个，所以我们找到这个节点后，马上就可以终止遍历

func (s *sMenu) dfsTreeSort(ctx context.Context, platformId int, node *model.MenuTree, parentTreeId int) error {

	if node == nil {

		return nil

	}



	childsMenus := make([]*model.MenuTree, 0)

	for i := 0; i < len(node.Children); i++ {

		n := node.Children[i]



		mt, err := dao.MenuTree.GetMenuTreeByMenuId(ctx, platformId, n.MenuId, dao.MenuTree.Columns().ParentTreeId)

		if err != nil {

			return err

		}



		if int(mt.PlatformId) != parentTreeId {

			// 发现被移动节点

			err = s.swapTreeNode(ctx, platformId, n, parentTreeId, i)

			if err != nil {

                            return err

			}

			return StopDFS // 终止遍历

		}

                // 收集子菜单

		childsMenus = append(childsMenus, n)



		err = s.dfsTreeSort(ctx, platformId, n, n.MenuId)

		if err != nil {

			return err

		}

	}



        // 判断子节点列表的顺序

	if node.MenuId != 0 && len(childsMenus) > 0 {

		oldChilds, err := dao.MenuTree.GetMenuTreeChild(ctx, platformId, node.MenuId)

		if err != nil {

			return err

		}



		if len(childsMenus) < len(oldChilds) {

			// 这个情况不处理

			return nil

		}



		for i := 0; i < len(childsMenus); i++ {

			if i < len(oldChilds) && childsMenus[i].MenuId != int(oldChilds[i].MenuId) {

				// 发现被移动节点

				err = s.swapTreeNode(ctx, platformId, childsMenus[i], parentTreeId, i)

				if err != nil {

					return err

				}

				return StopDFS

			}

		}

                // 前面顺序如果都一样，那必然是最后一个节点新增的

                if len(childsMenus) > len(oldChilds){

                    L := len(childsMenus) - 1



                    err = s.swapTreeNode(ctx, platformId, childsMenus[L], parentTreeId, L)

                    if err != nil {

			return err 

                    }

                    return StopDFS

                }

	}

	return nil

}



func (s *sMenu) swapTreeNode(ctx context.Context, platformId int, node *model.MenuTree, newParentMenuId int, index int) error {

	tx, err := g.DB().Begin(ctx)

	if err != nil {

		return gerror.Wrap(err, "")

	}

	ctx = context.WithValue(ctx, "tx", tx)



	childs, err := dao.MenuTree.GetMenuTreeChild(ctx, platformId, newParentMenuId)

	if err != nil {

		return err

	}



	var newIndex int64 = 1

	if len(childs) == 0 {

		// 原先没有子节点

		newIndex = 1

	}

	if len(childs) != 0 && index > len(childs)-1 {

		// 在末尾

		newIndex = childs[len(childs)-1].Index + 1

	}



	if len(childs) != 0 {

		// 在中间 或者在开头

		for i := index; i < len(childs); i++ {

			newIndex = childs[i].Index



			for j, e := range childs[i:] {

				fileds := make([]interface{}, 0)

				fileds = append(fileds, dao.MenuTree.Columns().Index)

                                if int(e.MenuId) == node.MenuId{

                                    // 不遍历到自己

                                    continue

                                }



				err = dao.MenuTree.EditMenuTree(ctx, &entity.MenuTree{

					Id:    e.Id,

					Index: newIndex + int64(j) + 1,

				}, fileds...)

				if err != nil {

					tx.Rollback()

					return err

				}

			}

		}

	}



	fileds := make([]interface{}, 0)

	fileds = append(fileds, dao.MenuTree.Columns().ParentTreeId)

	fileds = append(fileds, dao.MenuTree.Columns().Index)



	err = dao.MenuTree.EditMenuTreeByMenuId(ctx, &entity.MenuTree{

		MenuId:       int64(node.MenuId),

		PlatformId:   int64(platformId),

		ParentTreeId: int64(newParentMenuId),

		Index:        newIndex,

	}, fileds...)

	if err != nil {

		tx.Rollback()

		return err

	}

	tx.Commit()

	return nil

}

在菜单排序操作时，最好也加上分布式锁，菜单排序时禁止添加菜单、导入菜单等操作。

六、菜单导入、导出

菜单导入、导出在实践中也是非常有用的，常用的场景是：测试环境添加、更新、删除菜单后，想同步到正式环境，难道要再操作一遍吗？简单的办法就是导出测试环境的菜单，再导入到正式环境即可。

1. 菜单导出

既然已经获取到了菜单列表，那么把它导出成json文件也不是什么难事，这里的矛盾是，菜单列表里返回的菜单树信息是不全的，我们需要补充信息，导出一颗完整的菜单树：

   type MenuExportTree struct {

      MenuInfo



      Children []*MenuExportTree `json:"children"` // 子菜单

   }



   type MenuTree struct {

      MenuId       int    `json:"id"`        // 菜单ID

      ParentMenuId int    `json:"parent_id"` // 父菜单ID

      Name         string `json:"name"`      // 菜单名

      Type         int64  `json:"type"`      // 菜单类型 1菜单2子菜单3按钮4页签5数据标签



      Children []*MenuTree `json:"lists"` // 子菜单

   }

菜单列表返回的字段是不全的，我们需要拿到 menu_info 表的所有字段，这里有两种思路，一种是仿照菜单列表的写法再写一遍，但是这次建立树节点时要获取下 menu_info 表的信息；另一种做法则是调用菜单列表获取到菜单树，然后做一个树克隆的算法，在克隆的过程中，把 menu_info 的信息写进去。

这里介绍第二种做法，原树的节点(MenuTree)克隆一个新树（MenuExportTree），这里我们为了炫技复习基础，换用BFS来遍历树和克隆树。

// BFS 树克隆，原树 node ，新树 newNode

// BFS 遍历原树，在遍历过程中，建立新树节点

func (s *sMenu) bfsTreeCopy(node *model.MenuTree, newNode *model.MenuExportTree) {

   p := node

   if p == nil {

      return

   }

   q := newNode

   

   // isVisit是防止树中有回环指向，在菜单树中其实不存在回环，其实可以不要。

   isVisit := make(map[*model.MenuTree]int)

   queueP := list.New() // P 原树队列

   queueQ := list.New() // Q 新树队列

   queueP.PushBack(p)

   queueQ.PushBack(q)



   for queueP.Len() != 0 {

      size := queueP.Len()

      for i := 0; i < size; i++ {

         e := queueP.Front()

         eq := queueQ.Front()

         p = e.Value.(*model.MenuTree)

         q = eq.Value.(*model.MenuExportTree)



         if _, ok := isVisit[p]; !ok {

            q.MenuId = p.MenuId

            q.Children = make([]*model.MenuExportTree, 0)

            if q.MenuId != 0 {

               // 获取 menu_info 表数据

               menuInfo, _ := dao.MenuInfo.GetMenuInfo(

                  context.Background(),

                  q.MenuId,

                  dao.MenuInfo.Columns().Status,

                  dao.MenuInfo.Columns().Icon,

                  dao.MenuInfo.Columns().CreateTime,

               )

               q.MenuInfo = menuInfo

            }

            isVisit[p] = 1

         }



         for _, child := range p.Children {

            queueP.PushBack(child)

            t := &model.MenuExportTree{}

            q.Children = append(q.Children, t) 

            queueQ.PushBack(t) // 推一个空的新节点到queueQ，下次循环会为其赋值



         }

         queueP.Remove(e)

         queueQ.Remove(eq)

      }

   }

}

BFS 比较擅长处理需要针对每层节点进行操作的情况， DFS则可以在遍历时方便的获取到父节点的id，大部分时候我们选择一种遍历算法使用即可。

2. 菜单导入

导入则比较简单了，这里的导入是指我们用导入数据覆盖原数据，比较简单。如果要支持导入部分树节点，则可能比较麻烦，不能用 menu_id 数据库主键作为菜单唯一标识了，因为不同环境的主键不同。需要为菜单生成唯一标识，比如 menu_key 之类的字段，然后用它作为导入时定位菜单的依据。

所以不如简单点，导入就是用导入的数据覆盖原来数据，步骤就是，删除原来的菜单树，然后建立一颗新的菜单树。

// 根据 MenuExportTree 建立一个新的菜单树写入数据库中

func (s *sMenu) dfsTreeImport(ctx context.Context, tx *gdb.TX, root *model.MenuExportTree, parentMenuId int, index int) error {

   if root == nil {

      return nil

   }

   menuId := 0



   // 前序遍历，写入 menu_info 表

   if len(root.Name) != 0 {

      menuInfo := &entity.MenuInfo{

         PlatformId: int64(root.PlatformId),

         Name:       root.Name,

         Type:       root.Type,

         Icon:       root.Icon,

         IsOutlink:  root.IsOutLink,

         RouteUrl:   root.RouteData,

         Status:     root.Status,

         ShowTime:   root.Showtime,

         BackendApi: root.BackendApi,

         DataLabels: gjson.New(root.DataLabels.Data),

      }



      err := dao.MenuInfo.AddMenuInfoReturnId(ctx, menuInfo)

      if err != nil {

         _ = tx.Rollback()

         return gerror.Wrap(err, "")

      }

      menuId = int(menuInfo.Id)

   }



   for i := 0; i < len(root.Children); i++ {

      n := root.Children[i]



      err := s.dfsTreeImport(ctx, tx, n, menuId, i+1)

      if err != nil {

         _ = tx.Rollback()

         return err

      }

   }



   // 当遍历完这个节点的子节点后，把这个节点写入 menu_tree

   if len(root.Name) != 0 {

      tree := &entity.MenuTree{

         PlatformId:   int64(root.PlatformId),

         ParentTreeId: int64(parentMenuId),

         MenuId:       int64(menuId),

         Index:        int64(index),

      }

      err := dao.MenuTree.AddMenuTree(ctx, tree)

      if err != nil {

         _ = tx.Rollback()

         return err

      }

   }

   return nil

}

七、参考文献

1. LeetCode
2. gitee.com/fe.zookeepe… （图源）
3. 代码风格（GoFrameV2）

概述

Lint 是 Android studio 提供的一款静态代码检查工具，它可以帮助我们检查 Android 项目源文件是否有潜在的 bug，以及在正确性、安全性、性能、易用性、无障碍性和国际化方面是否需要优化改进。Lint 的好处不言而喻，它能够在编码阶段就帮我们提前发现代码中的“坏味道”，显著降低线上问题出现的概率；同时也能有效促进团队的开发规范的统一。

关于执行 lint 检查的几种方式不多做赘述，接下来着重来看下如何实现自定义 Lint 规则并应用到实际项目中。

自定义 Lint 接入方案

自定义 Lint 规则最终都会打成 JAR 包，只需将该输出 JAR 提供给其他组件使用即可。目前有两种方式可供选择：

全局方案

把此 jar 拷贝到 ~/.android/lint/ 目录中即可。缺点显而易见：针对所有工程生效，会影响同一台机器其他工程的 Lint 检查。即便触发工程时拷贝过去，执行完删除，但其他进程或线程使用 ./gradlew lint 仍可能会受到影响。

AAR 壳方案

另一种实现方式是将 jar 置于一个 aar 中，如果某个工程想要接入执行自定义的 lint 规则，只需依赖这个发布后的 aar 即可，如此一来，新增的 lint 规则就可将影响范围控制在单个项目内了。另外，该方案也是 Google 目前推荐的方式，aar 内容也支持 lint.jar 条目：

AAR 文件的文件扩展名为 .aar，Maven 工件类型应该也是 aar。此文件本身是一个 zip 文件。唯一的必需条目是 /AndroidManifest.xml。AAR 文件可能包含以下一个或多个可选条目：

xx.aar

|-/classes.jar

|-/res/

|-/R.txt

|-/public.txt

|-/assets/

|-/libs/name.jar

|-/jni/abi_name/name.so（其中 abi_name 是 Android 支持的 ABI 之一）

|-/proguard.txt

|-/lint.jar

|-/api.jar

|-/prefab/（用于导出原生库）

具体可参考 Android 官方对于 aar 的介绍：developer.android.com/studio/proj…

编写自定义 Lint 规则

接下来主要从以下几个方面来介绍自定义 Lint 的开发流程。

1. 创建 java-library & 配置 lint 依赖

自定义的 lint 规则最终输出格式为 jar 包，所以我们只需要创建一个 java-library 即可，build.gradle 配置如下：

lint-rules/build.gradle

plugins {

   id 'java-library'

   id 'org.jetbrains.kotlin.jvm'

}



dependencies {

// 官方提供的Lint相关API，并不稳定，每次AGP升级都可能会更改，且并不是向下兼容的

   compileOnly "com.android.tools.lint:lint-api:${rootProject.ext.lintVersion}"

// 目前Android中内置的lint检测规则

   compileOnly "com.android.tools.lint:lint-checks:${rootProject.ext.lintVersion}"

   compileOnly "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlinVersion"



   testImplementation "junit:junit:4.13.2"

   testImplementation "com.android.tools.lint:lint:$lintVersion"

   testImplementation "com.android.tools.lint:lint-tests:$lintVersion"

}



java {

   sourceCompatibility = JavaVersion.VERSION_1_8

   targetCompatibility = JavaVersion.VERSION_1_8

}



jar {

   manifest {

       // Only use the "-v2" key here if your checks have been updated to the

       // new 3.0 APIs (including UAST)

       attributes('Lint-Registry-V2': 'com.dorck.lint.rules.old.MyCustomIssueRegistry')

  }

}



configurations {

   lintJarOutput

}

dependencies {

   lintJarOutput files(jar)

}

defaultTasks 'assemble'

配置期间如果发现如下问题：

 需要将 java 闭包中的 sourceCompatibility 和 targetCompatibility 改为 1.8。

此外，如果你创建 module 时选择的是 kotlin 语言，还可能会遇到以下这个坑：

 只需要将 kotlin 标准库依赖方式改为 compileOnly 即可：

compileOnly "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlinVersion"

2. 编写 lint-rules

平时经常使用 kotlin 开发项目的同学应该都遇到过这种情况：一旦我们希望类 A 实现一个接口 B，那么通过 AS 快捷键 option+ enter 选择 implement members 后就会为我们的类 A 自动实现 B 中接口，并加了一堆 TODO 方法：

目前编码环境并不会提示任何错误，然而，如果我们粗心忘记去掉上面接口实现中的 TODO 方法，一旦我们其他类调用到这个类 SomethingNew，程序就立马抛出一个 NotImplementedError 异常。显然，如果前置静态代码检查阶段没有拦住这个问题进而跑到了线上，那么就只能祈祷别人不会去调用了，否则故障在所难免了。好了，既然需求过来了，我就来尝试通过自定义 Lint 帮助团队其他成员在编码阶段就发现问题并强制处理。

首先，在上一步中，我们在 lint-rules/build.gradle 中指定了自定义的 MyCustomIssueRegistry，现在里面空空如也，我们需要先创建一个 Detector 用于检测 Standard.kt 中的 TODO() 方法：

@Suppress("UnstableApiUsage")

class KotlinTodoDetector : Detector(), Detector.UastScanner {



   override fun getApplicableMethodNames(): List<String> {

       return listOf("TODO")

  }



   override fun visitMethodCall(context: JavaContext, node: UCallExpression, method: PsiMethod) {

       println("KotlinTodoDetector >>> matched TODO in [${method.parent.containingFile.toString()}]")

       if (context.evaluator.isMemberInClass(method, "kotlin.StandardKt__StandardKt")) {

           val deleteFix = fix().name("Delete this TODO method")

              .replace().all().with("").build()

           context.report(

               ISSUE,

               context.getLocation(node),

               "You must fix `TODO()` first.", deleteFix)

      }

  }



   companion object {

       private const val ISSUE_ID = "KotlinTodo"

       val ISSUE = Issue.create(

           ISSUE_ID,

           "Detecting `TODO()` method from kotlin/Standard.kt.",

           """

               You have unimplemented method or undo work marked by `TODO()`,

               please implement it or remove dangerous TODO.

               """,

           category = Category.CORRECTNESS,

           priority = 9,

           severity = Severity.ERROR,

           implementation = Implementation(KotlinTodoDetector::class.java, Scope.JAVA_FILE_SCOPE),

      )

  }

}

此处我们需要检测的对象是 Java 源文件，这里只需要继承自 Detector 并实现 Detector.UastScanner 接口即可。当然，我们也可以选择按组合方式实现更多其他 Scanner，这取决于我们希望扫描的文件范围。目前支持的扫描范围有：

• UastScanner：扫描 Java 或者 kotlin 源文件
• ClassScanner：扫描字节码或编译的类文件
• BinaryResourceScanner：扫描二进制资源文件（res/raw/bitmap等）
• ResourceFolderScanner：扫描资源文件夹
• XmlScanner：扫描 xml 格式文件
• GradleScanner：扫描 Gradle 格式文件
• OtherFileScanner：其他类型文件

检测 Java 源文件，可以通过 getApplicableMethodNames 指定扫描的方法名，其他还有类名、文件名、属性名等等，并通过 visitMethodCall 接受检测到的方法。这里我们只需要检测 Kotlin 标准库中的 Standard.kt 中的 TODO 方法，匹配到后通过 context.report 来报告具体问题，这里需要指定一个 Issue 对象来描述问题具体信息，相关字段如下：

• id : 唯一值，应该能简短描述当前问题。利用 Java 注解或者 XML 属性进行屏蔽时，使用的就是这个 id。
• summary : 简短的总结，通常5-6个字符，描述问题而不是修复措施。
• explanation : 完整的问题解释和修复建议。
• category : 问题类别。常见的有：CORRECTNESS、SECURITY、COMPLIANCE、USABILITY、LINT等等。
• priority : 优先级。1-10 的数字，10 为最重要/最严重。
• severity : 严重级别：Fatal, Error, Warning, Informational, Ignore。
• Implementation : 为 Issue 和 Detector 提供映射关系，Detector 就是当前 Detector。声明扫描检测的范围Scope，Scope 用来描述 Detector 需要分析时需要考虑的文件集，包括：Resource文件或目录、Java文件、Class文件等。

此外，我们还可以设置出现该 issue 上报时的默认解决方案 fix，这里我们创建了一个 deleteFix 实现开发者快速移除报错位置的 TODO 代码。

最后，只需要自定义一个 Registry 声明自己需要检测的 Issues 即可：

@Suppress("UnstableApiUsage")

class MyCustomIssueRegistry : IssueRegistry() {

   init {

       println("MyCustomIssueRegistry, run...")

  }



   override val issues: List<Issue>

       get() = listOf(

           JcenterDetector.ISSUE,

           KotlinTodoDetector.ISSUE,

      )



   override val minApi: Int

       get() = 8 // works with Studio 4.1 or later; see com.android.tools.lint.detector.api.Api / ApiKt



   override val api: Int

       get() = CURRENT_API



   override val vendor: Vendor

       get() = Vendor(

           vendorName = "Dorck",

           contact = "xxx@gmail.com"

      )



}

更多关于 AST 相关类及语法介绍可参考官方指导文档或者 Lint 源码，此处不多做介绍，这里很难一言以蔽之。

3. Lint 发布&接入

文章开头部分已经介绍了 Lint 的相关接入方案，出于灵活性和可用性角度考虑自然选择 aar 壳的方式。经过这几年 lint 的发展，实现起来也很简单：只需要创建一个 Android-Library module，然后稍微配置下 gradle 即可：

lint-aar:

plugins {

   id 'com.android.library'

   id 'org.jetbrains.kotlin.android'

}

dependencies {

   lintPublish project(':checks')

   // other dependencies

}

就是这么简单，此处的 lintPublish 配置允许我们引用另一个 module，它会获取该组件输出的 jar 并将其打包为 lint.jar 然后放到自身的 AAR 中。

最后，我们在 app 模块中依赖一下 lint-aar 这个组件，并编写以下测试代码：

interface SimpleInterface {

   fun initialize()

   fun doSomething()

}



class SomethingNew : SimpleInterface {

       override fun initialize() {

           TODO("Not yet implemented")

      }



       override fun doSomething() {

           TODO("Not yet implemented")

      }



  }

接下来执行一下 ./gradlew :app:lint 即可看到控制台输出以下内容：

我们也可以点击 Lint 输出的测试报告链接去查看详细信息：

Note：AGP 7.0 开始，执行 ./gradlew :app:lint 只会作用于默认变体 lint 任务上，而不是诸如此前的执行所有变体 lint 任务。

例如：我们此前执行 ./gradlew :app:lint 可能会导致 debugLint、releaseLint、releaseChinaLint 等诸多变体 lint 任务的执行，严重拖慢了编译速度，所以一般要指定特定变体的 lint 任务来执行：./gradlew :app:lintDebug。而7.0开始将无需如此麻烦，尽管放心使用 ./gradlew :app:lint 即可。

最后，在 Android studio 中我们也可以看到编译器给我们的代码警告了：

并且我们上面设置的 deleteFix 也生效了，即点击 Delete this TODO method 就可以轻松移除 TODO() 方法，快速解决问题。

4. 编写测试代码

TTD（Test-Driven Development）是一个不错的习惯，很多时候作为开发人员大多时候无需关心最新编写的 lint 组件发布状态，因为不断发布和集成到示例代码中测试是一个比较糟糕的体验，严重消耗我们的精力。如此一来，我们就不得不了解下 lint 规则编码时的单测流程了，我相信能够显著提升你的开发效率。

首先，我们需要依赖 Lint 的单测组件：

testImplementation "com.android.tools.lint:lint-tests:$lintVersion"

接着，在 lint-rules 模块中创建单测文件用于验证我们之前的 KotlinTodo 规则：

最后来看下 KotlinTodoDetectorTest 如何实现的：

package com.dorck.lint.examples



import com.android.tools.lint.checks.infrastructure.TestFiles.kotlin

import com.android.tools.lint.checks.infrastructure.TestLintTask.lint

import com.dorck.lint.rules.old.issues.KotlinTodoDetector

import org.junit.Test



@Suppress("UnstableApiUsage")

class KotlinTodoDetectorTest {



   @Test

   fun sampleTest() {

       lint().files(

           kotlin(

               """

                   package test.pkg

                   class SimpleInterfaceImpl : SimpleInterface {

                   

                       override fun doSomething(){

                           TODO("Not yet implemented")

                       }

                   }

                   interface SimpleInterface {

                       fun doSomething()

                   }

               """.trimIndent()

          ))

          .issues(KotlinTodoDetector.ISSUE)

          .run()

          .expect(

               """

                   src/test/pkg/SimpleInterfaceImpl.kt:5: Error: You must fix TODO() first. [KotlinTodo]

                           TODO("Not yet implemented")

                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~

                   1 errors, 0 warnings

               """.trimIndent()

          )

     .expectFixDiffs(

               """

                   Fix for src/test/pkg/SimpleInterfaceImpl.kt line 5: Delete this TODO method:

                   @@ -5 +5

                   -         TODO("Not yet implemented")

               """.trimIndent()

          )

  }

}

其实也很简单，只需要模拟创建一个 Java/kotlin/Gradle/xml 等格式的源文件，然后在 java() 或 koltin() 方法参数里面写上测试代码，并指定要验证的 Issue 以及期待的反馈内容。当然，expect() 中期待的输出检查结果我们是无法知晓的，我们只需要先设置为空字符串，然后先跑一下测试用例，预期肯定会失败，如此，我们只需要将终端输出的实际错误信息 copy 到 expect() 中即可：

最后，重新 run 一下单测，就会发现能够正常通过测试了。更多关于 Lint 单元测试的用法可以参考：Lint unit testing

5. 忽略某些规则检查

某些情况下，我们希望忽略某些 Lint 规则的检查或者更改 Lint 规则的严重级别，那么，我们可以选择增加一个 Lint 配置文件，用于解决上述问题。我们可以手动在项目 app/根目录下创建一个名为 lint.xml 的文件：

<?xml version="1.0" encoding="UTF-8"?>

<lint>

   <!-- list of issues to configure -->

   <issue id="DefaultLocale" severity="ignore"/>

   <issue id="DeprecatedProvider" severity="ignore"/>

   <issue id="ObsoleteLayoutParam">

       <!-- The <ignore> tag has two possible attributes: path and regexp (see below) -->

       <ignore path="res/layout-xlarge/activation.xml" />

       <!-- You can use globbing patterns in the path strings -->

       <ignore path="**/layout-x*/onclick.xml" />

       <ignore path="res/**/activation.xml" />

   </issue>



<issue id="MissingTranslation" severity="ignore"/>

<issue id="KotlinTodo" severity="ignore"/>

</lint>

在 lint.xml 中我们可以选择更改某条规则的严重级别，使原本不受重视的规则更加引人注意或者放宽其他规则的级别。当然，我们也可以指定某条规则在特定匹配路径下被忽略，这将取决于我们自己设定的 regex 匹配规则。

Note：如果我们创建了 lint.xml (文件名强约定)，并且 build.gradle 的 lintOptions 中没有自定义设定 lint 配置文件的名称和路径，则 AGP自动在临近目录中寻找名为 lint.xml 的配置文件。

详细参考：Configure by lint xml

此外，我们也可以通过在 build.gradle >> lintOptions DSL 中设置开启或者关闭某些特定规则，当然也可以配置报告的输出格式以及路径：

lintOptions {

   textReport false

   lintConfig file('default-lint.xml') // At `app/default-lint.xml`

   disable 'KotlinTodo', 'MissingTranslation'

   xmlOutput file("lint-report.xml")

}

更多关于 LintOptions DSl 的配置可查看官方文档：LintOptions-dsl

Note：如果你项目中使用了 lint plugin，那么可以参考 lint DSL的相关释义：AGP-lint-dsl

其他的设置 lint 配置的方式还有手动在 Android studio 的工具栏 Analyze > Inspect Code > Specify Inspection Scope 中或者通过 Lint 命令行工具来配置，这两种方式就不具体介绍了，感兴趣的朋友可以去看下官方文档的介绍。

版本迭代过程

AGP 4.0开始，Android studio 支持了独立的 com.android.lint 插件，进一步降低了自定义 lint 的成本。借助此插件，在上述 lint-rules/build.gradle 中通过在 manifest 中注册自定义 Registry 改为通过服务表单注册（当然，以前的方式目前还是可以用的）。以下是基于官方最新推荐的方式来配置和注册自定义规则的：

plugins {

   id 'java-library'

   id 'org.jetbrains.kotlin.jvm'

   id 'com.android.lint'

}



dependencies {

   // 官方提供的Lint相关API，并不稳定，每次AGP升级都可能会更改，且并不是向下兼容的

   compileOnly "com.android.tools.lint:lint-api:${rootProject.ext.lintVersion}"

   // 目前Android中内置的lint检测规则

   compileOnly "com.android.tools.lint:lint-checks:${rootProject.ext.lintVersion}"

   compileOnly "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlinVersion"



   testImplementation "junit:junit:4.13.2"

   testImplementation "com.android.tools.lint:lint:$lintVersion"

   testImplementation "com.android.tools.lint:lint-tests:$lintVersion"

}



java {

   sourceCompatibility = JavaVersion.VERSION_1_8

   targetCompatibility = JavaVersion.VERSION_1_8

}

可以看到，以此插件方式，我们需要关注的额外配置更少了，很大程度上降低了接入成本。

下面再来谈谈 AGP-7.0 开始的改动。其一变动是上面谈及过的执行 ./gradlew lint 只会作用于默认变体的 Lint 任务上，而不是以前的所有变体任务。

另外一项是在 7.0 中，lint 最终将能够跨模块增量运行，这意味着如果我们只更改一个模块中的代码，lint 只需在该模块下游的模块上重新运行分析检测。对于具有许多模块的大型项目，这应该是一项重大的改进。

开发技巧

1. 借助 Psi 工具查看 AST 语法树

Lint 检查的实质是对代码的 AST（Abstract Syntax Tree，即抽象语法树）数据进行检查分析，故而会用到大量 AST 与 lombok.ast 开源库相关知识。阅读源码是一种不错的分析语法树方式，不过我们可以借助 AS 的一些插件帮我们快速便捷解析类的节点树并加以解读。

利用 PsiViewer 就可以查看类的 AST 构造，如此一来我就可以另辟蹊径找到特定的属性来匹配特定代码了。值得注意的是，上面的 AST viewer 插件对 kotlin 代码支持不是很好，如果有需要，建议先将 kotlin 反编译为 java 再分析。

2. 参考 Android 内置 Lint 规则

我发现官方近期对于 Lint 的技术推进很上心，各路文档和 FAQ 陆续补齐了。关于内置规则，Android官方团队也对每条做了详细说明和用法指导，详细参考：googlesamples.github.io/android-cus…

线程封闭

线程封闭一般通过以下三个方法：

1. Ad-hoc线程封闭：程序控制实现，最糟糕，忽略


2. 堆栈封闭：局部变量，无并发问题


3. ThreadLocal线程封闭：特别好的封闭方法

方法2是最常用的，变量定义在接口内，本文主要讲解方法三，SpringBoot项目通过自定义过滤器和拦截器实现ThreadLocal线程封闭。实现Filter接口自定义过滤器和继承HandlerInterceptorAdapter自定义拦截器。

ThreadLocal线程封闭实现步骤

封装ThredLocal的方法

/**

 * <p>自定义RequestHolder</p></p>

 *

 * @Author zjq

 * @Date 2021/12

 */

public class RequestHolder {



    private final static ThreadLocal<Long> requestHolder = new ThreadLocal<>();



    public static void set(Long id) {

        requestHolder.set(id);

    }



    public static Long get() {

        return requestHolder.get();

    }



    public static void remove() {

        requestHolder.remove();

    }



}

自定义过滤器

自定义定义拦截器继承Filter接口，实现ThredLocal.add()方法

/**

 * <p>自定义过滤器</p>

 *

 * @Author zjq

 * @Date 2021/12/7

 */

@Slf4j

public class HttpFilter implements Filter {



    /**

     * 为Filter初始化 提供支持

     *

     * @param filterConfig

     * @throws ServletException

     */

    @Override

    public void init(FilterConfig filterConfig) throws ServletException {



    }



    /**

     * 拦截到要执行的请求时，doFilter就会执行。这里我们可以写对请求和响应的预处理。

     * FilterChain把请求和响应传递给下一个 Filter处理

     *

     * @param servletRequest

     * @param servletResponse

     * @param filterChain

     * @throws IOException

     * @throws ServletException

     */

    @Override

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

        //把普通servlet强转成httpServlet

        HttpServletRequest httpServletRequest = (HttpServletRequest) servletRequest;

        Long threadId = Thread.currentThread().getId();

        log.info("do filter,threadId:{} servletPath:{}", threadId, httpServletRequest.getServletPath());

        //把当前线程id放入requestHolder

        RequestHolder.set(threadId);

        //放行

        filterChain.doFilter(httpServletRequest, servletResponse);

    }



    /**

     * Filter 实例销毁前的准备工作

     */

    @Override

    public void destroy() {



    }

}

自定义拦截器

自定义拦截器在线程使用完毕后移除ThredLocal中内容，避免内存溢出

/**

 * <p>自定义拦截器</p>

 *

 * @Author zjq

 * @Date 2021/12/7

 */

@Slf4j

public class HttpInterceptor extends HandlerInterceptorAdapter {



    /**

     * 拦截处理程序的执行。在 HandlerMapping 确定合适的处理程序对象之后，在 HandlerAdapter 调用处理程序之前调用。

     * @param request

     * @param response

     * @param handler

     * @return

     * @throws Exception

     */

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        log.info("preHandle执行。。。");

        return true;

    }



    /**

     * 请求处理完成后（渲染视图后）的回调。将在处理程序执行的任何结果上调用，从而允许进行适当的资源清理。

     * @param request

     * @param response

     * @param handler

     * @param ex

     * @throws Exception

     */

    @Override

    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

        RequestHolder.remove();

        log.info("afterCompletion执行。。。");

        return;

    }

}

Application类启动类中配置自定义过滤器和拦截器

/**

 * 

 * @author zjq

 */

@SpringBootApplication

public class Application extends WebMvcConfigurationSupport {



    public static void main(String[] args) {

        SpringApplication.run(ConcurrencyApplication.class, args);

    }



    /**

     * 自定义过滤器

     * @return

     */

    @Bean

    public FilterRegistrationBean filterRegistrationBean(){

        FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean();

        filterRegistrationBean.setFilter(new HttpFilter());

        //设置自定义过滤器拦截的url

        filterRegistrationBean.addUrlPatterns("/threadLocal/*");

        return filterRegistrationBean;

    }



    /**

     * 定义自定义拦截器原先需要继承WebMvcConfigurerAdapter

     * SpringBoot2.0后WebMvcConfigurerAdapter被定义成过时了，推荐使用继承WebMvcConfigurationSupport

     * @param registry

     */

    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        registry.addInterceptor(new HttpInterceptor()).addPathPatterns("/**");

    }

}

定义调用接口

/**

 * ThreadLocal测试controller

 * @author zjq

 */

@Controller

@RequestMapping("/threadLocal")

public class ThreadLocalController {



    @RequestMapping("/test")

    @ResponseBody

    public Long test() {

        return RequestHolder.get();

    }

}

请求访问验证

访问调用接口，控制台输出如下：

看到结局的问题：如何区分StatelessWidget 和 StatefulWidget 的使用场景，不禁开始自问，对于StatefulWidget ，StatelessWidget，以及flutter中Widget的众多子类我真的足够了解吗？

对于自己经常要打交道的东西，如果只是一知半解则不利于进步。

下面就从源码的角度来学习下flutter基础的几个Widget 都起到了什么作用。

先给个简单总结：

• 其中StatelessWidget 和 StatefulWidget 起到了组织组合子组件的作用。


• RenderObjectWidget 起到渲染作用。包含绘制偏移和测量信息。


• ProxyWidget 可以携带信息，以供其他组件使用。

一、探索StatelessWidget的组件构建

在使用StatelessWidget的时候，通常只需要实现一个build方法。就拿我们常用的Container组件举例，他就是StatelessWidget 的子类。他的build方法返回的就是各种组件的组合嵌套。

他的各种成员属性也只是用来配置子组件的组合方式而已。

1. StatelessWidget 的build调用时机，以及widget树遍历流程

Container组件是StatelessWidget的经典子类。

我们通过断点调试看看Container 组件build方法的调用堆栈

在ComponentElement 的performRebuild 方法调用的时候，触发了build方法，从stateless中获取了build返回的Widget，而又在performRebuild 调用了updateChild方法，对所有的子孙Element进行build遍历。

ComponentElement是Widget对应元素StatelessElement和StatefulElement的父类。

我们拉到最初的调用栈。Element栈调用的起点在于attachRootWidget方法。

还记得我们flutter app开发的起点吗？就是runApp(App())方法，开启了整个flutter app。
attachRootWidget方法正是我们在调用runApp的时候执行的。

在其中，执行了RenderObjectToWidgetAdapter组件的初始化，将renderView 和 rootWidget作为入参。并且调用attachToRenderTree返回元素树顶点的Element。

三颗树的顶点

其中renderView是RenderObject树的顶点，_renderViewElement是Element树的顶点。匿名的RenderObjectToWidgetAdapter则是Widget树的顶点，但是他没有被引用。Widget树的维护依赖于Element树，rootWidget就是我们的runApp组件节点，被作为参数挂载到RenderObjectToWidgetAdapter根组件中，被后续的Element挂载循环使用。

Element中也存放了_parent变量，所以我们通过Element对象可以轻松的追溯到祖先节点。

我们从上面的分析可以得出ComponentElement 的 performRebuild方法是element.build传承关键方法 ，mount方法也能由此挂载出所有子树（其他类型的Element实现方案略有不同）

在ComponentElement中。也由performRebuild构建出一层层的子孙节点。代码如下，注意红色方框的代码。

第一个红框中是build()方法的执行。意味着每次performRebuild被调用的时候，子组件都会被build出来，由此可知widget是唯一的，每次更新都会有新的Widget生成。

在updateChild的过程中，如果子element还未生成，就会调用widget.createElement()方法获得element 。

我们再看StatelessWidget 的源码，实现了createElement方法返回了自定义的StatelessElement。

生成的子Element 都会在ComponentElement中被持有，以便后续更新

由此可知，ComponentElement维系了祖孙关系，其子类Element对应的 StatelessWidget，StatefulWidget，ParentDataWidget 和 InheritedWidget都天然拥有子孙关系能力。

如下所示，StatefulElement 是 ComponentElement 的子类。

2. StatelessWidget 和Element在渲染中的更新

widget的创建都是在element树遍历的过程中执行的。
widget树依赖于element树，在Element创建的时候widget实例将会被持有。
StatelessWidget在布局和渲染流程中依赖Element维系，树关系被Element挖掘。

在Element performeRebuild重新构建的时候，有一个是否更新Element的判定机制，以优化性能。
不管是更新update还是挂载mount，每次子widget都会先build()出来。再进行新旧比较。Widget都是一次性的，如果有状态需要保存是由其他方式实现的。
我们再看updateChild方法。上面一小节提到在子element为空的时候，会在其中createElement。而在子Element不为空的时候，会根据新旧Widget 的不同，进行不同的操作。

其中通过新旧widget的equals判定。决定是否复用之前的element。如果复用了element，根据canUpdate方法的返回值，来执行child.update方法。所以我们可以得出这样一个结论。

widget 的 canUpdate 实现，将很大程度上决定 Element 的复用。减少重新绘制，对State重新赋值，甚至状态丢失的资源浪费。

3. 探索key的作用

canUpdate的默认实现中以Widget的类型和key作为关键字进行判断。如果有对key定义，那么Key的一致性就会对widget的更新显得尤为关键。

这也是我们在做性能优化的时候需要注意的。可以利用Key的配置，来控制组件是否需要更新。

static bool canUpdate(Widget oldWidget, Widget newWidget) {

  return oldWidget.runtimeType == newWidget.runtimeType

      && oldWidget.key == newWidget.key;

}

复制代码

Key的几种子类基本上都是根据需求，对== 操作符做不同的实现。以更好的自定义 canUpdate 的结果。

其中GlobalKey比较特殊。作为全局的唯一秘钥。提供了对应 widget 的 BuildContext 和 widget 的访问方式。并针对 StatefulWidget。还提供了 State 的访问。

以便用户对状态进行全局的更新。比如我们需要在外部使用 BuildContext 进行初始化的时候，可以进行这样调用

4. 小结

通过以上对StatelessWidget和ComponentElement 的分析，可以得出以下的判断。
StatelessWidget 基于 ComponentElement。主要功能就是提供了组合各种widget的能力，并维持了祖孙的build传承。

当然在探索当中也发现了一些技术债务，由于我们已经知道了statelesswidget的使用场景，对于具体的源码细节先按下不表，在此只记录

• 生命周期_lifecycleState 起到什么作用


• _dirty 标记和 markNeedsBuild 的用法和原理是什么


• BuildOwner 的作用是什么

二、探索StatefulWidget的动态刷新机制

StatefulWidget 和 StateflessWidget 有很多共同之处。最主要的原因就是他们创建的元素都是ComponentElement的子类，其提供了widget子孙build传承的能力。

可知StatefulWidget和StateflessWidget一样，也是一个有能力组合各种widget的组件。

1. State生命周期分析

StatefulWidget 定义了createState方法。提供了状态刷新能力。

再次从StatefullElement的build方法入手。直接调用了state.build(this)。代理了state的构建行为。

在performRebuild方法中也进行了state.didChangeDependencies生命周期回调。

在State中，除了生命周期方法外， 最重要的就是build方法了。作用和StatelessWidget的build方法一致。都是提供了组合widget的能力。
initState则给用户提供了初始化state状态的机会。断点调试看看调用栈如何。

调试中直观看到，在firstBuld的时候，state的initState被调用。并在之后调用了didChangeDependencies生命周期方法，和build方法。

代码中也对方法做了限制，不可以返回Future类型。
所以我们可以在initState中放心做一些初始化工作，没有异步参与，工作将会在build之前完成。

2. setState方法刷新页面方式分析

对于setState方法。除开生命周期的判断之外，关键代码只有一句，就是调用了element 的markNeedsBuild()

该方法将对应的element标记为dirty。并且调用owner``!.scheduleBuildFor(``this``);将其加入到 BuildOwner的脏列表(_dirtyElements)中。
将会在下次帧刷新的时候调用BuildOwner.owner.buildScope 重新构建该列表中的元素。

3. 小结

StatelessWidget给使用者提供了一个便捷的布局刷新入口，我们可以利用setState刷新布局。该方法会将对应Element标记为待刷新元素，在下次帧刷新的时候重建布局。状态的改动将会被重建的布局重新获取。

三、探索SingleChildRenderObjectWidget

SingleChildRenderObjectWidget对应的元素类是SingleChildRenderObjectElement。
我们作为开发者，布局过程中SingleChildRenderObjectWidget 的子类使用频率非常频繁，布局的约束，偏移和渲染都是由RenderObjectWidget 实现的，SingleChildRenderObjectWidget继承了RenderObjectWidget的渲染能力，并提供了单子传承的能力。布局的过程中该对象的子类不可或缺，flutter框架中也有不少对应的实现类。

Flutter 框架中实现的SingleChildRenderObjectWidget有以下几种。

1. SizedBox


2. LimitedBox


3. ShaderMask


4. RotatedBox


5. SizedOverflowBox


6. Padding


7. ...

1. 探索SingleChildRenderObjectElement中对于子widget的挂载和更新

SingleChildRenderObjectElement`的`mount` 和 `update`方法都很简单，都是直接调用了`updateChild`方法，传进去的子widget直接是`widget.child

这个方法和ComponentElement基本上一样，都是利用canUpdate的结果进行更新或者是创建子Element。

1. 以Padding为例了解RenderObjectWidget 的布局和绘制实现。

名词解释

RenderObject：渲染对象，flutter对象布局的约束，绘制，位移全是由该对象实现，RenderObject树的祖孙中传递着约束，以做到布局大小的传承影响。

RenderObject的创建

RenderObjectWidget 会在mount挂载的时候，创建RenderObject，直接调用widge.createRenderObject。我们的约束，绘制，位移全是由RenderObject传递和实现的。

RenderPadding的布局实现

以Padding为例。createRenderObject创建了RenderPadding实例，widget的成员原封不动交给了该实例。

约束(BoxConstraint)是Flutter确定布局大小的方案，各种RenderObject对于约束的传递都有自己的实现。

下方是RenderPadding的performLayout代码。红框标记起来的代码中就展示了Padding的约束传承逻辑。
其父布局传给自己约束基础上减去Padding再传递给子RenderObject。

观察performLayout方法可以发现，该方法完成了约束的传递，计算了偏移量Offset，并确定了自己的大小。

确定大小约束之后，就会在paint中绘制自己和子孙。RenderPadding没有自定义绘制，直接使用了父类RenderShiftedBox的实现。RenderShiftedBox 提供了offset偏移。在绘制子renderObject的时候，为其施加绘制偏移量。有些需要计算子布局偏移的widget，如Padding，Align等，都对RenderShiftedBox进行了实现。

可以看到子布局的offset存在他的parentData中。PaddingRender使用的parentData是BoxParentData，内部提供了offset变量以供父布局使用。

/// Parent data used by [RenderBox] and its subclasses.

class BoxParentData extends ParentData {

  /// The offset at which to paint the child in the parent's coordinate system.

  Offset offset = Offset.zero;

  @override

  String toString() => 'offset=$offset';

}

所有的RenderBox都持有BoxParentData对象，用于存储位移信息，在setUpPrentData的时候进行的初始化。红框中的代码展示了这一细节。

到此，就能了解RenderObject是如何被约束BoxConstraint，如何被布局layout，以及如何被绘制paint。

1. RenderObjectElement的传承方式

RenderObjectElement 的父子传承在两个子类中实现，在第1小结中已经提到SingleChildRenderObjectWidget 和ComponentElement十分类似，只是直接把widget.child拿来传承，而不再提供build方法以供子组件组合。

MultiChildRenderObjectElement 也类似，只不过作为多子组件，三棵树分叉的主要因子，维护的是children 列表。

在mount 和 update 的时候，子孙组件会像点了爆竹一样被逐一构建和更新。

1. 小结

每个SingleChildRenderObjectWidget组件都实现了各自的布局和绘制方案，也各自处理了约束并传递下去。

比如ColordBox作为绘制组件，借助了RenderColord，绘制了自身颜色，约束则取得是父约束的最小值。Align作为定位组件，借助了RenderPositionedBox，布局的时候计算了对应的偏移量offset，在绘制子布局的时候使用，约束则在传递的时候转了松约束。

诸如此类，所有组件都利用了对应的RenderObject满足了各自布局和渲染的所有需求。我们自己当然也可以自定义对应的RenderObject实现自己的布局。
MultiChildRenderObjectWidget 和 SingleChildRenderObjectWidget类似，只是维护一个子widget变成了多个子widget。

他的RenderObject基本上都是ContainerRenderObjectMixin和RenderBox的子类，内部维护了头尾两个子节点，并利用存储在parentData中的双相链表维护所有的子RenderObject。

四、谈谈ProxyWidget

最后稍微提一下ProxyWidget。ProxyElement也上ComponentElement的子类。和StatefulWidget 以及StatelessWidget是兄弟关系。也有子孙维系的能力，只不过他的build方法是固定的，返回的就是child。

1. InheritedWidget

我们获取 Theme，MediaQuery数据的时候，都是使用了InheritedWidget

MediaQuery.of(context).size.width;

Theme.of(context).appBarTheme;

通过context 也就是Element实例，获取祖先节点的数据。实现数据共享的效果。
Element中维护了祖先的所有InheritedElement映射，就可以在需要的时候直接通过子孙Element获取。

2. ParentDataWidget

ParentDataWidget提供了子组件向父组件传递渲染信息的能力。
Flexible，Positioned 等组件都是ParentDataWidget 的子类。

需要注意的是：ParentDataWidget只用于渲染信息的传递

在Element.attachRenderObject的时候会调用updateParentData，然后会辗转调用到对应的ParentDataWidget.applyParentData。可以看出只有子组件是RenderObjectWidget子类的时候才会应用对应的ParentDataWidget传递信息。

由此可知，只有在子节点渲染的时候，才会应用RenderObject的数据传递赋值。

子节点的ParentData对象由父布局创建代码如下，创建时机在子节点插入的时候执行。

最后

作为开发者，很多时候完成一个任务只会建立在使用的层面。对于为什么这么使用往往不甚了解。
如果我们能更多的学习他的原理。那么如果在开发中碰到问题，我们能够更加得心应手得去解决。
flutter布局渲染的原理以前总是一层雾蒙在我地眼前。但现在，终于有一片薄雾散去，内部轮廓在我面前变得清晰。
坚持学习，见识真实的世界。

小试

我们最后尝试一下一个简单地布局，分析其三棵树结构。嵌套结构如下。其中builder是StatelessWidget。Column是 MultiChildRenderObjectWidget其他都是SingleChildRenderObjectWidget。

void main() {

  runApp(Builder(builder: (context) {

    return Column(

      mainAxisSize: MainAxisSize.max,

      crossAxisAlignment: CrossAxisAlignment.stretch,

      children: [

        Center(

          child: SizedBox(

            width: 100,

            height: 100,

            child: ColoredBox(color: Colors.blue),

          ),

        ),

        Expanded(

          child: ColoredBox(color: Colors.red),

        ),

      ],

    );

  }));

}

展示出来的样式如下。

分析得出的三棵树如下，源头从RenderView而起，然后构建出RenderObjectToWidgetAdapter，再构建出RootRenderObjectElement。由此从根开始三棵树的循环，直到叶子节点。

RenderObject和Widget并非一一对应，只有RenderObjjectWidget才有，但是RenderObject能自动找出自己的组件RenderObjject 自动插入到其child中，所以也能自动成树。

至此，我们的Widget初步了解完结。

Flutter中如何独立绘制每一个像素点?

前提

前一阵我参照教程：GAMEBOY 仿真器 做了一个game boy模拟器，经过漫长的调试，终于成功的在电脑上运行了起来，但作为一个移动端开发者，我最终还是想要在手机上运行，在经过一番研究后，我卡在了第一个难点：在Flutter中如何单独绘制每一个像素点呢？

Gamyboy的显示器尺寸是160 * 144，素点的格式是RGB，模拟器大概每隔16ms生成一帧画面，当模拟器运行时，我就能源源不断的拿到每一帧的像素数据（这里的像素数据可以看做是一个int32数组，长度为160 * 144），我要做的就是找到一种方法，将每一帧的像素数据绘制到屏幕上。一番搜素后，终于在How do I Render Individual Pixels in Flutter?上找到了答案

绘制像素点

想要直接绘制原始的像素点，需要用到Canvas的一个方法：

/// Draws the given [Image] into the canvas with its top-left corner at the

/// given [Offset]. The image is composited into the canvas using the given [Paint].

void drawImage(Image image, Offset offset, Paint paint)

从方法签名中可以看出，canvas绘制的是一个Image对象，它持有原始的像素数据，所以我们需要先将像素数据转换成Image对象，可以使用decodeImageFromPixels方法

/// Convert an array of pixel values into an [Image] object.

///

/// The `pixels` parameter is the pixel data in the encoding described by

/// `format`.

/// ...

void decodeImageFromPixels(

  Uint8List pixels,

  int width,

  int height,

  PixelFormat format,

  ImageDecoderCallback callback, {

  int? rowBytes,

  int? targetWidth,

  int? targetHeight,

  bool allowUpscaling = true,

})

• pixels是一个一维数组，每一个元素是一个字节


• width和height代表图片的宽和高


• format用来设置像素点的格式，比如：PixelFormat.rgba8888表示一个像素点由四个字节组成，分别表示红，绿，蓝，透明度等信息


• callback为图片解码完成后的回调函数，函数参数为最终生成的Image对象

/// Callback signature for [decodeImageFromList].

typedef ImageDecoderCallback = void Function(Image result);

至此，整个流程已经走通，共分为三步：

1. 生成像素数据


2. 调用decodeImageFromPixels方法将像素数据转换为Image对象


3. 调用Canvas的drawImage方法绘制像素数据

读到这里，有些朋友可能会有疑惑，我从哪里去获取Canvas对象呢? 如何做到实时更新每一帧画面呢？接下来，我将用一个案例将整个流程串起来

演示案例

作为演示，这里用生成的雪花噪点数据来代替模拟器生成的像素数据，完整的案例请看：github.com/hcoderLee/f…

首先我们需要一个不断生成像素数据的类

import 'dart:ui' as ui;



class Emulator {

  /// 每一帧生成的像素所对应的Image对象

  ui.Image? _image;



  ui.Image? get image => _image;



  bool _isRunning = false;

  Timer? _timer;



  /// 用于生成雪花噪点数据

  int xorshift32(int x) {

    x ^= x << 13;

    x ^= x >> 17;

    x ^= x << 5;

    return x;

  }



  int seed = 0xDEADBEEF;

  

  /// 生成原始像素数据，并转换为Image对象

  Future<ui.Image> makeImage() {

    final c = Completer<ui.Image>();

    final pixels = Int32List(lcdWidth * lcdHeight);

    for (int i = 0; i < pixels.length; i++) {

      seed = pixels[i] = xorshift32(seed);

    }

    void decodeCallback(ui.Image image) {

      c.complete(image);

    }



    // 将像素数据转换为Image对象

    ui.decodeImageFromPixels(

      pixels.buffer.asUint8List(),

      lcdWidth,

      lcdHeight,

      ui.PixelFormat.rgba8888,

      decodeCallback,

    );

    return c.future;

  }



  /// 不断的生成每一帧的画面

  void run() {

    if (_isRunning) {

      return;

    }

    _isRunning = true;



    _timer?.cancel();

    /// 每隔16ms（更新一帧的时间）更新一次画面

    _timer = Timer.periodic(const Duration(milliseconds: 16), (timer) async {

      final newImage = await makeImage();

      _image?.dispose();

      _image = newImage;

    });

  }



  void dispose() {

    _timer?.cancel();

    _timer = null;

    _image?.dispose();

  }

}

当有了Image对象后，需要调用Canvas的drawImage方法来绘制，这里使用CustomPaint组件来获取Canvas对象：

CustomPaint(

    painter: _LCD(

      emulator: _emulator,

      timer: _timer,

    ),

);



class _LCD extends CustomPainter {

  final Emulator emulator;



  _LCD({

    required this.emulator,

    required _Timer timer,

  }) : super(repaint: timer);



  @override

  void paint(ui.Canvas canvas, ui.Size size) {

    final image = emulator.image;

    if (image != null) {

      canvas.drawImage(image, Offset.zero, Paint());

    }

  }



  @override

  bool shouldRepaint(covariant CustomPainter oldDelegate) {

    return true;

  }

}

CustomPaint组件有一个重要的参数: painter, 它是一个CustomPainter对象，我们可以自定义一个类去继承CustomPainter, 实现paint方法，获取到Canvas对象，至此，我们可以利用canvas去绘制任何我们想要的东西

这里我们定义了_LCD去继承CustomPainter，它持有Emulator对象，从而获取要绘制的Image对象，这里有两个地方需要重点关注一下：

1. 
   

   shouldRepaint方法表示如果上层组件发生重建，生成了新的CustomPaint对象，是否需要重新调用paint方法绘制内容，因为我的需求是每一帧都要绘制新的画面，所以这里直接返回true（表示需要重新调用paint方法），真实的业务场景需要根据具体情况去判断是否返回true

   
   


2. 
   

   构造函数中有一个_Timer对象，并调用了super(repaint: timer)，那么这个_Timer对象是用来做什么的呢？

   
   

查看CustomPainter的文档，有这么一段说明：

/// The painter will repaint whenever `repaint` notifies its listeners.

repaint会通知CustomPainter去重新绘制画面，我们再查看repaint的类型是Listenable，这里我们自定义一个_Timer类，用来在每一帧更新的时候去通知CustomPainter重绘

class _Timer extends ChangeNotifier {

  final TickerProvider _vsync;

  late final Ticker _ticker;



  _Timer(this._vsync) {

    _ticker = _vsync.createTicker(_onTick);

    _ticker.start();

  }



  void _onTick(Duration elapsed) {

    notifyListeners();

  }



  @override

  void dispose() {

    _ticker.stop();

    _ticker.dispose();

    super.dispose();

  }

}

这里我们继承了ChangeNotifier，因此间接继承了Listenable
在构造函数里创建了一个Ticker对象，用来获取每一帧更新的时机，_onTick方法会在每一帧更新的时候调用，并通知CustomPaint去重绘。实际上，Flutter的动画也是使用Ticker对象，在每一帧更新的时候触发组件重绘
为了创建Ticker对象，需要用到TickerProvider对象，它提供了创建Ticker对象的方法（createTicker），并确保onTick回调函数只在组件处在前台活跃状态的时候才触发。为了获得TickerProvider对象，最常用的做法是创建一个StatefullWidget，并给State添加SingleTickerProviderStateMixin mixin，如果大家写过动画相关的代码，对这一套应该不陌生：

class _GameView extends StatefulWidget {

  const _GameView({Key? key}) : super(key: key);



  @override

  State<_GameView> createState() => _GameViewState();

}



class _GameViewState extends State<_GameView>

    with SingleTickerProviderStateMixin {

  late final Emulator _emulator;

  /// 在每一帧更新的时候去通知_LCD重绘

  late final _Timer _timer;



  @override

  void initState() {

    super.initState();

    _emulator = Emulator();

    // 运行模拟器，不断的产生每一帧的像素数据

    _emulator.run();

    _timer = _Timer(this);

  }



  @override

  Widget build(BuildContext context) {

    return SizedBox(

      width: lcdWidth.toDouble(),

      height: lcdHeight.toDouble(),

      child: CustomPaint(

        painter: _LCD(

          emulator: _emulator,

          timer: _timer,

        ),

      ),

    );

  }



  @override

  void dispose() {

    _emulator.dispose();

    _timer.dispose();

    super.dispose();

  }

}

至此，我们已经完成了所有的步骤，看一下运行效果：

总结

本文讲述了Flutter中如何实时绘制自己生成的像素数据，有以下几个步骤：

1. 生成像素数据


2. 调用decodeImageFromPixels方法将像素数据转换为Image对象


3. 调用Canvas的drawImage方法绘制像素数据


4. 使用Ticker对象获取每一帧更新的时机，并通知CustomPainter去重绘

如果有错误，还请大家帮忙指正, 希望能够对大家有所帮助

一、我讲

今天，我主要讲一下android里面的服务Service，以及它的使用方法。

1.1 服务 Service

Service其实是Android的四大组件之一。

安卓有四大组件，前面我们说的Activity和BroadCastReceiver,其实都属于四大组件。你看，我没有一上来就讲让你先记住四大组件，而是慢慢渗透，因为没有例子的应用，记那些没有意义。

在Android中，能看到的属于Activity，看不到的属于Service。

Service的运行不依赖于任何用户界面，即使程序被切换到后台，或者用户打开了另一个应用程序，Service仍然能够保持正常运行。

1.2 Service的使用

创建

可选中包名，右键点击菜单，输入你的服务的名称进行创建。

其实，你这步操作，影响了两处代码。

第一，新建了一个继承Service的类。

public class MyService extends Service {



    @Override

    public void onCreate() {

        super.onCreate();

    }



    @Override

    public int onStartCommand(final Intent intent, int flags, int startId) {

        // 巴拉巴拉

        return super.onStartCommand(intent, flags, startId);

    }



    @Override

    public void onDestroy() {

        super.onDestroy();

    }

}

当服务每次启动时，都会执行onStartCommand方法，所以我们终点会把逻辑写到这里面。

第二，在AndroidManifest.xml中做了注册。

<?xml version="1.0" encoding="utf-8"?>

<manifest>

    <application>

        ……

        <service

            android:name=".MyService"

            android:enabled="true"

            android:exported="true"></service>

        

    </application>

</manifest>

启动和停止

服务的启动和停止，一般通过Intent在Activity中进行。

Intent intent = new Intent(this, MyService.class);

startService(intent);

stopService(intent);

通过Intent构建要提供哪一个服务，然后调用startService启动服务，stopService停止服务。

二、你做

我们要搞一个这样的功能：

启动服务后，在服务里面循环播放古诗，退出程序也不打断，看其他应用也不打断。这样，能播放一整天，你看抖音时也弹。这导致你，无奈地就学会了一首诗。

虽然，我们说服务没有界面，但是启动它要界面，我们写在MainActivity中，它的布局是activity_main.xml,就两个按钮，一个启动，一个关闭。

<?xml version="1.0" encoding="utf-8"?>

<ConstraintLayout tools:context=".MainActivity">

    <Button

        android:id="@+id/button1"

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        android:text="启动服务"

        android:onClick="start" />

    <Button

        android:id="@+id/button2"

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        android:text="关闭服务"

        android:onClick="stop" />

</ConstraintLayout>

又看到了熟悉的onClick=""这个我们之前讲过。

对应下面的逻辑控制代码，里面有服务的启动和停止。

public class MainActivity extends Activity {



    Intent intent;

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        intent = new Intent(this, MyService.class);

    }





    public void start(View view) {

        startService(intent);

    }



    public void stop(View view) {

        stopService(intent);

    }

}

最后，也是重点，就是我们的服务实现逻辑。

先定义一个字符串数组texts用于存储每一句诗词。

然后在onStartCommand里，启动一个线程。

线程里有一个循环，每休眠3秒钟，就往外发送一条消息。

这条消息由Handler发送和接收，接收到后切换诗句，然后通过Toast弹出来。

public class MyService extends Service {



    String[] texts = new String[]{"窗前明月光","疑是地上霜","举头望明月","低头思故乡"};

    int index = 0;

    boolean isRun = true;

    

    ……

    

    @Override

    public int onStartCommand(final Intent intent, int flags, int startId) {



        new Thread(){

        

            @Override

            public void run() {

                while (isRun){

                    if (index+1 > texts.length){

                        index = 0;

                    }

                    handler.sendEmptyMessage(index);

                    sleep(3000);

                    index++;

                }

            }

        }.start();

        

        return super.onStartCommand(intent, flags, startId);

    }



    Handler handler = new Handler(){

        @Override

        public void handleMessage(Message msg) {

            super.handleMessage(msg);

            Toast.makeText(MyService.this, ""+texts[msg.what], Toast.LENGTH_SHORT).show();

        }

    };



    @Override

    public void onDestroy() {

        super.onDestroy();

        isRun = false;

    }

}

需要注意，isRun是控制是否还循环，如果为false了，while循环就不执行了，线程结束。

另外，Service也是有生命周期的，这个生命周期和Activity的生命周期类似，当 onDestroy() 销毁时，需要做一些收尾工作。

好了，最后点击运行，启动服务，去看看效果吧。

最近，使用compose编写了一个类QQ的image picker。完成android library的编写，在此记录下发布这个Library到maven central的流程以及碰到的问题。

maven：mvnrepository.com/artifact/io…

github：github.com/huhx/compos…

Sonatype 账号

MavenCentral 和 Sonatype 的关系

因此我们要发布Library到Maven Central的话，首先需要Sonatype的账号以及权限。

申请 Sonatype 账号

申请账号地址： issues.sonatype.org/secure/Sign…

登录账号创建issue

创建issue地址：issues.sonatype.org/secure/View…

点击 Create 按钮, 然后会弹出 Create Issue的窗口：

点击Configure Fields, 选择 Custom 选项

grouId的话最好使用: io.github.github_name, 要不然使用其他的还需要在 DNS 配置中配置一个TXT记录来验证域名所有权

填写完所有的信息点击创建，一个新的issue就创建成功了，以下就是我创建的issue，附上链接：issues.sonatype.org/browse/OSSR…

值得注意的是sonatype要求我们创建一个github仓库来验证我们的github账号。创建完仓库之后，我们回复热心的工作人员，接下来就是等他们的处理结果了。大概30分钟就能好吧

收到这样的回复，代表一切ready了你可以上传package到maven central。

编写gradle脚本上传Lib

这篇文章里面，我是使用的android library做例子的。如果你想要发布java的Library，可以参考：docs.gradle.org/current/use…

In module project, build.gradle file

// add maven-publish and signing gradle plugin

plugins {

    id 'maven-publish'

    id 'signing'

}



// add publish script

publishing {

    publications {

        release(MavenPublication) {

            pom {

                name = 'Image Picker Compose'

                description = 'An Image Picker Library for Jetpack Compose'

                url = 'https://github.com/huhx/compose_image_picker'



                licenses {

                    license {

                        name = 'The Apache License, Version 2.0'

                        url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'

                    }

                }



                developers {

                    developer {

                        id = 'huhx'

                        name = 'hongxiang'

                        email = 'gohuhx@gmail.com'

                    }

                }



                scm {

                    connection = 'https://github.com/huhx/compose_image_picker.git'

                    developerConnection = 'https://github.com/huhx/compose_image_picker.git'

                    url = 'https://github.com/huhx/compose_image_picker'

                }

            }



            groupId "io.github.huhx"

            artifactId "compose-image-picker"

            version "1.0.2"



            afterEvaluate {

                from components.release

            }

        }

    }

    repositories {

        maven {

            url "https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/"

            credentials {

                username ossrhUsername // ossrhUsername is your sonatype username

                password ossrhPassword // ossrhUsername is your sonatype password

            }

        }

    }

}



// signing, this need key, secret, we put it into gradle.properties

signing {

    sign publishing.publications.release

}

ossrhUsername 和 ossrhPassword 是我们在第一步注册的sonatype账号。用户名和密码是敏感信息，我们放在gradle.properties并且不会提交到github。因此在 gradle.properties文件中，我们添加了以下内容：

# signing information

signing.keyId=key

signing.password=password

signing.secretKeyRingFile=file path



# sonatype account

ossrhUsername=username

ossrhPassword=password

其中包含了签名的三个重要信息，这个我们会在下面详细讲解

创建gpg密钥

我使用的是mac，这里就拿mac来说明如何创建gpg密钥。以下是shell脚本

# 安佳 gpg

> brew install gpg



# 创建gpg key，过程中会提示你输入密码。

# 记住这里要输入的密码就是上述提到你需要配置的signing.password

> gpg --full-gen-key



# 切换目录到~/.gnupg/openpgp-revocs.d, 你会发现有一个 .rev文件。

# 这个文件名称的末尾8位字符就是上述提到你需要配置的signing.keyId

> cd ~/.gnupg/openpgp-revocs.d && ls



# 创建secretKeyRingFile, 以下命令会创建一个文件secret.gpg

# 然后~/.gnupg/secret.gpg就是上述提到你需要配置的signing.secretKeyRingFile

> cd ~/.gnupg/ && gpg --export-secret-keys -o secret.gpg

把signing相关的信息成功填写到gradle.properties之后，我们就可以借助maven-publish插件发布我们的andoird包到maven的中心仓库了

maven publish的gradle task

# 这个是发布到我们的本地，你可以在~/.m2/repository/的目录找到你发布的包

> ./gradlew clean publishToMavenLocal



# 这个是发布到maven的中心仓库，你可以在https://s01.oss.sonatype.org/#stagingRepositories找到

> ./gradlew clean publish

我们执行./gradlew clean publish命令之后，访问地址：s01.oss.sonatype.org/#stagingRep…

可以看到我们的android包已经在nexus repository了，接下来你要做的两步就是Close and Release。

Maven检验以及发布

第一步：点击Close按钮，它会触发对发布包的检验。我在这个过程中碰到一个signature validation失败的问题。

# 失败原因：No public key in hkp://keyserver.ubuntu.com:11371，是因为同步key可能会花些时间。这里我们可以手动发布我们的key到相应的服务器上

> gpg --keyserver hkp://keyserver.ubuntu.com:11371 --send-keys signing.keyId

第二步：确保你填入的信息是满足要求之后，Release按钮就会被激活。点击Release，接下来就是等待时间了，不出意外的话。30分钟你可以在nexus repository manager找到，但是在mvnrepository.com/找到的话得花更长的时间。

背景

Android系统模块代码的编译实在是太耗时了，即使寥寥几行代码的修改，也能让一台具有足够性能的编译服务器工作十几分钟以上（模块单编），只为编出一些几兆大小的jar和dex。

这里探究的是系统完成过一次整编后进行的模块单编，即m、mm、mmm等命令。

除此之外，一些不会更新源码、编译配置等文件的内容的操作，如touch、git操作等，会被Android系统编译工具识别为有差异，从而在编译时重新生成编译配置，重新编译并没有更新的源码、重新生成没有差异的中间文件等一系列严重耗时操作。

本文介绍关于编译过程中的几个阶段，以及这些阶段的耗时点/耗时原因，并最后给出一个覆盖一定应用场景的基于ninja的加快编译的方法（实际上是裁剪掉冗余的编译工作）。

环境

编译服务器硬件及Android信息：

• Ubuntu 18.04.4 LTS
• Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (28核56超线程)
• MemTotal: 65856428 kB (62.8GiB)
• AOSP Android 10.0
• 仅修改某个Java文件内部的boolean初始化值（true改false）
• 不修改其他任何内容，包括源码、mk、bp的情况下，使用m单编模块（在清理后，使用对比的ninja进行单编）
• 使用time计时
• 此前整个系统已经整编过一次
• 编译时不修改任何编译配置文件如Android.mk

之所以做一个代码修改量微乎其微的case，是因为要分析编译性能瓶颈，代码变更量越小的情况下，瓶颈就越明显，越有利于分析。

关键编译阶段和耗时分析

由于Makefile结构复杂、不易调试、难以扩展，因此Android决定将它替换掉。Android在7.0时引入了Soong，它将Android从Makefile的编译架构带入到了ninja的时代。

Soong包含两大模块，其中Kati负责解析Makefile并转换为.ninja，第二个模块Ninja则基于生成的.ninja完成编译。

Kati是对GNU Make的clone，并将编译后端实现切换到ninja。Kati本身不进行编译，仅生成.ninja文件提供给Ninja进行编译。

Makefile/Android.mk -> Kati -> Ninja

Android.bp -> Blueprint -> Soong -> Ninja

因此在执行编译之前（即Ninja真正开动时），还有一些生成.ninja的步骤。关键编译阶段如下：

1. Soong的自举（Bootstrap），将Soong本身编译出来
   1. 系统代码首次编译会比较耗时，其中一个原因是Soong要全新编译它自己
2. 遍历源码树，收集所有编译配置文件（Makefile/Android.mk/Android.bp)
   1. 遍历、验证非常耗时，多么强劲配置的机器都将受限于单线程效率和磁盘IO效率
   2. 由于Android系统各模块之间的依赖、引入，因此即使是单编模块，Soong（Kati）也不得不确认目标模块以外的路径是否需要重新跟随编译。
3. 验证编译配置文件的合法性、有效性、时效性、是否应该加入编译，生成.ninja
   1. 如果没有任何更改，.ninja不需要重新生成
   2. 最终生成的.ninja文件很大（In my case，1GB以上），有很明显的IO性能效率问题，显然在查询效率方面也很低下
4. 最后一步，真正执行编译，调用ninja进入多线程编译
   1. 由于Android加入了大量的代码编译期工作，如API权限控制检查、API列表生成等工作（比如，生成系统API保护名单、插桩工作等等），因此编译过程实际上不是完全投入到编译中
   2. 编译过程穿插“泛打包工作”，如生成odex、art、res资源打包。虽然不同的“泛打包”可以多线程并行进行，但是每个打包本身只能单线程进行

下面将基于模块单编（因开发环境系统全新编译场景频率较低，不予考虑），对这四个关键阶段进行性能分析。

阶段一：Soong bootstrap

在系统已经整编过一次的情况下，Soong已经完成了编译，因此其预热过程占整个编译时间的比例会比较小。

在“环境”下，修改一行Framework代码触发差异进行编译。并且使用下面的命令进行编译。

time m services framework -j57

编译实际耗时22m37s：

 build completed successfully (22:37 (mm:ss)) ####

real    22m37.504s

user    110m25.656s

sys     12m28.056s

对应的分阶段耗时如下图。

• 可以看到，包括Soong bootstrap流程在内的预热耗时占比非常低，耗时约为11.6s，总耗时约为1357s，预热耗时占比为0.8%。

• Kati和ninja，也就是上述编译关键流程的第2步和第3步，分别占了接近60%（820秒，13分钟半）和约35%（521秒，8分钟半）的耗时，合计占比接近95%的耗时。

注：这个耗时是仅小幅度修改Java代码后测试的耗时。如果修改编译配置文件如Android.mk，会有更大的耗时。

小结：看来在完成一次整编后的模块单编，包括Soong bootstrap、执行编译准备脚本、vendorsetup脚本的耗时占比很低，可以完全排除存在性能瓶颈的可能。

阶段二：Kati遍历、mk搜集与ninja生成

从上图可以看到，Kati耗时占比很大，它的任务是遍历源码树，收集所有的编译配置文件，经过验证和筛选后，将它们解析并转化为.ninja。

从性能角度来看，它的主要特点如下：

1. 它要遍历源码树，收集所有mk文件（In my case，有983个mk文件）
2. 解析mk文件（In my case，framework/base/Android.mk耗费了~6800ms）
3. 生成并写入对应的.ninja
4. 单线程

直观展示如下，它是一个单线程的、IO速度敏感、CPU不敏感的过程：

Kati串行地处理文件，此时对CPU利用率很低，对IO的压力也不高。

小结：可以确定它的性能瓶颈来源于IO速度，单纯为编译实例分配更多的CPU资源也无益于提升Kati的速度。

阶段三：Ninja编译

SoongClone了一份GNU Make，并将其改造为Kati。即使我们没有修改任何mk文件，前面Kati仍然会花费数分钟到数十分钟的工作耗时，只为了生成一份能够被Ninja或.ninja的生成工具能够识别的文件。接下来是调用Ninja真正开始编译工作。

从性能角度来看，它的主要特点如下：

1. 根据目标target及依赖，读取前面生成的.ninja配置，进行编译
2. 比较独立，不与前面的组件，如blueprint、kati等耦合，只要.ninja文件中能找到target和build rule就能完成编译
3. 多线程

直观展示如下，Ninja将会根据传入的并行任务数参数启动对应数量的线程进行编译。Ninja编译阶段会真正的启动多线程。但做不到一直多线程编译，因为部分阶段如部分编译目标（比如生成一个API文档）、泛打包阶段等本身无法多线程并行执行。

可以看到此时CPU利用率应该是可以明显上升的。但是耗时较大的阶段仅启用了几个线程，后面的阶段和最后的图形很细（时间占比很小）的阶段才用起来更多的线程。

其中，一些阶段（图中时间占比较长的几条记录）没能跑满资源的原因是这些编译目标本身不支持并行，且本次编译命令指定的目标已经全部“安排”了，不需要调动更多资源启动其他编译目标的工作。当编译整个系统时就能够跑满了。

最后一个阶段（图中最后的几列很细的记录）虽然跑满了所有线程资源，但是运行时间很短。这是因为本case进行编译分析的过程中，仅修改了一行代码来触发编译。因编译工作量很小，所以这几列很细。

小结：我们看到，Ninja编译启动比较快，这表明Ninja对.ninja文件的读取解析并不敏感。整个过程也没有看到显著的耗时点。且最后面编译量很小，表明Ninja能够确保增量编译、未更新不编译。

编译优化

本节完成点题——Android系统编译优化：使用Ninja加快编译。

根据前面分析的小结，可以总结性能瓶颈:

1. Kati遍历、生成太慢，受限于IO速率
2. Kati吞吐量太低，单线程
3. 不论有无更新均重新解析Makefile

利用Ninja进行编译优化的思路是，大多数场景，可以舍弃Kati的工作，仅执行Ninja的工作，以节省掉60%以上的时间。其核心思路，也是制约条件，即在不影响编译正确性的前提下，舍弃不必要的Kati编译工作。

• 使用Ninja直接基于.ninja文件进行编译来改善耗时：

结合前面的分析，容易想到，如果目标被构建前，能够确保mk文件没有更新也不需要重新生成一长串的最终编译目标（即.ninja），那么make命令带来的Soong bootstrap、Kati等工作完全是重复的冗余的——这个性质Soong和Kati自己识别不出来，它们会重复工作一次。

既重新生成.ninja是冗余的，那么直接命令编译系统根据指定的.ninja进行编译显然会节省大量的工作耗时。ninja命令is the key:

使用源码中自带的ninja:

./prebuilts/build-tools/linux-x86/bin/ninja --version

1.8.2.git

对比最上面列出的make命令的编译，这里用ninja编译同样的目标：

 time ./prebuilts/build-tools/linux-x86/bin/ninja -j 57 -v -f out/combined-full_xxxxxx.ninja services framework

ninja自己识别出来CPU平台后，默认使用-j58。这里为了对比上面的m命令，使用-j57编译

-f参数指定.ninja文件。它是编译配置文件，在Android中由Kati生成。这里文件名用'x'替换修改

编译结果，对比上面的m，有三倍的提升：

real    7m57.835s

user    97m12.564s

sys     8m31.756s

编译耗时为8分半，仅make的三分之一。As we can see，当能够确保编译配置没有更新，变更仅存在于源码范围时，使用Ninja直接编译，跳过Kati可以取得很显著的提升。

直接使用ninja:

./prebuilts/build-tools/linux-x86/bin/ninja -j $MAKE_JOBS -v -f out/combined-*.ninja <targets...>

对比汇总

这里找了一个其他项目的编译Demo，该Demo的特点是本身代码较简单，编译配置也较简单，整体编译工作较少，通过make编译的大部分耗时来自soong、make等工具自身的消耗，而真正执行编译的ninja耗时占比极其低。由于ninja本身跳过了soong，因此可以跳过这一无用的繁琐的耗时。可以看到下面，ninja编译iperf仅花费10秒。这个时间如果给soong来编译，预热都不够。

$ -> f_ninja_msf iperf

Run ninja with out/combined-full_xxxxxx.ninja to build iperf.

====== ====== ======

Ninja: ./prebuilts/build-tools/linux-x86/bin/ninja@1.8.2.git

Ninja: build with out/combined-full_xxxxxx.ninja

Ninja: build targets iperf

Ninja: j72

====== ====== ======

time /usr/bin/time ./prebuilts/build-tools/linux-x86/bin/ninja -j 72 -f out/combined-full_xxxxxx.ninja iperf



[24/24] Install: out/target/product/xxxxxx/system/bin/iperf

53.62user 11.09system 0:10.17elapsed 636%CPU (0avgtext+0avgdata 5696772maxresident)

4793472inputs+5992outputs (4713major+897026minor)pagefaults 0swaps



real    0m10.174s

user    0m53.624s

sys     0m11.096s

下面给出soong编译的恐怖耗时：

$ -> rm out/target/product/xxxxxx/system/bin/iperf

$ -> time m iperf -j72



...



[100% 993/993] Install: out/target/product/xxxxxx/system/bin/iperf



#### build completed successfully (14:45 (mm:ss)) ####





real    14m45.164s

user    23m40.616s

sys     11m46.248s

As we can see，m和ninja一个是10+ minutes，一个是10+ seconds，比例是88.5倍。

Kotlin 的标准库提供了不少方便的实用工具函数，比如 with, let, apply 之流，这些工具函数有一个共同特征：都调用了 contract() 函数。

@kotlin.internal.InlineOnly

public inline fun <T, R> with(receiver: T, block: T.() -> R): R {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return receiver.block()

}



@kotlin.internal.InlineOnly

public inline fun repeat(times: Int, action: (Int) -> Unit) {

    contract { callsInPlace(action) }



    for (index in 0 until times) {

        action(index)

    }

}

contract？协议？它到底是起什么作用？

函数协议

contract 其实就是一个顶层函数，所以可以称之为函数协议，因为它就是用于函数约定的协议。

@ContractsDsl

@ExperimentalContracts

@InlineOnly

@SinceKotlin("1.3")

@Suppress("UNUSED_PARAMETER")

public inline fun contract(builder: ContractBuilder.() -> Unit) { }

用法上，它有两点要求：

• 仅用于顶层方法
• 协议描述须置于方法开头，且至少包含一个「效应」（Effect）

可以看到，contract 的函数体为空，居然没有实现，真是一个神奇的存在。这么一来，此方法的关键点就只在于它的参数了。

ContractBuilder

contract的参数是一个将 ContractBuilder 作为接受者的lambda，而 ContractBuilder 是一个接口：

@ContractsDsl

@ExperimentalContracts

@SinceKotlin("1.3")

public interface ContractBuilder {

    @ContractsDsl public fun returns(): Returns

    @ContractsDsl public fun returns(value: Any?): Returns

    @ContractsDsl public fun returnsNotNull(): ReturnsNotNull

    @ContractsDsl public fun <R> callsInPlace(lambda: Function<R>, kind: InvocationKind = InvocationKind.UNKNOWN): CallsInPlace

}

其四个方法分别对应了四种协议类型，它们的功能如下：

• returns：表明所在方法正常返回无异常
• returns(value: Any?)：表明所在方法正常执行，并返回 value（其值只能是 true、false 或者 null）
• returnsNotNull()：表明所在方法正常执行，且返回任意非 null 值
• callsInPlace(lambda: Function<R>, kind: InvocationKind = InvocationKind.UNKNOWN)：声明 lambada 只在所在方法内执行，所在方法执行完毕后，不会再被其他方法调用；可通过 kind 指定调用次数

前面已经说了，contract 的实现为空，所以作为接受着的 ContractBuilder 类型，根本没有实现类 —— 因为没有地方调用，就不需要啊。它的存在，只是为了声明所谓的协议代编译器使用。

InvocationKind

InvocationKind 是一个枚举类型，用于给 callsInPlace 协议方法指定执行次数的说明：

@ContractsDsl

@ExperimentalContracts

@SinceKotlin("1.3")

public enum class InvocationKind {

    // 函数参数执行一次或者不执行

    @ContractsDsl AT_MOST_ONCE,

    // 函数参数至少执行一次

    @ContractsDsl AT_LEAST_ONCE,

    // 函数参数执行一次

    @ContractsDsl EXACTLY_ONCE,

    // 函数参数执行次数未知

    @ContractsDsl UNKNOWN

}

InvocationKind.UNKNOWN，次数未知，其实就是指任意次数。标准工具函数中，repeat 就指定的此类型，因为其「重复」次数由参数传入，确实未知；而除它外，其余像 let、with 这些，都是用的InvocationKind.EXACTLY_ONCE，即单次执行。

Effect

Effect 接口类型，表示一个方法的执行协议约定，其不同子接口，对应不同的协议类型，前面提到的 Returns、ReturnsNotNull、CallsInPlace 均为它的子类型。

public interface Effect



public interface ConditionalEffect : Effect



public interface SimpleEffect : Effect {

    public infix fun implies(booleanExpression: Boolean): ConditionalEffect

}



public interface Returns : SimpleEffect



public interface ReturnsNotNull : SimpleEffect



public interface CallsInPlace : Effect

简单明了，全员接口！来看一个官方使用，以便理解下这些接口的意义和使用：

public inline fun Array<*>?.isNullOrEmpty(): Boolean {

    contract {

        returns(false) implies (this@isNullOrEmpty != null)

    }



    return this == null || this.isEmpty()

}

这里涉及到两个 Effect：Returns 和 ConditionalEffect。此方法的功能为：判断数组为 null 或者是无元素空数组。它的 contract 约定是这样的：

1. 调用 returns(value: Any?) 获得 Returns 协议（当然也就是 SimpleEffect 协议），其传入值是 false
2. 第1步的 Returns 调用 implies 方法，条件是「本对象非空」，得到了一个 ConditionalEffect
3. 于是，最终协议的意思是：函数返回 false 意味着 接受者对象非空

isNullOrEmpty() 的功能性代码给出了返回值为 true 的条件。虽然反过来说，不满足该条件，返回值就是 false，但还是通过 contract 协议里首先说明了这一点。

协议的意义

讲到这里，contract 协议涉及到的基本类型及其使用已经清楚了。回过头来，前面说到，contract() 的实现为空，即函数体为空，没有实际逻辑。这说明，这个调用是没有实际执行效果的，纯粹是为编译器服务。

不妨模仿着 let 写一个带自定义 contract 测试一下这个结论：

// 类比于ContractBuilder

interface Bonjour {



    // 协议方法

    fun <R> parler(f: Function<R>)  {

        println("parler something")

    }

}





// 顶层协议声明工具，类比于contract

inline fun bonjour(b: Bonjour.() -> Unit) {}





// 模仿let

fun<T, R> T.letForTest(block: (T) -> R): R {

    println("test before")

    bonjour {

        println("test in bonjour")

        parler<String> {

            ""

        }

    }

    println("test after")

    return block(this)

}



fun main(args: Array<String>) {

    "abc".letForTest {

        println("main: $it called")

    }

}

letForTest() 是类似于 let 的工具方法（其本身功能逻辑不重要）。执行结果：

test before

test after

main: abc called

如预期，bonjour 协议以及 Bonjour 协议构造器中的所有日志都未打印，都未执行。

这再一次印证，contract 协议仅为编译器提供信息。那协议对编码来说到底有什么意义呢？来看看下面的场景：

fun getString(): String? {

    TODO()

}



fun String?.isAvailable(): Boolean {

    return this != null && this.length > 0

}

getString() 方法返回一个 String 类型，但是有可能为 null。isAvailable 是 String? 类型的扩展，用以判断是否一个字符串非空且长度大于 0。使用如下：

val target = getString()

if (target.isAvailable()) {

    val result: String = target

}

按代码的设计初衷，上述调用没问题，target.isAvailable() 为 true，证明 target 是非空且长度大于 0 的字符串，然后内部将它赋给 String 类型 —— 相当于 String? 转换成 String。

可惜，上述代码，编译器不认得，报错了：

Type mismatch.

    Required:

        String

    Found:

        String?

编译器果然没你我聪明啊！要解决这个问题，自然就得今天的主角上场了：

fun String?.isAvailable(): Boolean {

    contract {

        returns(true) implies (this@isAvailable != null)

    }

    return this != null && this.length > 0

}

使用 contract 协议指定了一个 ConditionalEffect，描述意思为：如果函数返回true，意味着 Receiver 类型非空。然后，编译器终于懂了，前面的错误提示消失。

这就是协议的意义所在：让编译器看不懂的代码更加明确清晰。

小结

函数协议可以说是写工具类函数的利器，可以解决很多因为编译器不够智能而带来的尴尬问题。不过需要明白的是，函数协议还是实验性质的，还没有正式发布为 stable 功能，所以是有可能被 Kotlin 官方 去掉的。

之前一些列的文章重点在于分析协程本质原理，了解了协程的内核再来看其它衍生的知识就比较容易了。

接下来这边文章着重分析协程框架提供的一些重要的函数原理，通过本篇文章，你将了解到：

1. runBlocking 使用与原理


2. launch 使用与原理


3. join 使用与原理


4. async/await 使用与原理


5. delay 使用与原理

1. runBlocking 使用与原理

默认分发器的runBlocking

使用

老规矩，先上Demo：

    fun testBlock() {

        println("before runBlocking thread:${Thread.currentThread()}")

        //①

        runBlocking {

            println("I'm runBlocking start thread:${Thread.currentThread()}")

            Thread.sleep(2000)

            println("I'm runBlocking end")

        }

        //②

        println("after runBlocking:${Thread.currentThread()}")

    }

runBlocking 开启了一个新的协程，它的特点是：

协程执行结束后才会执行runBlocking 后的代码。

也就是① 执行结束后 ② 才会执行。

可以看出，协程运行在当前线程，因此若是在协程里执行了耗时函数，那么协程之后的代码只能等待，基于这个特性，runBlocking 经常用于一些测试的场景。

runBlocking 可以定义返回值，比如返回一个字符串：

    fun testBlock2() {

        var name = runBlocking {

            "fish"

        }

        println("name $name")

    }

原理

    #Builders.kt

    public fun <T> runBlocking(context: CoroutineContext = EmptyCoroutineContext, block: suspend CoroutineScope.() -> T): T {

        //当前线程

        val currentThread = Thread.currentThread()

        //先看有没有拦截器

        val contextInterceptor = context[ContinuationInterceptor]

        val eventLoop: EventLoop?

        val newContext: CoroutineContext

        //----------①

        if (contextInterceptor == null) {

            //不特别指定的话没有拦截器，使用loop构建Context

            eventLoop = ThreadLocalEventLoop.eventLoop

            newContext = GlobalScope.newCoroutineContext(context + eventLoop)

        } else {

            eventLoop = (contextInterceptor as? EventLoop)?.takeIf { it.shouldBeProcessedFromContext() }

                ?: ThreadLocalEventLoop.currentOrNull()

            newContext = GlobalScope.newCoroutineContext(context)

        }

        //BlockingCoroutine 顾名思义，阻塞的协程

        val coroutine = BlockingCoroutine<T>(newContext, currentThread, eventLoop)

        //开启

        coroutine.start(CoroutineStart.DEFAULT, coroutine, block)

        //等待协程执行完成----------②

        return coroutine.joinBlocking()

    }

重点看①②。

先说①，因为我们没有指定分发器，因此会使用loop，实际创建的是BlockingEventLoop，它继承自EventLoopImplBase，最终继承自CoroutineDispatcher（注意此处是个重点）。

根据我们之前分析的协程知识可知，协程启动后会构造DispatchedContinuation，然后依靠dispatcher将runnable 分发执行，而这个dispatcher 即是BlockingEventLoop。

    #EventLoop.common.kt

    //重写dispatch函数

    public final override fun dispatch(context: CoroutineContext, block: Runnable) = enqueue(block)



    public fun enqueue(task: Runnable) {

        //将task 加入队列，task = DispatchedContinuation

        if (enqueueImpl(task)) {

            unpark()

        } else {

            DefaultExecutor.enqueue(task)

        }

    }

BlockingEventLoop 的父类EventLoopImplBase 里有个成员变量：_queue，它是个队列，用来存储提交的任务。

再看②：

协程任务已经提交到队列里，就看啥时候取出来执行了。

#Builders.kt

    fun joinBlocking(): T {

        try {

            try {

                while (true) {

                    //当前线程已经中断了，直接退出

                    if (Thread.interrupted()) throw InterruptedException().also { cancelCoroutine(it) }

                    //如果eventLoop！= null，则从队列里取出task并执行

                    val parkNanos = eventLoop?.processNextEvent() ?: Long.MAX_VALUE

                    //协程执行结束，跳出循环

                    if (isCompleted) break

                    //挂起线程，parkNanos 指的是挂起时间

                    parkNanos(this, parkNanos)

                    //当线程被唤醒后，继续while循环

                }

            } finally { // paranoia

            }

        }

        //返回结果

        return state as T

    }



#EventLoop.common.kt

    override fun processNextEvent(): Long {

        //延迟队列

        val delayed = _delayed.value

        //延迟队列处理，这里在分析delay时再解释

        //从队列里取出task

        val task = dequeue()

        if (task != null) {

            //执行task

            task.run()

            return 0

        }

        return nextTime

    }

上面代码的任务有两个：

1. 尝试从队列里取出Task。


2. 若是没有则挂起线程。

结合①②两点，再来过一下场景：

1. 先创建协程，包装为DispatchedContinuation，作为task。


2. 分发task，将task加入到队列里。


3. 从队列里取出task执行，实际执行的即是协程体。


4. 当3执行完毕后，runBlocking()函数也就退出了。

其中虚线箭头表示执行先后顺序。

由此可见，runBlocking()函数需要等待协程执行完毕后才退出。

指定分发器的runBlocking

上个Demo在使用runBlocking 时没有指定其分发器，若是指定了又是怎么样的流程呢？

    fun testBlock3() {

        println("before runBlocking thread:${Thread.currentThread()}")

        //①

        runBlocking(Dispatchers.IO) {

            println("I'm runBlocking start thread:${Thread.currentThread()}")

            Thread.sleep(2000)

            println("I'm runBlocking end")

        }

        //②

        println("after runBlocking:${Thread.currentThread()}")

    }

指定在子线程里进行分发。

此处与默认分发器最大的差别在于：

默认分发器加入队列、取出队列都是同一个线程，而指定分发器后task不会加入到队列里，task的调度执行完全由指定的分发器完成。

也就是说，coroutine.joinBlocking()后，当前线程一定会被挂起。等到协程执行完毕后再唤醒当前被挂起的线程。

唤醒之处在于：

#Builders.kt

    override fun afterCompletion(state: Any?) {

        // wake up blocked thread

        if (Thread.currentThread() != blockedThread)

            //blockedThread 即为调用coroutine.joinBlocking()后阻塞的线程

            //Thread.currentThread() 为线程池的线程

            //唤醒线程

            unpark(blockedThread)

    }

不管是否指定分发器，runBlocking() 都会阻塞等待协程执行完毕。

2. launch 使用与原理

想必大家刚接触协程的时候使用最多的还是launch启动协程吧。

看个Demo：

    fun testLaunch() {

        var job = GlobalScope.launch {

            println("hello job1 start")//①

            Thread.sleep(2000)

            println("hello job1 end")//②

        }

        println("continue...")//③

    }

非常简单，启动一个线程，打印结果如下：

③一定比①②先打印，同时也说明launch()函数并不阻塞当前线程。

关于协程原理，在之前的文章都有深入分析，此处不再赘述，以图示之：

3. join 使用与原理

虽然launch()函数不阻塞线程，但是我们就想要知道协程执行完毕没，进而根据结果确定是否继续往下执行，这时候该Job.join()出场了。

先看该函数的定义：

#Job.kt

public suspend fun join()

是个suspend 修饰的函数，suspend 是咱们的老朋友了，说明协程执行到该函数会挂起(当前线程不阻塞，另有他用)。

继续看其实现：

    #JobSupport.kt

    public final override suspend fun join() {

        //快速判断状态，不耗时

        if (!joinInternal()) { // fast-path no wait

            coroutineContext.ensureActive()

            return // do not suspend

        }

        //挂起的地方

        return joinSuspend() // slow-path wait

    }



    //suspendCancellableCoroutine 典型的挂起操作

    //cont 是封装后的协程

    private suspend fun joinSuspend() = suspendCancellableCoroutine<Unit> { cont ->

        //执行完这就挂起

        //disposeOnCancellation 是将cont 记录在当前协程的state里，构造为node

        cont.disposeOnCancellation(invokeOnCompletion(handler = ResumeOnCompletion(cont).asHandler))

    }

其中suspendCancellableCoroutine 是挂起的核心所在，关于挂起的详细分析请移步：讲真，Kotlin 协程的挂起没那么神秘(原理篇)

joinSuspend()函数有2个作用：

1. 将当前协程体存储到Job的state里（作为node)。


2. 将当前协程挂起。

什么时候恢复呢？当然是协程执行完成后。

#JobSupport.kt

private class ResumeOnCompletion(

    private val continuation: Continuation<Unit>

) : JobNode() {

    //continuation 为协程的包装体，它里面有我们真正的协程体

    //之后重新进行分发

    override fun invoke(cause: Throwable?) = continuation.resume(Unit)

}

当协程执行完毕，会例行检查当前的state是否有挂着需要执行的node，刚好我们在joinSuspend()里放了node，于是找到该node，进而找到之前的协程体再次进行分发。根据协程状态机的知识可知，这是第二次执行协程体，因此肯定会执行job.join()之后的代码，于是乎看起来的效果就是：

job.join() 等待协程执行完毕后才会往下执行。

语言比较苍白，来个图：

注：此处省略了协程挂起等相关知识，如果对此有疑惑请阅读之前的文章。

4. async/await 使用与原理

launch 有2点不足之处：协程执行没有返回值。

这点我们从它的定义很容易获悉：

    fun testAsync() {

        runBlocking {

            //启动协程

            var job = GlobalScope.async {

                println("job1 start")

                Thread.sleep(10000)

                //返回值

                "fish"

            }

            //等待协程执行结束，并返回协程结果

            var result = job.await()

            println("result:$result")

        }

    }

运行结果：

接着来看实现原理。

    public fun <T> CoroutineScope.async(

        context: CoroutineContext = EmptyCoroutineContext,

        start: CoroutineStart = CoroutineStart.DEFAULT,

        block: suspend CoroutineScope.() -> T

    ): Deferred<T> {

        val newContext = newCoroutineContext(context)

        //构造DeferredCoroutine

        val coroutine = if (start.isLazy)

            LazyDeferredCoroutine(newContext, block) else

            DeferredCoroutine<T>(newContext, active = true)

        //coroutine == DeferredCoroutine

        coroutine.start(start, coroutine, block)

        return coroutine

    }

与launch 启动方式不同的是，async 的协程定义了返回值，是个泛型。并且async里使用的是DeferredCoroutine，顾名思义：延迟给结果的协程。

后面的流程都是一样的，不再细说。

再来看Job.await()，它与Job.join()类似：

1. 先判断是否需要挂起，若是协程已经结束/被取消，当然就无需等待直接返回。


2. 先将当前协程体包装到state里作为node存放，然后挂起协程。


3. 等待async里的协程执行完毕，再重新调度执行await()之后的代码。


4. 此时协程的值已经返回。

这里需要重点关注一下返回值是怎么传递过来的。

将testAsync()反编译：

    public final Object invokeSuspend(@NotNull Object $result) {

        //result 为协程执行结果

        Object var6 = IntrinsicsKt.getCOROUTINE_SUSPENDED();

        Object var10000;

        switch(this.label) {

            case 0:

                //第一次执行这

                ResultKt.throwOnFailure($result);

                Deferred job = BuildersKt.async$default((CoroutineScope) GlobalScope.INSTANCE, (CoroutineContext)null, (CoroutineStart)null, (Function2)(new Function2((Continuation)null) {

                    int label;

                    @Nullable

                    public final Object invokeSuspend(@NotNull Object var1) {

                        Object var4 = IntrinsicsKt.getCOROUTINE_SUSPENDED();

                        switch(this.label) {

                            case 0:

                                ResultKt.throwOnFailure(var1);

                                String var2 = "job1 start";

                                boolean var3 = false;

                                System.out.println(var2);

                                Thread.sleep(10000L);

                                return "fish";

                            default:

                                throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");

                        }

                    }

                }), 3, (Object)null);

                this.label = 1;

                //挂起

                var10000 = job.await(this);

                if (var10000 == var6) {

                    return var6;

                }

                break;

            case 1:

                //第二次执行这

                ResultKt.throwOnFailure($result);

                //result 就是demo里的"fish"

                var10000 = $result;

                break;

            default:

                throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");

        }



        String result = (String)var10000;

        String var4 = "result:" + result;

        boolean var5 = false;

        System.out.println(var4);

        return Unit.INSTANCE;

    }

很明显，外层的协程(runBlocking)体会执行2次。

第1次：调用invokeSuspend(xx)，此时参数xx=Unit，后遇到await 被挂起。

第2次：子协程执行结束并返回结果"fish"，恢复外部协程时再次调用invokeSuspend(xx)，此时参数xx="fish"，并将参数保存下来，因此result 就有了值。

值得注意的是：

async 方式启动的协程，若是协程发生了异常，不会像launch 那样直接抛出，而是需要等待调用await()时抛出。

5. delay 使用与原理

线程可以被阻塞，协程可以被挂起，挂起后的协程等待时机成熟可以被恢复。

    fun testDelay() {

        GlobalScope.launch {

            println("before getName")

            var name = getUserName()

            println("after getName name:$name")

        }

    }

    suspend fun getUserName():String {

        return withContext(Dispatchers.IO) {

            //模拟网络获取

            Thread.sleep(2000)

            "fish"

        }

    }

获取用户名字是在子线程获取的，它是个挂起函数，当协程执行到此时挂起，等待获取名字之后再恢复运行。

有时候我们仅仅只是想要协程挂起一段时间，并不需要去做其它操作，这个时候我们可以选择使用delay(xx)函数：

    fun testDelay2() {

        GlobalScope.launch {

            println("before delay")

            //协程挂起5s

            delay(5000)

            println("after delay")

        }

    }

再来看看其原理。

#Delay.kt

    public suspend fun delay(timeMillis: Long) {

        //没必要延时

        if (timeMillis <= 0) return // don't delay

        return suspendCancellableCoroutine sc@ { cont: CancellableContinuation<Unit> ->

            //封装协程为cont，便于之后恢复

            if (timeMillis < Long.MAX_VALUE) {

                //核心实现

                cont.context.delay.scheduleResumeAfterDelay(timeMillis, cont)

            }

        }

    }

主要看context.delay 实现：

#DefaultExecutor.kt

internal actual val DefaultDelay: Delay = kotlinx.coroutines.DefaultExecutor



//单例

internal actual object DefaultExecutor : EventLoopImplBase(), Runnable {

    const val THREAD_NAME = "kotlinx.coroutines.DefaultExecutor"

    //...

    private fun createThreadSync(): Thread {

        return DefaultExecutor._thread ?: Thread(this, DefaultExecutor.THREAD_NAME).apply {

            DefaultExecutor._thread = this

            isDaemon = true

            start()

        }

    }

    //...

    override fun run() {

        //循环检测队列是否有内容需要处理

        //决定是否要挂起线程

    }

    //...

}

DefaultExecutor 是个单例，它里边开启了线程，并且检测队列里任务的情况来决定是否需要挂起线程等待。

先看队列的出入队情况。

放入队列

我们注意到DefaultExecutor 继承自EventLoopImplBase()，在最开始分析runBlocking()时有提到过它里面有成员变量_queue 存储队列元素，实际上它还有另一个成员变量_delayed：

#EventLoop.common.kt

internal abstract class EventLoopImplBase: EventLoopImplPlatform(), Delay {

    //存放正常task

    private val _queue = atomic<Any?>(null)

    //存放延迟task

    private val _delayed = atomic<EventLoopImplBase.DelayedTaskQueue?>(null)

}



private inner class DelayedResumeTask(

    nanoTime: Long,

    private val cont: CancellableContinuation<Unit>

) : EventLoopImplBase.DelayedTask(nanoTime) {

    //协程恢复

    override fun run() { with(cont) { resumeUndispatched(Unit) } }

    override fun toString(): String = super.toString() + cont.toString()

}

delay.scheduleResumeAfterDelay 本质是创建task：DelayedResumeTask，并将该task加入到延迟队列_delayed里。

从队列取出

DefaultExecutor 一开始就会调用processNextEvent()函数检测队列是否有数据，如果没有则将线程挂起一段时间(由processNextEvent()返回值确定)。

那么重点转移到processNextEvent()上。

##EventLoop.common.kt

    override fun processNextEvent(): Long {

        if (processUnconfinedEvent()) return 0

        val delayed = _delayed.value

        if (delayed != null && !delayed.isEmpty) {

            //调用delay 后会放入

            //查看延迟队列是否有任务

            val now = nanoTime()

            while (true) {

                //一直取任务，直到取不到(时间未到)

                delayed.removeFirstIf {

                    //延迟任务时间是否已经到了

                    if (it.timeToExecute(now)) {

                        //将延迟任务从延迟队列取出，并加入到正常队列里

                        enqueueImpl(it)

                    } else

                        false

                } ?: break // quit loop when nothing more to remove or enqueueImpl returns false on "isComplete"

            }

        }

        // 从正常队列里取出

        val task = dequeue()

        if (task != null) {

            //执行

            task.run()

            return 0

        }

        //返回线程需要挂起的时间

        return nextTime

    }

而执行任务最终就是执行DelayedResumeTask.run()函数，该函数里会对协程进行恢复。

至此，delay 流程就比较清晰了：

1. 构造task 加入到延迟队列里，此时协程挂起。


2. 有个单独的线程会检测是否需要取出task并执行，没到时间的话就要挂起等待。


3. 时间到了从延迟队列里取出并放入正常的队列，并从正常队列里取出执行。


4. task 执行的过程就是协程恢复的过程。

老规矩，上图：

图上虚线紫色框部分表明delay 执行到此就结束了，协程挂起(不阻塞当前线程），剩下的就交给单例的DefaultExecutor 调度，等待延迟的时间结束后通知协程恢复即可。

关于协程一些常用的函数分析到此就结束了，下篇开始我们一起探索协程通信(Channel/Flow 等)相关知识。

由于篇幅原因，省略了一些源码的分析，若你对此有疑惑，可评论或私信小鱼人。