企业官网建设流程全解析

GridView 大概是 Android 原生开发里最容易被低估的一个容器。很多同学觉得它就是个“两列/三列的列表”，RecyclerView 用熟了之后甚至懒得再碰它。但我做过的几个重度网格类项目——比如生鲜电商的商品列表、直播间的礼物墙、带缩放拖拽的工作台——里，真正能把 GridView 用顺手的开发者并不多。标题里写“最佳实践”，我不想堆规则，而是想把那些踩过、优化过、实测过的东西一次说透。这篇内容适合刚接触网格布局的新手，也适合那种“列表已经很流畅但总觉得哪里不对”的进阶开发者。

1. 网格布局到底难在哪：卡顿、错乱与复用的隐形代价

先说一个反直觉的结论：GridView 的卡顿根源，往往不在 draw 和 layout，而在getView 里做的事太多，或者Adapter 的数据组织方式与网格的几何结构不匹配。很多人一上来就抱着“GridView 是上古控件，RecyclerView 才是正道”的偏见，其实 GridView 的 AbsListView 架构在网格场景下有一套自己的脾气，弄懂了以后很多问题都能提前避开。

1.1 测量与布局的特殊性：为什么网格项比线性列表更容易掉帧

线性列表（ListView）的每一项宽度固定，高度可能不同，测量路径相对简单。GridView 则要求你在固定列数或固定列宽之间做选择，这直接决定了子项尺寸的分配方式。

我用过三种列宽设置：

• android:numColumns="3"配合android:columnWidth不指定——列数固定，每一项宽度由 GridView 均分。
• android:columnWidth="100dp"配合android:numColumns="auto_fit"——宽度固定，列数根据屏幕宽度自动计算。
• 纯 Java 代码里通过setNumColumns动态改列数。

实际项目里最常用的是第一种，因为 UI 设计师给的稿子通常有明确的列数要求。但均分宽度有个坑：Grid 的均分算法在竖屏、横屏、平板上的表现并不一样。它用的是列数 + 1的除法机制（考虑 stretch mode），在stretchMode="columnWidth"时还会尝试把剩余空间按列宽拉伸。如果你给子项设置了复杂的权重或者依赖父容器宽度做自适应，测量阶段就会多做不少计算。

提示：在 Adapter 的getView里做任何涉及ViewGroup.LayoutParams的调整，都会触发一次 requestLayout，而请求布局在网格滚动中会和你手指的滑动帧竞争 UI 线程资源。最佳做法是让 GridView 的列宽、间距、拉伸模式在 XML 或初始化时定死，运行时不要去改。

1.2 复用机制的双刃剑：ConvertView 复用为什么还会闪

很多人以为 GridView 卡顿是“复用没写好”，但实际我看到更多的是：复用写了，但复用得不对。

getView的标准写法确实是这样：

@Override public View getView(int position, View convertView, ViewGroup parent) { ViewHolder holder; if (convertView == null) { convertView = mInflater.inflate(R.layout.item_grid, parent, false); holder = new ViewHolder(convertView); convertView.setTag(holder); } else { holder = (ViewHolder) convertView.getTag(); } holder.bind(mData.get(position)); return convertView; }

这是对的，但不完整。网格滚动的时候，convertView来自同一个ViewType的回收池。一旦你在这个网格里混入了多种类型的 Item（比如第一个位置是 Banner，后面是普通商品），却没有重写getItemViewType和getViewTypeCount，Android 会默认所有 item 是同一种类型，复用逻辑就会把不同布局的 View 交给你，你直接强转 ViewHolder 就会 ClassCastException，或者你做了类型判断但 View 里的内容残留，就会出现“图片闪一下再变正确”的错乱。

问题更隐蔽的地方在于：图片加载是异步的。网格项被回收后，旧的图片加载回调可能在新位置执行，ImageView 显示的图就错了。这不是 GridView 的错，是你没有做请求取消或占位校验。我用 Glide 时习惯给每个 ImageView 设置独立的 requestKey，或者利用Glide.with(context).load(url).into(imageView)时 Glide 自己会处理生命周期和复用，但如果你用的图片框架不支持自动取消，就必须在ViewHolder.bind里先清空 ImageView 的 tag 再加载。

