先说个场景。某项目里产品丢过来一个需求Android 左右竖直滚动的Table要像 Excel 一样横着能滑、竖着也能滑顶部表头还得固定不动。网上搜了一圈要么是第三方库太重要么是示例代码只能跑个 demo一接真实数据就各种错位、卡顿、表头跑偏。这是系列第二篇。第一篇我们把最基础的 TableLayout 嵌套方案跑通了这篇主要说清楚双方向滚动到底该怎么拆层级、表头固定用什么思路最省事、同步滚动有哪些坑、以及为什么有些地方必须那样设计。文章里没有特别高深的东西但每一条都是我实际改过 bug 之后才总结出来的希望能帮正在做类似需求的人少走弯路。1. 这个需求到底难在哪先把双方向滚动的三种方案过一遍1.1 初步方案与它们各自的硬伤做表格之前我在同事中间问了一圈发现大家第一反应基本都是这三个方向。方案一ScrollView 嵌套 HorizontalScrollView 嵌套 TableLayout。这是最常见也最容易上手的做法优点是结构直白、每个单元格就是一个 View后期想加点击事件、长按事件都很方便。缺点是层级一多容易出事件冲突数据量大时 draw 阶段会明显变卡。方案二用多个 RecyclerView 模拟表格。外层一行是一个 RecyclerView每个 item 里放多个 TextView横向滚动交给 item 横向排列。这个方案在数据量特别大的时候性能有优势但列对齐是个非常麻烦的问题——不同 item 的 View 测量时机不同任何一个 item 里文字换行、字号变了宽度就会偏最后整个表都歪掉。我见过有人用 GridLayoutManager 的 spanCount 做但列宽控制仍然有限。方案三直接自绘 Canvas。这个方案自由度最高性能也最好适合做复杂报表、需要合并单元格的场景。但自绘意味着触摸命中测试、文字测量、滚动边界全部要自己算开发周期会成倍拉长。小团队做业务需求通常不值得一上来就选这个路。我在项目里选的是方案一也就是在 TableLayout 这套基础结构上继续深挖原因很简单需求里的数据量短期不会超过几百行表头固定和双方向滚动是硬需求但合并单元格、复杂样式不存在用 View 层级实现最稳也最好交接给后来维护的人。1.2 固定表头与固定首列的取舍很多需求文档里会写“表头固定、首列固定”但实际做的时候我建议先跟产品确认第一列是不是真的必须固定固定表头要做的是把表头放到一个独立的横向容器里跟内容区域共用同一个水平滚动事件源这个难度不算高。固定首列就麻烦很多因为首列需要跟着内容区域上下滚动又要在水平滚动时保持不动这意味着必须有一个独立的纵向滚动容器去同步内容区域的高度滚动。两个方向都有同步关系事件冲突和测量误差都会翻倍。我们最后给产品的方案是表头固定首列不固定首列在横向滚动时跟着滑出屏幕。如果用户看某一行的数据是可以靠行号字段定位的。如果后续真的需要首列固定我再考虑把第一列抽到最外层单独做一个纵向 ScrollView同时监听内容区域的 scrollY。所以在动手写代码之前先把这个取舍谈清楚能帮你省掉一整块工作量。2. 我把层级结构重新拆了一遍横向谁负责、纵向谁负责2.1 核心层级两个外层横向容器加一个内层纵向容器这类表格最容易犯错的地方是所有人把 ScrollView 和 HorizontalScrollView 随便往 XML 里一放能用就行。等需要加表头固定的时候才发现不知道应该把表头放在哪里。我最后定下来的结构是这样的最外层是一个垂直方向的 LinearLayout分成两个区域表头区域和内容区域。表头区域一个 HorizontalScrollView里面装一行表头单元格。内容区域另一个 HorizontalScrollView里面放一个垂直方向的 ScrollView垂直 ScrollView 内部再放一个横向的 LinearLayout每一列是一个垂直的 LinearLayout所有列的宽度保持一致。这样拆之后职责很清楚横向滚动统一由两个 HorizontalScrollView 负责一上一下纵向滚动只发生在内容区域的内层 ScrollView表头区域跟纵向滚动天然无关因为它在垂直 ScrollView 的外面。同步要做的事情只剩一件让表头的横向滚动位置跟着内容区域的横向滚动位置走。用代码描述大概是这样// 表头水平滚动容器 HorizontalScrollView headerScroll findViewById(R.id.header_scroll); // 内容水平滚动容器 HorizontalScrollView contentScroll findViewById(R.id.content_scroll); // 内容水平滚动的内部垂直容器 ScrollView verticalScroll findViewById(R.id.vertical_scroll); // 垂直容器内部存放多列数据的横向布局 LinearLayout tableBody findViewById(R.id.table_body);当我要给表格填充数据时只需要往tableBody里按列添加数据行不需要动表头区域表头区域只负责那一条固定的标题行。这样的设计把“数据渲染”和“滚动同步”解耦了后面的局部刷新也更好做。2.2 列宽统一与字体缩放导致的“错列”问题列宽不一致是这个方案里出现频率最高的 bug。很多人写 Item 的宽度时会用wrap_content表面上看起来没问题但一旦某列的文字长度变化整列宽度就被撑开了其他列跟着被挤压表格就对不齐了。我的做法是给每一列一个固定宽度用 dp 值在代码里统一设置int[] columnWidths { 100, 140, 180, 120, 160 }; // 单位 dp for (int i 0; i columnWidths.length; i) { LinearLayout column createColumn(); int width (int) (columnWidths[i] * getResources().getDisplayMetrics().density); LinearLayout.LayoutParams params new LinearLayout.LayoutParams( width, ViewGroup.LayoutParams.WRAP_CONTENT); column.setLayoutParams(params); tableBody.addView(column); }这样写还有个好处就是当表头需要跟内容列对齐时表头单元格也用同一个 dp 宽度两边就一定会对齐。一个容易忽略的坑是字体缩放如果用户把系统字体调到了最大wrap_content的单元格会随着文字变大而变宽但固定 dp 宽度的列不会于是会出现表头对齐、内容文字被截断的情况。解决的办法是对关键列表格里的文字设置固定字号或者干脆用dp来设置文字大小避免用户侧字体缩放影响布局测量。2.3 一个用来快速验证对齐的小方法实际开发时我习惯在表格填充完之后临时给每一列设置一个不同的背景色或者给表头加个醒目边框在不同屏幕尺寸的模拟设备上看一遍。这个方法花不了五分钟但能快速暴露错位问题。真正踩过坑之后你会记住列宽设计必须从表头到数据全部统一不能一部分用权重、一部分用 wrap_content、一部分写死 dp。混用测量单位的后果就是在预览里看着好好的真机上一换字体或一换分辨率整张表直接没法看。3. 表头固定和双 ScrollView 同步一个 onScrollChanged 就能搞定但坑不少3.1 同步代码与防抖保护表头固定的核心就是把两个横向容器绑在一起。最直接的做法是监听内容区 HorizontalScrollView 的滚动事件然后把表头容器同步滚到同样的水平位置。代码很简单contentScroll.setOnScrollChangeListener(new View.OnScrollChangeListener() { Override public void onScrollChange(View v, int scrollX, int scrollY, int oldScrollX, int oldScrollY) { if (headerScroll.getScrollX() ! scrollX) { headerScroll.scrollTo(scrollX, 0); } } });这个 if 判断很关键。scrollTo本身会再次触发滚动监听如果不加判断就有可能出现两个容器互相通知、无限递归的情况。虽然 Android 的滚动回调不一定会立刻再次触发但在快速滑动、边界回弹的边缘场景下不带保护的同步经常会导致视觉抖动表现为表头比内容“慢半拍”或者“晃一下”。还有另一种更稳妥的做法在同步之前先把监听器临时摘掉同步完再装回去。代码比 if 判断长一点但能彻底避免自己通知自己的问题。contentScroll.setOnScrollChangeListener(null); headerScroll.scrollTo(scrollX, 0); contentScroll.setOnScrollChangeListener(listener);实际项目中我推荐把监听器单独抽成一个字段方便在复用列表项时统一管理。3.2 为什么同步频率高会产生肉眼可见的抖动onScrollChange在快速滚动时会被频繁触发这不是问题问题是两个容器的滚动位置在任何一帧里都可能暂时不一致。比如用户猛地一滑内容区已经滚了 300 像素但表头区同一帧只滚到 250下一帧又追到 300。如果刷新率正好卡在视觉敏感区间用户就会觉得表头在“抖”。解决思路有两个。一是把同步回调尽量放到绘制之前利用Choreographer的回调机制做节流让同一帧内只执行一次同步。二是把两个 HorizontalScrollView 换成同一个自定义容器自己管理一块画布表头固定和内容固定都通过位移计算完成不过这属于进阶改造代码量增加不少。对于第一版需求我建议先做好第一点不要在滚动监听的每一帧里都执行多余逻辑尤其是不要在里面做布局更新或 View 重建。滚动监听里只做scrollTo其他一切操作全部移出去。3.3 表头阴影和置顶层级表头固定在顶部之后内容区域向上滚动时数据行会从表头下方“穿过去”。如果表头本身没有不透明背景或者层级不够高视觉上就会很乱。给表头设置一个不透明背景同时加上一点 elevationHorizontalScrollView android:idid/header_scroll android:background#FFFFFF android:elevation4dp /HorizontalScrollView这个 elevation 不是用来做花哨阴影的是为了让表头在 Z 轴层级上高于内容区滚动时不会出现内容覆盖表头的情况。部分国产 ROM 对 elevation 的渲染有兼容差异保险起见也可以把表头单独包在一个 FrameLayout 里用画分割线的方式做视觉分隔效果更稳定。4. 测量、绘制、缓存三层隐患让表格卡到没法用4.1 数据量不大但滑动卡顿的真相有个项目里表格一共也就两百行滑动起来却明显掉帧。当时第一反应是数据填充方式有问题后来用工具一看过度绘制才发现单个单元格里叠了多层背景整个页面一帧要画好几遍。TableLayout 这套方案里每个单元格都是一个 ViewTableRow 本身也是 ViewScrollView 的 content 又是 View。如果每一层都设背景色重叠区域就会被反复绘制。加上 Android 默认没有开启硬件加速的某些绘制路径一屏显示三十行、每行十列就是三百个 View绘制时间自然就上去了。在做类似表格时我先列三条规则不随便给 ScrollView、HorizontalScrollView 设置背景背景统一放在最内层的单元格上。单元格的背景尽量用同一个 drawable 复用不每个 View new 一个。行与行之间的分割线不要用 margin更不要用多个 View 叠加用 shape 的 stroke 或者用统一的 divider 高度代替。4.2 减少过度绘制的具体手段分割线方案统一先说一下我最后确定的分割线方案。每一行底部用一条 1dp 的细线每一列右侧也用一条 1dp 的细线。这些分割线全部作为单元格内部的子 View 来管理不额外包一层容器。private View createDivider(int width, int height) { View divider new View(context); divider.setBackgroundColor(Color.parseColor(#E0E0E0)); divider.setLayoutParams(new ViewGroup.LayoutParams(width, height)); return divider; }在往列容器里添加数据单元格时每个单元格底部追加一条高度为 1dp 的分割线每个单元格右侧追加一条宽度为 1dp 的分割线。这样整张表的分割线天然对齐不会出现两条线“重叠加粗”或“断档”的情况。这种做法的好处是把绘制的复杂度限制在了每个单元格自身不依赖父容器去计算交错位置。坏处是单元格子 View 数量会变多所以分割线一定要用最简单的 View 而不是带背景图的控件。4.3 滑动缓存与硬件加速的设置如果卡顿仍然明显可以试试给滚动容器开启缓存contentScroll.setDrawingCacheEnabled(true); contentScroll.setPersistentDrawingCache(ViewGroup.PERSISTENT_SCROLLING_CACHE);这个只推荐用在外层容器不要用在每个单元格上。全开只会让内存暴涨滑动结束后还要手动清缓存。硬件加速同理不要让整个 Activity 或者整页开启硬件层而是只针对内容滚动区域设置verticalScroll.setLayerType(View.LAYER_TYPE_HARDWARE, null);需要特别提醒一句如果表格里频繁更新文字内容开启硬件层反而会导致更新时重新合成层掉帧更严重。所以这个设置要配合实际场景去调不是无脑加上就完事。4.4 一次性渲染和分批加载的策略我给自己定了一个线超过 500 行就不太适合继续用纯 TableLayout 方案了至少需要加“加载更多”或者分页。500 以内一次性渲染问题不大但也要避免在滚动监听力里面做addView操作。如果你还不知道怎么判断该不该分页我建议这样先把数据全量渲染一遍看首屏时间。如果首屏超过 500ms或者滑动时明显掉帧就改成每屏只渲染可见区域用预加载边界控制提前量。等数据规模上万那真的还是切到 RecyclerView 或自绘方案更合适。5. 实测中必须处理的事件冲突横滑还是竖滑谁来拍板5.1 事件冲突的表象嵌套 ScrollView 和 HorizontalScrollView 之后最常见的现象是水平滑动困难。用户明明想横向划到最后几列手指稍微带一点竖直方向的移动事件就被垂直 ScrollView 抢走了。这个问题的本质是父容器和子容器都认为自己应该处理这次滑动。Android 的事件分发默认先给子 View子 View 不消费才轮到父 View但 ScrollView 在 onInterceptTouchEvent 里会自己判断滑动方向一旦确定是竖直方向就直接拦截。5.2 用 dispatchTouchEvent 做的事件搬运我在项目里解决这个问题的思路是在内容区域的 HorizontalScrollView 里重写事件判断让水平方向的位移量大于竖直方向时主动请求垂直 ScrollView 不要拦截这次事件。public class TableHorizontalScrollView extends HorizontalScrollView { private float downX, downY; public TableHorizontalScrollView(Context context) { super(context); } Override public boolean onInterceptTouchEvent(MotionEvent ev) { switch (ev.getActionMasked()) { case MotionEvent.ACTION_DOWN: downX ev.getX(); downY ev.getY(); break; case MotionEvent.ACTION_MOVE: float dx Math.abs(ev.getX() - downX); float dy Math.abs(ev.getY() - downY); if (dx dy) { // 肯定是横向滑动阻止父容器垂直ScrollView拦截 getParent().requestDisallowInterceptTouchEvent(true); } break; } return super.onInterceptTouchEvent(ev); } }这个代码的思路是在手指移动时判断位移方向。如果横向位移占主导就告诉父容器不要拦。如果纵向占主导就让父容器正常处理。实际用下来横滑和竖滑都能得到比较自然的响应不会出现方向锁死的情况。5.3 边界回弹与边缘效果的关闭建议嵌套滚动还有一个常见的视觉 bug已经到了最右侧手指继续往右拖会出现发虚光的边缘效果或者两个容器同时回弹。很多详情页用不着这种弹性效果建议直接关掉android:overScrollModenever同样的属性也设置在垂直 ScrollView 上。这样用户在表格区域里滑动时手感和普通的平面内容一致不会被边缘回弹干扰判断。还有一个细节内容区域的 HorizontalScrollView 最好设置clipToPadding为 false并且去掉左右 padding否则横向滚动时内容会被裁剪掉一块看起来像“表格被切了”。我当时排查过半天最后发现是父容器默认裁剪导致的。6. 数据更新与局部刷新做表格最容易忽略的一环6.1 全量刷新的代价项目做测试的时候我用的刷新方式是每次数据变化清空tableBody里所有 View重新走一遍填充逻辑。一开始觉得简单粗暴没毛病后来发现用户频繁切换筛选条件时整个表格会白屏闪一下严重的时候还会感觉“跳了一下”因为重新构建几百个 View 的时间谁都不能忽略。这个问题的根源是全量removeAllViews加addView对视图树来说就是一次重建。哪怕数据只有十个字段变了其他几十列原样没动也要全部重新 measure 一遍。6.2 局部更新接口设计后面我封装了一个简单的刷新入口思路跟 RecyclerView 的notifyItemChanged一样只不过实现方式更轻量。接口大概是这样public void updateCell(int row, int column, String text) { View rowContainer tableBody.getChildAt(row); if (rowContainer instanceof LinearLayout) { View cell ((LinearLayout) rowContainer).getChildAt(column); if (cell instanceof TextView) { ((TextView) cell).setText(text); } } }这里有个前提每一行的结构必须完全一致有多少列、每个单元格的宽度、字体大小都要统一否则 getChildAt 的索引就乱了。这么做之后单格更新的开销非常小只会触发该 View 的重新绘制不会影响整张表。6.3 数据变化时保持滚动位置的技巧局部更新还有一个好处就是不会重置滚动偏移。如果是全量刷新ScrollView 在新内容加入后常常会把 scrollY 归零用户本来在第五十行一刷新直接回到第一行体验非常割裂。如果是局部刷新滚动位置天然保留如果某些场景必须重建数据记得在重建前先保存滚动偏移填充完成后再恢复int scrollY verticalScroll.getScrollY(); int scrollX contentScroll.getScrollX(); // 重建数据... verticalScroll.scrollTo(0, scrollY); contentScroll.scrollTo(scrollX, 0);这里要特别注意的是scrollTo要在新数据 measure 完成之后才生效。如果数据高度变化较大恢复的偏移可能不准。稳妥的做法是用post把恢复操作放到下一帧执行。7. 一些个人体会和后续扩展方向这套方案做下来我的最大感受是Android 左右竖直滚动的 Table难点从来不在于某个单一控件而在于把所有滚动关系理顺。哪个容器负责横向、哪个容器负责纵向、哪个滚动状态是唯一事件源理清楚之后再写代码就顺手很多。如果你现在要动手做我最后的建议是数据量能控制在 500 行以内用 TableLayout 这套组合最省事超过 500 行直接考虑 RecyclerView 加自绘表头。但不管哪种方案表头固定和双方向同步的核心逻辑都是那一句话——把横向滚动抽成单一事件源其他容器只做跟随。这样可以省掉一半以上的同步 bug。后续如果要扩展还能做三件事一是给表头加多功能菜单点击某列表头按该列排序二是长按单元格弹出快捷操作三是把列宽拖动调整做成可配置项。前两个基于现有的 View 体系很好加第三个需要花点时间重新设计触摸逻辑但也不是做不到。希望这篇文章对你有用有踩到其他坑的朋友也欢迎交流。