欢乐的票圈重构——九宫格控件（上）

项目重构的Git地址： github.com/razerdp/Fri…

本文控件Git地址: github.com/razerdp/Pho…

上集：欢乐的票圈重构之旅——RecyclerView的头尾布局增加

下集：欢乐的票圈重构——九宫格控件（中上）

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

写在前面：

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

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

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

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

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

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

预览：

重构之前

如果您有留意过我之前的文章，或者一直跟随着本项目进度的话，您肯定知道，在重构之前的版本里，朋友圈九宫格的实现采取的是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】

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

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

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

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

自定义一个ViewGroup，覆写measure和layout，使其适应1张图和4张图的特殊布局
这个ViewGroup应该还有自己的缓存
- 举个例子，比如在一个AbsListView里面使用，上一个控件有8张图，滑动后即将被复用，复用后的控件有4张图，两者相差4个ImageView。
- 如果这4个ImageView没有缓存而是直接抛弃置空的话，假设我再滑回去，也就是从4个ImageView又变成8个，那么我就要重新new出4个ImageView
- 这明显不是很合理，所以就应该要有个缓存机制，有View的时候直接使用，没有才是new出来（不错，说的就是ListView的方法）

初步方案

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

继承GridView实现
继承GridLayout实现
继承RelativeLayout或者ViewGroup直接实现
继承FlowLayout实现

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

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

使用FlowLayout的原因有几个：

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

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