一.头像组件整体流程图
1.AvatarComponent目前初步暂定兼容三种类型的头像。用户头像，群头像，普通src网络地址图像。普通src头像主要用于服务号这种，列表里面已经有服务号的头像网络地址情形。
2.头像组件在项目结构中的定位属于数据复杂UIComponent：
二.用户头像组件
比如用户头像组件加载流程如下图：
用户头像组件初始化falsetrue根据uid+appkey判断是否存在缓存用户信息根据uid+appkey获取网络用户信息false判断是否有头像地址根据用户名生成文字头像将头像的buff数据通过customGetImage返回给imageknife建立用户信息映射表重载customGetImage回调imageknife以avatarSrc为loadSrc加载头像根据头像地址下载头像组合用户头像组件的avatarSrc作为loadSrc根据uid+appkey获取用户信息true
1.用户头像组件初始化代码如下：
AvatarComponent({avatarInterface:new UserAvatarInterface(this.userinfo.uid, this.userinfo.toAppKey)})
入参的avatarInterface字段为UserAvatarInterface的类型，便于AvatarComponent内部按照用户头像规则组合缓存key，与生成/下载用户头像图片。用户头像最终的avartarSrc的组合格式为：userAvatar://[APP_KEY]/[UID][.thumb]，例如：userAvatar[://e21c13e0-b57a-49f1-985b-01af30232e1a/admin.thumb]组合的avartarSrc作为ImageKnifeComponent加载的loadSrc地址，为了在ImageKnife中建立一个以【uid+appkey】为key的图片二级缓存系统。
2.用户头像组件只是用了imageknife的图片二级缓存/展示逻辑，完全没有使用他的图片下载逻辑，下载图片逻辑目前是有业务方代码UserAvatarUtils自己实现。
3.根据uid+appkey获取用户信息，由通讯录模块提供接口实现，通讯录模块主要返回photo与name字段
4.根据头像地址下载头像时，需要保证同一个地址，同一时间只有一个下载器。imageknife拿到头像buff数据后，其内部会自己实现二级缓存与展示逻辑。
5.收到用户头像更新的通知时，更新用户信息映射表里对应的[uid:user.photo]字段后，由用户信息映射表post通知全局的头像组件。头像组件判断自己的uid在更新范围内，重走刷新逻辑。
6.imageknife组件可走customGetImage自定义的方式，由头像组件下载真实photo或者生成【名字图片】后返回给imageknife组件内部实现二级缓存/展示的源码依据：
从以上代码可以看到imageknife组件在通过customGetImage获取到resBuf后，会将图片缓存到文件系统。图片缓存内存，是统一操作的，有兴趣可以去查看imageknife组件源码
7.用户头像组件与通讯录交互时序请参考：
8.在用户文字头像生成时，这边还遇到了一个比较棘手的问题，首先用OffscreenCanvas或者graphics.drawing画出来的pixelMap数据只是一个图像像素值的map数据。如果直接将该pixelMap的buffer返回给ImageKnife的话，ImageKnife检查图片类型及其它信息时，肯定是会报错的。所以需要将画出来的pixelMap再pack成jpg图片格式，最后将jpg图片的整体buffer返回给ImageKnife才行。
