3.2 核心组件与两端渲染差异
3.2 核心组件与两端渲染差异
本节摘要：核心组件是 RN 提供的标准件——View、Text、Image、ScrollView、FlatList、Modal 等，它们在两端映射为各自的原生控件，因此继承了原生控件的行为差异。本节盘点高频组件的双端脾气，给出 Platform 模块与平台专属文件两种分流机制，并用一张差异速查表与一个阴影统一案例，把「尊重差异还是抹平差异」变成可操作的工程决策。本节是本章枢纽，后面两节的所有示例都会用到这里的分流工具。
别把 Text 只当文字标签
先从最容易轻敌的组件说起。Text 看起来人畜无害，但它是差异密度最高的核心组件之一：字体渲染走的是各自系统的文字引擎，iOS 与 Android 对同一字号字重的度量并不相同，同一行中文在两端可能在不同位置换行；行高计算规则不同，文本垂直居中的实现手法要按端微调；文字溢出省略的属性两端都支持，但省略号出现的位置可能不一致。结论不是「别用 Text」，而是「别假设 Text 的产出像素级一致」——涉及精确对位时，用固定容器加居中布局去约束，而不是赌系统文字引擎的善意。
这背后是一个普适原则：RN 组件的差异分三类。第一类是「有意的差异」——Button 在两端渲染成各自设计语言的原生按钮，这是框架尊重土壤的设计决策；第二类是「实现差异」——如 View 的溢出裁剪默认值两端不同，属于历史遗留或平台限制，需要记忆与对冲；第三类是「能力差异」——某属性只有一端支持（如部分阴影参数），需要条件处理。区分这三类，比背诵差异清单更重要。
图：核心组件双端差异速查
分流的两把工具
第一把：Platform 模块。 轻量差异用它在同一文件里分流。平台判断取当前系统名；平台选择对象按端取值，适合样式与配置；配合三元判断适合逻辑分支。看一个「阴影统一」的完整示例：
import { Platform, StyleSheet } from 'react-native'; // 两端的「浮起」效果实现路径不同：iOS 用阴影参数，Android 用高程 const cardShadow = Platform.select({ ios: { shadowColor: '#000', shadowOpacity: 0.12, shadowRadius: 8, shadowOffset: { width: 0, height: 3 }, }, android: { // 高程值越大浮起感越强，但绘制成本也越高 elevation: 4, }, default: {}, }); const styles = StyleSheet.create({ card: { backgroundColor: '#fff', borderRadius: 12, padding: 14, ...cardShadow }, });
第二把：平台专属文件。 差异大到整块逻辑或整段布局都不同时，把组件拆成带平台后缀的两个文件，比如日期选择器组件拆成同名加 iOS 后缀与加 Android 后缀的两份，构建工具按目标平台自动择一打包。判定口诀：改几行样式用平台选择，改整块结构用平台文件；超过两三处分流逻辑开始互相纠缠时，就该升级成平台文件了。顺带一提，这个机制与第 7 章原生模块的「模块级分流」是一脉相承的——只是那边分流的是原生实现。
完整案例：一张卡片的阴影统一工程
背景：设计规范要求所有浮层卡片有统一的「浮起感」，但iOS 的阴影参数在 Android 上完全不生效，而 Android 的高程在 iOS 上又被忽略，第一版界面出现了「iOS 有影子、Android 是平面」的割裂观感。操作：团队先把浮层卡片收敛为一个基础卡片组件，把上一节的平台选择样式内置其中；再定义高程语义对照——产品语言里的「一级浮起、二级浮起、弹层浮起」分别映射到固定的阴影参数组与高程值组，全项目只允许引用语义层级，不允许手写阴影数字；最后在两端真机上校准观感并截图存档，纳入视觉回归基线。结果：双端浮起感观感一致，且新页面接入卡片组件时零成本获得正确阴影。解读：这个案例的要点不是阴影怎么写，而是「差异管理要沉淀为组件与语义」——把分流逻辑写一次、封在组件里，比在每个页面各写一遍强得多。变式：如果设计规范进一步要求阴影带品牌色，Android 的高程就无法表达了，此时要么接受近似（高程加背景叠加），要么两端各用一套自绘阴影方案——差异管理的尽头是产品决策，不是代码技巧。
三个高频场景的完整对照
把分流工具放进真实场景，决策过程比结论更有价值。
场景一：滚动容器选型。 需求是「个人主页」：头图、资料卡、然后是几十条动态。选 ScrollView 还是 FlatList？判据是数据量与确定性——内容总量少且确定（资料页天然如此），ScrollView 直接装，简单可控；动态列表一旦可能增长到几百条，就必须整体换列表组件承载。常见的错误是「ScrollView 里嵌一个 FlatList」：两个滚动容器互相嵌套，手势归属在两端行为不一致（iOS 倾向把滚动手势给内层，Android 的判断阈值不同），嵌套滚动的问题会以「内层滑两下就卡住」的形式出现。正确做法是要么全程列表组件（把头图做成列表头），要么给内层列表固定高度并关闭其滚动。
场景二：键盘避让。 表单页输入框被键盘遮挡，键盘避让组件的两种偏移策略要按端选：iOS 上键盘高度与动画曲线由系统统一管理，贴边策略顺手；Android 上窗口尺寸调整模式与分屏、全面屏手势交织，高度偏移策略更稳。这不是背结论的场景，是「两端真机各调一遍」的场景——键盘是模拟器还原度最低的系统组件之一。
场景三：状态栏与安全区。 沉浸式头图要顶到状态栏下面，两端的安全区语义不同：iOS 有明确的顶部凹槽与底部横条，Android 的状态栏高度随版本与厂商定制变化。用安全区钩子取值而不是写死高度，是这类需求唯一的稳健做法——写死的数值在你手上的机型是对的，在用户手里的机型是错的。
三个场景共享一条元规则：凡是与系统组件（键盘、状态栏、手势）接壤的地方，默认两端不同，先查证再编码。反过来，纯内容区域（配色、排版、业务组件）两端天然一致，不需要分流。把精力花在接壤处，是差异管理的性价比之道。
本节要点回顾
- 差异分三类：有意的（Button 风格）、实现的（溢出默认值）、能力的（单端属性），分类后再决定统一还是尊重；
- Text 是差异重灾区：字体度量与行高引擎两端不同，精确对位靠容器约束不靠赌；
- View 溢出默认值两端相反：iOS 不裁剪、Android 裁剪，越界装饰在 Android 上会消失；
- 两把分流工具：平台选择适合局部，平台专属文件适合整块，纠缠超过两三处就升级；
- 差异管理沉淀为组件：语义层级内置进基础组件，分流逻辑只写一次。
界面元素认全了，下一节解决「怎么摆」：Flexbox 的主轴交叉轴模型，以及那些与 Web 经验相左的样式默认值。