项目重构的Git地址：
https://github.com/razerdp/FriendCircle
项目同步更新的文集：
http://www.jianshu.com/notebooks/3224048/latest
本文控件Git地址:
https://github.com/razerdp/PhotoContents
上集：欢乐的票圈重构之旅——RecyclerView的头尾布局增加
下集：欢乐的票圈重构——九宫格控件（中上）
ps:票圈重构已经合并到主分支了，大多数功能也在逐步赶上以前的进度，而且以后的提交主要都是往主分支提交的，如果您是在main-dev分支clone的，请切换到master分支。
写在前面：
在重构之前的票圈版本是在大四，也就是我没毕业的时候写的，那时候有着比较充裕的时间，因此更新文章也比较频繁。
而现在参与了工作之后，虽然git的提交没有断，但写文章的频率是越来越低了，不过幸好，大部分知识在重构之前的文章都写过了，所以很多东西都不需要重复描述。
虽然文章写的越来越少，但有一点是不会变的，在下一定会认真地码出每一次的进步-V-
本次自定义控件断断续续码了10天，篇幅较长，因此分为上中下三篇
- 上篇探究微信朋友圈实现和相关的库类，总结思路并给出一个初步的方案。
- 中篇初步搭建控件的基本元素。
- 下篇针对几个着重点进行特别描述。
如果您对这个项目感兴趣或者有什么好的建议，在下非常欢迎您提交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】
得到了单图和多图的布局（顺带提一下：吐槽乐天那张干得漂亮）：
单图
多图
从图上我们初步分析得到几个结果：
- 微信的做法很明显不是通过控制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添加的控件是有序且方向可控
以上是本篇的内容，下一篇将会开始控件的初步搭建。
网友评论