两种写法直接用对象事件或者用函数组件。如果是函数组件典型的受控写法是这样import { TextInput, View, Text, StyleSheet } from react-native; import { useState, useRef } from react; export const LoginForm () { const [phone, setPhone] useState(); const [password, setPassword] useState(); const pwdRef useRefTextInput(null); const canSubmit phone.length 11 password.length 6; return ( View style{styles.container} TextInput style{styles.input} value{phone} onChangeText{setPhone} placeholder请输入手机号 keyboardTypenumber-pad maxLength{11} returnKeyTypenext blurOnSubmit{false} onSubmitEditing{() pwdRef.current?.focus()} / TextInput ref{pwdRef} style{styles.input} value{password} onChangeText{setPassword} placeholder请输入密码 secureTextEntry returnKeyTypedone submitBehaviorsubmit / TouchableOpacity style{[styles.btn, !canSubmit styles.btnDisabled]} disabled{!canSubmit} onPress{handleLogin} Text style{styles.btnText}登录/Text /TouchableOpacity /View ); }; const styles StyleSheet.create({ container: { padding: 20 }, input: { height: 44, borderWidth: 1, borderColor: #CCC, borderRadius: 8, paddingHorizontal: 12, marginBottom: 16, }, btn: { height: 44, backgroundColor: #3478F6, borderRadius: 8, alignItems: center, justifyContent: center, }, btnDisabled: { backgroundColor: #A0C4FF }, });这里有两个小细节值得单独拿出来说。4.3 失焦与键盘收起的联动处理第一个细节是输入完成后希望键盘自动收起。在React Native里可以用Keyboard.dismiss()来手动收起键盘但要注意调用时机。如果用户在最后一项输入框里按了键盘的“完成/搜索”按钮onSubmitEditing触发时键盘通常会自己收起但如果用户是点击页面其他地方就需要在滚动容器或页面根节点上监听onTouchEnd或onPress来收起键盘。我见过比较稳的方案是在外层包一个Keyboard.dismiss()的透明遮罩或者用ScrollView的keyboardShouldPersistTapshandled。handled的含义是点击子元素时键盘不自动收起由子元素的事件决定是否收起点击空白区域时直接收起键盘。这个属性在OpenHarmony上实测是生效的所以建议从一开始就把它写上避免出现“输入完点登录键盘还挡着按钮”的尴尬场景。第二个细节和焦点有关。onFocus和onBlur在RNOH上也会有触发时序差异。比如onFocus可能在原生控件完成焦点切换之前就被调用如果你在onFocus里读取event.target做焦点判断有时会拿到旧值。我后来习惯在onFocus和onBlur里不依赖event.nativeEvent的具体字段而是直接用ref是否等于当前焦点控件来判断这样最稳。另外iOS和OpenHarmony上都有一个类似的“二次点击”问题某个输入框获得焦点后如果用户再点同一个输入框某些系统只在第一次点击时触发onFocus第二次点击时因为焦点没变就不触发。如果你的业务需要“用点击次数做交互”不能依赖onFocus的重复触发要在TextInput外侧包一层TouchableOpacity或者Pressable来监听点击次数。5. 多行输入、样式定制与性能优化从能用走到好用功能跑通只是第一步真正决定用户留不留得住的是那些细节手感多行输入时的光标位置、字体大小变化的布局稳定性、连续输入时界面卡不卡。这一章聊的都是“从能用走到好用”要做的事。5.1 multiline模式下的高度与对齐问题先说说多行输入。multiline打开之后OpenHarmony上的TextInput会自动具备多行扩展能力但有两个问题很突出。第一个是高度计算。在React Native里如果只设置multiline而不设置固定高度控件默认高度是height: auto会随内容增长。但由于OpenHarmony底层把输入框包装了一层实测中内容超过一行后控件的可视区域有时不会跟着撑开文字会被顶到看不到的位置。解决方案是监听onContentSizeChange事件动态计算内容高度并设置给heightconst [noteHeight, setNoteHeight] useState(80); const onContentSizeChange (e) { const { height } e.nativeEvent.contentSize; // 给一个最小高度和最大高度 setNoteHeight(Math.max(80, Math.min(200, height 16))); }; TextInput style{[styles.noteInput, { height: noteHeight }]} multiline onContentSizeChange{onContentSizeChange} /这样做的原理是contentSize告诉了你纯文本占用的尺寸在高度上加上一点padding的余量就能保证输入光标始终可见。这个逻辑在所有平台上都成立在OpenHarmony上尤为重要因为原生层的行高计算和RN侧的默认值经常不一致。第二个是textAlignVertical。在Android上多行输入框的文字默认是靠上还是居中取决于默认样式在iOS上则没有这个属性。OpenHarmony的ArkUI输入框也有类似行为差异。如果你希望多行占位符文字从左上角开始显示最好显式设置textAlignVertical: top并且用paddingTop来控制首行缩进不要指望默认值一致。我见过一个典型的bug同样的代码在Android上占位符贴顶在OpenHarmony上却垂直居中看起来特别别扭。5.2 字体缩放和padding不一致的根因再来说说字体缩放。React Native有一个全局的allowFontScaling配置默认是true意思是文本会根据系统字体大小设置缩放。问题是OpenHarmony设备上用户如果开启了“大字模式”或“无障碍字体”TextInput内的字体可能会被放大但外层容器的高度和padding并不会跟着变结果就是文字溢出、光标错位。我建议对TextInput显式设置allowFontScaling{false}——如果你能接受应用内部字体大小自保持一致的话。这样做的好处是输入框的布局计算变得可预测无论用户系统设置如何变化行高、高度、padding都能严格按你写的数值渲染。代价是如果你本来希望尊重系统的无障碍设置这个属性就关不合适。折中方案是把maxFontSizeMultiplier设为2之类的大致上限既允许一定比例缩放又不至于让布局崩掉。还有一个容易忽略的点是padding在平台间的差异。同样是paddingHorizontal: 12OpenHarmony上实际表现往往比Android上更“宽”原因是底层ArkUI的TextInput默认自带内边距RN侧叠加之后产生了双倍间距。解决方式不复杂在TextInput的style里把所有padding都显式声明完整并且检测到默认样式复杂时干脆先把padding: 0重置一遍再设置自己的值。这个习惯在需要“宽度严格对齐”的设计稿场景里非常有用。5.3 高频文本变化的性能控制最后聊性能。TextInput是实时输入控件每敲一个字符onChangeText就会触发一次。如果直接把每次输入都同步到React状态再驱动一个较大的页面重新渲染在低端OpenHarmony设备上会明显感到掉帧——因为桥接层的事件转发本身就有开销再加上ArkUI的渲染调度卡顿会被放大。我踩过一次坑做一个搜索页输入框在顶部页面下方是一个几十条数据的列表。最初我把searchText放在页面顶层每次敲字都触发整个列表的重渲染。后来改成两件事一是输入框单独抽成一个组件用memo包裹让输入状态只影响输入框自身和搜索请求逻辑二是给onChangeText里的高频逻辑加一个轻量防抖const handleSearchTextChange useMemo( () debounce((text: string) setSearchText(text), 200), [] );防抖的好处不是降低输入体验而是把“每次输入都触发”变成“用户停顿后触发”对需要依赖输入值去请求接口、搜索过滤的场景非常合适。200毫秒比较中庸不会觉得延迟又能明显降低渲染频率。如果你用useMemo缓存debounce函数还要注意依赖数组里不要放会变的外部引用否则debounce会被反复重建防抖就失效了。另外如果列表很大建议给每一项加React.memo并且用keyExtractor保证key稳定。这一套组合拳打下来输入流畅度会有肉眼可见的改善。6. 面对诡异问题时我的分层排查思路实话实说RNOH的TextInput文档不算丰富很多问题出现时你能搜到的资料很有限。这种情况下与其在网上到处翻帖子不如掌握一套自己的排查思路。我总结的是三步走用来对付多数“行为怪异”的问题都很管用。6.1 第一步用最小demo剥离业务干扰遇到问题先别急着在自己的大项目里打日志。我的习惯是新建一个极简页面只放一个TextInput把可能出现问题的属性一个一个加上去观察行为变化。比如输入中文乱序先测试纯中文输入是否稳定再测试中文和数字混输是否稳定再测试加上maxLength之后是否稳定。通过控制变量往往很快能定位到是某个具体属性引起的而不是整个桥接层坏了。最小demo还有一个好处是能快速验证“问题在所有设备上都复现还是只有特定设备复现”。这一点在OpenHarmony生态里特别重要因为不同厂商的设备对键盘、字体渲染的处理差异很大同一个TextInput在这台设备上没问题在另一台设备上光标就是不动。最小demo能帮你确认到底是代码问题还是设备适配问题。6.2 第二步对比原生ArkUI输入框如果最小demo里RN的输入框依然有问题第二步是写一个同样场景的原生ArkUI页面只放一个原生输入框做同样的操作。如果原生输入框也有同样问题说明问题大概率出在系统控件层RN适配层只是背锅如果原生正常RN异常那就要去查RN到原生控件之间的映射和事件转发环节。这一步的原理很简单TextInput在RNOH里最终还是要落到ArkUI的原生输入框上中间会经过层层的props映射、事件封装。通过原生对照实验你能把问题收敛到“原生层”还是“桥接层”排查范围瞬间缩小一半。我在一台设备上遇到过控制光标颜色无效的问题原生输入框也不支持改光标颜色那就不用再纠结RN这边了直接放弃该属性的跨端一致性。6.3 第三步检查桥接层日志与版本差异如果确定问题出在桥接层那就需要打开调试日志看RN侧把属性传到原生侧之后究竟发生了什么。打开方式是在启动时启用调试模式然后在代码里临时加一些辅助日志比如onChangeText里打印事件对象、onKeyPress里打印按键事件甚至直接在原生代码的对应回调里打印日志。通过对比“RN侧收到了什么”和“原生侧收到了什么”能判断是属性没传过去还是传过去了但原生实现没响应。另外一个经常被忽略的方向是版本差异。RNOH本身迭代很快同一个属性在不同版本里的支持程度变化很大。如果你的项目使用的适配层版本比较老某个属性不支持是很正常的。建议养成一个习惯升级版本之前把项目里用到的所有TextInput属性列成一个清单在新版本上跑一遍别等上线了才发现某个属性行为变了。我在文章开头提到的“行为差异清单”其实就是干这个用的。最后分享一个我自己的复盘习惯每解决一个TextInput相关问题就把“现象—最小复现条件—根因—解决方式—验证方式”记成一条短笔记存到项目文档里。半年下来这份笔记比很多外部资料都有用因为它是你自己的环境、你自己的设备、你自己的代码堆出来的下一次遇到类似问题时能省下大量试错时间。
