专业IM即时通讯软件开发,值得信赖!

Android手把手朋友圈实战教程(二十四)重构-九宫格控件(上)

即时通讯软件开发 云聊IM 459℃

项目地址:https://github.com/razerdp/FriendCircle

控件地址:https://github.com/razerdp/PhotoContents

ps:票圈重构已经合并到主分支了,大多数功能也在逐步赶上以前的进度,而且以后的提交主要都是往主分支提交的,如果您是在main-dev分支clone的,请切换到master分支。

写在前面:

在重构之前的票圈版本是在大四,也就是我没毕业的时候写的,那时候有着比较充裕的时间,因此更新文章也比较频繁。

而现在参与了工作之后,虽然git的提交没有断,但写文章的频率是越来越低了,不过幸好,大部分知识在重构之前的文章都写过了,所以很多东西都不需要重复描述。

虽然文章写的越来越少,但有一点是不会变的,在下一定会认真地码出每一次的进步-V-

本次自定义控件断断续续码了10天,篇幅较长,因此分为上中下三篇

  1. 上篇探究微信朋友圈实现和相关的库类,总结思路并给出一个初步的方案。
  2. 中篇初步搭建控件的基本元素。
  3. 下篇针对几个着重点进行特别描述。

如果您对这个项目感兴趣或者有什么好的建议,在下非常欢迎您提交pr或者issue哦~

预览:

preview.gif

重构之前

如果您有留意过我之前的文章,或者一直跟随着本项目进度的话,您肯定知道,在重构之前的版本里,朋友圈九宫格的实现采取的是GridView。

那时候水平不足同时又因为毕业设计等原因,所以就粗略的用GridView实现,众所周知,两个滑动控件的嵌套效率往往是不如人意的,而且两个AbsListView都是挺重的,因此在重构版本中,我下定决心亲自弄一个九宫格控件。

相关库类

本着不重复轮子的原则,开工之前肯定是去github淘一番~于是乎就找到了这么一个控件:

NineGridImageView

其中文介绍在这里:http://jaeger.itscoder.com/android/2016/03/06/nine-grid-iamge-view-libaray.html

看了一下git,star数挺多的,有着700+,想着貌似能直接用的感觉,但是本着用库先了解原理的原则,在用一个库之前,我都会去看一下核心方法。

结果不看不要紧,一看吓一跳。。。

原因在于一个方法里面:

/**
 * 设置图片数据
 *
 * @param lists 图片数据集合
 */
public void setImagesData(List lists) {
 ...略

    int[] gridParam = calculateGridParam(lists.size(), mShowStyle);
    mRowCount = gridParam[0];
    mColumnCount = gridParam[1];
    if (mImgDataList == null) {
        int i = 0;
        while (i < lists.size()) {
          ...略
            addView(iv, generateDefaultLayoutParams());
            i++;
        }
    } else {
       ...略
            for (int i = oldViewCount; i < newViewCount; i++) {
                ImageView iv = getImageView(i);
                if (iv == null) {
                    return;
                }
                addView(iv, generateDefaultLayoutParams());
            }
        
    }
    mImgDataList = lists;
    requestLayout();
}

如您所见,在设置数据的时候,用的是addView,当一个用在频繁被复用和改变的布局的View不断的进行addView时,总觉得会有点影响。这让我想起我们票圈项目的评论控件,似乎也是这么个实现方案,看来这里有空的时候需要去优化一下了。(当然,我这里并没有进行实际的测试,仅仅是通过代码层面看出来的,要真实结果应该还是要去打印日志等验证一下的

我们都知道addView执行一次会导致一次requestLayout和invalidate,这里通过循环add进来本来是没问题的,但是如果放在RecyclerView等AbsListView的话,就会导致过多的measure/layout了,直接表现就是性能下降。。。

对比了ListView,官方用的是addViewInLayout或者attachViewToParent取代addView,最后再同一进行测量等操作,不过这是后面的内容了。。

同时看了几款NineGridXXXX系列后,还是不太尽如人意,于是就决定从微信下手,然后慢慢撸出我们的九宫格控件。

微信的实现

因为我的手机是小米开发版系统,所以可以直接通过AS的Layout Inspector(视图分析)来获取微信朋友圈的UI布局(com.tencent.mm.plugin.sns.ui.SnsTimeLineUI)【应该不会被查水表吧。。。。QAQ】

得到了单图和多图的布局(顺带提一下:吐槽乐天那张干得漂亮):

从图上我们初步分析得到几个结果:

  1. 微信的做法很明显不是通过控制View的可视性来控制View的数量,而是自定义ViewGroup
  2. 无论是单张图还是多张图,用的都是同一个控件,其名为PhotosContent
  3. MaskImageView应该可以理解为点击响应前景的ImageView,在我们的工程中,相当于ForceClickImageView
  4. 不过有一点不明白的是,无论是单图还是多图,似乎都还有一个MaskImageView在占位?

有了上面几个条件,以我的经验来推测一下微信的做法:

自定义一个ViewGroup,覆写measure和layout,使其适应1张图和4张图的特殊布局

这个ViewGroup应该还有自己的缓存

  1. 举个例子,比如在一个AbsListView里面使用,上一个控件有8张图,滑动后即将被复用,复用后的控件有4张图,两者相差4个ImageView。
  2. 如果这4个ImageView没有缓存而是直接抛弃置空的话,假设我再滑回去,也就是从4个ImageView又变成8个,那么我就要重新new出4个ImageView
  3. 这明显不是很合理,所以就应该要有个缓存机制,有View的时候直接使用,没有才是new出来(不错,说的就是ListView的方法)

初步方案

思路既然已经有了,剩下来就是开始着手我们的实现方案了,在我心目中有以下几个方案:

  1. 继承GridView实现
  2. 继承GridLayout实现
  3. 继承RelativeLayout或者ViewGroup直接实现
  4. 继承FlowLayout实现

首先要抛弃的就是GridView的实现,其次GridLayout确实是个不错的方案,我也曾经试过这个方案,但后来发现对于单张图片的适配极差,因此还是放弃了,第三个实现一个ViewGroup,这个是我曾经想做的,只是判断了一下,感觉花费我的精力会很多,甚至可能影响到了我的工作,于是也就抛弃了。

最后,我采取了继承FlowLayout的方案。

使用FlowLayout的原因有几个:

  1. 我不用关注onLayout的实现
  2. FlowLayout允许我针对控件换行
  3. FlowLayout添加的控件是有序且方向可控

以上是本篇的内容,下一篇将会开始控件的初步搭建。

喜欢 (0)
仿微信聊天软件开发