public void bind(Product product) { mName.setText(product.name); // 关键：防止异步加载错位 mImage.setTag(product.id); loadImage(product.imageUrl, mImage, product.id); }

加载回调里校验一下 tag 和当前 ImageView 的 tag 是否一致，不一致直接不渲染。这个操作能把网格滑动时的“图片乱跳”问题彻底解决。

2. 数据组织与刷新策略：别再用 notifyDataSetChanged 挑战性能

网格场景下，数据源的组织方式直接决定刷新成本。线性列表你更新一个字段只需要 notify 一行，但网格里一个位置的数据变化，往往牵扯到整行、整列的尺寸和内容联动。

2.1 网格刷新的三个常见场景与推荐做法

我把日常开发里 GridView 刷新的场景分成三类，分别有不同的处理方式。

第一类是全量刷新：比如下拉刷新获取了全新数据。这种场景用notifyDataSetChanged()没问题，但前提是你把新旧数据的差异先处理好。比如旧数据有 100 条，新数据只有 80 条，直接 set 新 List 再 notify，网格的高度会在瞬间变化，尤其是你在 GridView 外面套了一层 ScrollView 做嵌套滚动时，会出现跳动。我通常的做法是：先保持 GridView 的 layoutParams 高度不变，等布局稳定后再更新数据。

第二类是单条或局部更新：比如购物车页改某个商品数量、直播间礼物列表新增一个礼物特效帧。这种场景不要让整个网格重绘。可以用getChildAt(index)拿到当前可见的 item 直接更新，或者更优雅的是记录 position，手动刷新：

public void updateItem(int position, Product newData) { mData.set(position, newData); // 只更新可见范围内的项 int first = mGridView.getFirstVisiblePosition(); int last = mGridView.getLastVisiblePosition(); if (position >= first && position <= last) { View item = mGridView.getChildAt(position - first); if (item != null) { ViewHolder holder = (ViewHolder) item.getTag(); holder.bind(newData); } } }

这个方案的好处是避开了 notify 带来的全局 measure/layout。但注意：如果你的 item 高度是 wrap_content 且内容长度会变化（比如文本行数变化），局部更新会导致网格项高度不一致，视觉上会“顶开”或“缩紧”其他项。解决思路是给网格项固定高度，或者用notifyDataSetChanged让它整体重新布局。

第三类是插入和删除：商品列表加载更多、删除某个收藏。GridView 没有 RecyclerView 那种notifyItemInserted的动画 API，它的常规做法是全量刷新。这里有个体验优化的小技巧：插入数据时，先把新数据追加到 List，再 notify，同时调用setSelection(position)让网格停在插入位置附近。删除时同理，先删除再 notify，视觉上虽然没动画，但不会跳回顶部。

2.2 DiffUtil 与网格的结合：复杂的更新也能降复杂度

如果你的项目已经切到 RecyclerView.GridLayoutManager（算是 GridView 的进阶形态），那 DiffUtil 是标配。但如果你因为历史包袱必须用 GridView，也可以用 DiffUtil 产出的差异结果手动刷新。

DiffUtil.calculateDiff(oldList, newList, true)返回的DiffResult，可以拿到getChangePayload(position)这种信息。对着 GridView，我写过一套轻量封装：

DiffUtil.DiffResult diffResult = DiffUtil.calculateDiff(new ProductDiffCallback(oldList, newList), true); List<Product> newData = new ArrayList<>(newList); mData.clear(); mData.addAll(newData); diffResult.dispatchUpdatesTo(new GridViewListUpdateCallback(mGridView, mAdapter));

GridViewListUpdateCallback会回调onChanged(position, payload)、onInserted(position, count)。在里面用第一节提到的getChildAt+ ViewHolder 的方式精确定位刷新，能让大数据量下的网格更新从几百毫秒降到几毫秒。DiffUtil 的计算本身在大列表（1000+）时也会耗时，建议放子线程。

实操心得：DiffUtil 不是银弹。如果你的数据列表只有二三十条，直接notifyDataSetChanged反而更快。我做性能对比时测过：50 条以内，DiffUtil 的差集计算时间占优不明显，但因为避免了全量重绘，滑动到当前位置的帧率体验仍然更好。核心取舍在于你的 item 布局复杂度——item 布局越重，局部更新收益越大。

3. 网格的尺寸、间距与适配：每个像素都要有说法

网格布局最花时间的地方，其实是“看起来没什么技术含量”的尺寸计算。列数对了，间距不对；间距对了，最后一列又贴边；横竖屏切换后，间距比例又不对劲。这些都是网格开发里的常态。

3.1 间距与分隔线的计算：加还是不加、在哪加

GridView 里的horizontalSpacing和verticalSpacing只控制网格项之间的间隔，不控制网格与 GridView 边缘的 padding。这意味着你如果想要“网格两侧和屏幕边缘有留白，中间间距均匀”的效果，需要自己算。

常见的错误做法是直接把horizontalSpacing设为目标间距，然后给 GridView 设置一个 padding。比如目标效果是：屏幕左右边距 16dp，item 之间的间距也是 16dp。如果只设horizontalSpacing="16dp"加paddingLeft="16dp"paddingRight="16dp"，最后视觉效果是两边 16dp、中间也是 16dp，看起来还行。但如果设计师要求的是“边距 16dp，中间间距 12dp”，你就要手动算列宽。

我常用的公式是这样：假设 GridView 宽度 W，左右 padding 各 P，列数 N，水平间距 S，那么每个 item 宽度 = (W - 2P - (N - 1) * S) / N。

如果你用纯 XML 写死 dp 值，在平板这种宽屏设备上会有问题——item 可能被拉得很宽，图片变形。所以我建议用代码动态设置：

int spanCount = 3; float spacing = dp(12); float padding = dp(16); int gridWidth = getAvailableWidth(); int itemWidth = (int) ((gridWidth - 2 * padding - (spanCount - 1) * spacing) / spanCount);

然后把 itemWidth 传给你的 ViewHolder，用固定宽度渲染。

对于 Grid 的 XML 写法，stretchMode值得单独说。它有三个值：none、columnWidth、spacingWidth。columnWidth模式下，GridView 会尝试把列宽按比例拉伸以填满空间；spacingWidth模式则优先拉伸间距。如果你在代码里已经精确设置了 itemWidth，XML 里再设置stretchMode="columnWidth"会覆盖你的计算，导致实际效果和预期偏差。这一点非常隐蔽，我见过有人写好了 dp 宽度，结果在真机上 item 间距莫名其妙变大的情况，最后发现是stretchMode在作祟。

注意：columnWidth在没有设置numColumns时很有用，但一旦你同时设置numColumns和stretchMode="columnWidth"，GridView 可能会根据可拉伸空间重新计算子项宽度，使你的精确宽度失效。生产环境里，要么靠 XML 的自动计算，要么靠代码精确控制，不要两套混用。

3.2 横竖屏与折叠屏适配：网格项尺寸的响应式策略

折叠屏和分屏模式在网格场景下最容易出问题，因为可用宽度变化极大。竖屏时 3 列合适，展开后 3 列会让每个 item 太宽，图片被放大后显得粗糙；但如果因为横竖屏切换而改变列数，用户看到的网格疏密变化又可能影响操作习惯。

我的策略是“按宽度区间决定列数”，比如：

用一个GridConfig工具类来管理这些值，在onConfigurationChanged里重新计算并notifyDataSetChanged。

还要注意图片资源的加载尺寸：如果你在后端配置了图片 CDN 的裁剪参数，最好根据 item 的实际渲染宽度请求对应尺寸的图片，避免在平板上加载手机尺寸的低清图又在大屏上放大模糊，也避免明明只显示小图却加载了高清大图造成内存浪费。我曾在一个项目里统计过：同样的商品网格，用窄屏图片规格在平板上渲染，内存占用比适屏图片规格高大约 2.3 倍，而视觉效果并没变好。

4. 嵌套滚动与多状态网格：GridView 在复杂页面里的协作能力

真实项目里 GridView 很少单独存在。它通常被塞进 ScrollView、配合顶部轮播图、底部加载更多、空视图、错误视图一起出现。这部分的坑比 GridView 本身多得多。

4.1 嵌套滚动冲突：GridView 在 ScrollView 里的处理方案

当 GridView 嵌在 ScrollView 里时，默认情况是 ScrollView 拦截了垂直滑动事件，GridView 自己的滚动不会发生。如果网格数据很多，直接整个 GridView 展开会让界面卡顿——因为所有 item 全部创建了，复用机制失效。这是很多新手都会踩的坑。

主流方案有两个：

方案 A（推荐）：外层用NestedScrollView+RecyclerView.GridLayoutManager，并设置recyclerView.setNestedScrollingEnabled(false)。这不是 GridView 控件，但如果你控制不了它，就换个思路。这种方法本质是让 GridView 退化为全量渲染，不推荐在 item 数量大时使用，但如果你内部 item 数量固定且少（比如控制在 20 个以内），展开渲染也没问题。

方案 B：保持 GridView 自带的滚动，而不是整个页面滚动。把 GridView 高度固定为屏幕剩余空间的高度，让 GridView 负责滚动，顶部轮播图等固定在外面。这样体验最流畅，也符合移动端“局部滚动”的交互习惯。

还有一种折中：GridView 的 item 数量不定且可能很多，但页面还想整体滚动。这种情况下，我建议不要用 GridView，改用RecyclerView的GridLayoutManager配合多类型 item，让轮播和网格在同一个 RecyclerView 里。虽然不是本篇的主角，但从工程治理角度看，这是“网格在复杂页面里协作”的最优解。

4.2 空视图、加载视图和错误视图：网格页面的状态切换

GridView 本身有setEmptyView方法，这是我认为它比“裸写 RecyclerView”更好用的地方之一。ListView家族的老控件天生支持空视图切换，而 RecyclerView 需要自己写 Adapter 里的类型处理。

我的状态管理套路：

View emptyView = findViewById(R.id.empty_view); mGridView.setEmptyView(emptyView);

这个方法的隐藏逻辑是：Adapter 数据为空时，GridView 自动显示 emptyView；数据不为空时自动隐藏。如果业务上有加载中、加载失败两种附加状态，我会在 emptyView 里塞一个ViewSwitcher，根据状态切换加载动画、错误提示、空内容提示。

这里有个细节：setEmptyView是注册在 GridView 内部的Observer上的，如果你在 Adapter 里调用了notifyDataSetChanged，它会自动判断是否显示空视图。但如果你把数据清空后没有 notify，空视图就不会出现。所以状态的切换顺序永远是：改数据 → 通知刷新 → 更新 UI 状态。

4.3 网格项里的复杂交互：点击、长按、多选与动态增减

网格项通常包含图片、价格、按钮等元素，点击区域容易因为 item 之间的间距产生误触。我建议在 Adapter 里统一处理点击事件，用接口回调到 Activity/Fragment，而不是在每个 item 里直接写 setOnClickListener 绑业务逻辑。

public interface OnProductClickListener { void onProductClick(Product product, int position); void onLikeClick(Product product, int position); void onLongPress(Product product, int position); }

然后在 ViewHolder 构造函数里注册点击事件，通过getAdapterPosition()拿到当前位置。注意：因为 GridView 增加了 header 的话，getAdapterPosition()不会帮你排除 header offset，需要手动减掉 headerViewCount，这是我踩过一次的坑。

多选模式则建议用ChoiceMode或自己维护 selected 集合，用局部刷新来更新选中态。网格项的状态多（默认、按压、选中、禁用）容易累积成绘图压力，用 ColorStateList 和 Selector 资源能省下不少重复绘制。

5. 从卡顿到流畅：一场网格页面的性能调优实测

说一千道一万，网格合不合格要看实测数据。下面是我在一个模拟电商首页（顶部轮播 + 3 列网格，约 300 个商品）里做埋点优化时的实测记录，数据来自某测试设备（配置算中端），供参考。

5.1 调优前的性能基线

主要问题集中在三处：

1. item 布局嵌套深，有 5 层，每条 item 测量耗时高；
2. 图片加载尺寸过大，GridView item 显示区域只有 240dp 宽，却加载了 1080px 的图片；
3. 快速滑动时每次getView都创建新的 circle drawable 作为价格背景，导致短生命周期对象暴增，触发频繁 GC。

5.2 调优措施与效果

第一，拍平 item 布局。把原来用来做阴影的深嵌套FrameLayout+LinearLayout改成ConstraintLayout，层级从 5 层降到 2 层。这一步对测量耗时影响最大，因为 GridView 的复用机制里，新建 View 的 inflate 成本只发生在数量有限的时候，但每次的 measure/layout 却会伴随 item 入屏过程。

第二，按需加载图片尺寸。用图片加载库的 resize 能力，把网格图片统一裁剪为 400px * 400px（对应 200dp * 200dp 的 item 显示区域，按 2x 分辨率计算），内存占用立竿见影地下降。

第三，对象复用。价格标签背景改成 XML drawable，而不是每次 getView 都 new 一个 GradientDrawable；价格文本用TextView的 compoundDrawable 或 background 替代动态创建。

调优后的数据：

整体体验从“能滑但有点黏”变成了“顺手就滑”。这组数据不一定适用于所有项目，但调优方向是一致的：先减层级，再减图片，最后消除短生命周期对象。

5.3 性能调优的工具与指标解读

网格滑动流畅度的衡量，光看 FPS 不够，建议同时关注丢帧间隔和 UI 线程占用。我用过的工具组合是：Systrace 看测量、布局、绘制的耗时区间；CPU Profiler 观察 Java 层方法耗时；Memory Profiler 看 Allocations 里是不是有大量短生命周期对象不断创建。

如果你无法跑大型性能工具，Android Studio 自带的Inspect Code和Layout Inspector也能快速定位明显的层级过深问题。还有一个土办法：在getView里插入Log.d打印每次创建的耗时（生产环境记得关掉），对比不同位置的 item 创建耗时波动，基本能定位到是不是有 item 做了额外操作。

实测心得：很多网格卡顿跟 GridView 本身关系不大，而是因为 item 里的自定义 View 在 onDraw 里做了耗时操作，比如画阴影、画圆角、画渐变。如果只是静态样式，优先用 shape drawable，让 Android 的渲染管线去优化，而不是你每次调用canvas.drawXXX全量绘制。

6. 那些没人告诉你但很重要的细节：从适配到异常兜底

现在我挑几个生产环境里一定会遇到的细节问题，每个都是真实项目里需要做的动作，不是纸上谈兵。

6.1 网格项的点击反馈与无障碍支持

网格项默认没有 ripple 效果，因为 GridView 的默认 item selector 是透明的。你需要给 item 根布局设置：

android:background="?attr/selectableItemBackground"

这样 Android 5.0 以上会有水波纹效果，5.0 以下自动降级为普通的按压色。这个操作对体验的提升非常明显，特别是商品类网格，用户点下去没有反馈，会觉得交互很“死”。

无障碍支持在国内可能优先级不高，但如果你做海外市场或政务类项目，需要确保GridView的 item 可以被 TalkBack 正确读取。关键点：

• item 的 contentDescription 不要设置在根布局上，而是设置给重要的按钮或图片；
• 自定义 View 需要onInitializeAccessibilityNodeInfo暴露点击语义；
• 不要用setImportantForAccessibility批量隐藏整个网格，否则读屏会把所有 item 当作一个整体。

6.2 异常数据与占位兜底：网格比列表更怕“脏数据”

列表模式的数据异常最多就是显示错误，但网格里一个 item 异常可能会导致整行列布局错位。比如图片地址为空时，如果加载库返回错误，你最好有个占位图，否则 ImageView 撑不起来，item 高度塌了，后面的行会补上来，形成整体跳动。

我的兜底策略：

1. 数据层过滤：后端返回的数据在进 Adapter 前，先做合法性检查，脏数据统一用默认对象填充或者标记隐藏；
2. 渲染层兜底：onBindViewHolder里对所有文本设置默认值，所有 ImageView 先设占位图；
3. 布局层兜底：item 根布局固定宽高或最小高度。

网格布局最怕的是 item 高度不统一导致的对不齐。如果你必须允许高度自适应（比如文本有 2 行或 3 行两种情况），可以考虑用StaggeredGridLayoutManager，那是瀑布流布局的管理器，不属于 GridView，但它能更好地处理高度不一致时的视觉分布。但注意瀑布流和网格的视觉逻辑完全不同，网格强调行列对齐，瀑布流强调卡片错落，不要混用。

6.3 内存优化：网格页面的图片缓存与回收

网格是图片密集型页面，内存治理话题绕不开。图片加载库虽然替你做了缓存，但有两件事它不管：第一是数据源本身持有的大尺寸 Bitmap；第二是 item 被移除后 Bitmap 是否被正确回收。

如果你的 Adapter 数据里直接持有了 Bitmap 引用，那么即使 GridView 不显示这些 item，Bitmap 仍然占用内存。最佳实践是数据层只持有图片 URL，用图片框架管理 Bitmap 生命周期；如果业务上必须持有 Bitmap，则在 Adapter 被销毁或数据更新时，手动recycle()不再使用的 Bitmap（仅限于你已经确认没有其他地方引用的情况）。

此外，GridView滚动时图片请求频率高，最好设置图片加载的磁盘缓存策略为“先内存后磁盘”，同时控制同一时刻的并发请求数。我之前在一个图片框架默认并发 4 的配置下，快滑时图片加载总是滞后；调成 8 之后明显改善，但内存抖动也变多。最终用了“按 GridView 滑动状态调整加载优先级”的思路：静止时高优先级加载当前屏，快速滑动时只加载首尾可见区域的图片，其余等滑动停止后再补。

mGridView.setOnScrollListener(new AbsListView.OnScrollListener() { @Override public void onScrollStateChanged(AbsListView view, int scrollState) { if (scrollState == SCROLL_STATE_IDLE) { // 停止滑动，开始加载所有可见项图片 imageLoader.resume(); } else { // 滑动时，先暂停低优先级图片请求 imageLoader.pause(); } } });

这个优化在低端机上效果尤其明显，滑动时的掉帧从肉眼可感变成基本无感。

6.4 封装一个可复用的 GridView 工具类

第 3 部分的间距计算、第 5 部分的调优经验，如果每次都复制粘贴到页面里，很容易改一漏十。我建议把这套逻辑封装成一个工具类，比如叫GridAutoSize（模拟命名），负责：

• 根据列数和目标间距计算 item 宽度；
• 计算 GridView 的 padding 与 spacing；
• 在横竖屏切换时自动重新计算；
• 提供动态设置列数的接口。

封装之后，业务方只需要传入列数、边距、间距和屏幕宽度，就能拿到正确的 LayoutParams。这个类在我的好几个项目里都直接复用，节省了大量时间，也统一了网格布局的标准。

写完这些，回头看发现“GridView 最佳实践”这个词看起来基础，但深挖下来可以牵扯到测量、复用、状态切换、性能调优、异常兜底等多个维度。我最后分享一个个人习惯：每到一个新项目，看到 GridView 的使用，我都会先问三个问题——这个数据量级是多少？item 布局复杂吗？Grid 外面还有没有嵌套滚动？这三个问题的答案，基本决定了你的网格这次是稳还是要折腾。