去年有段时间团队里流传着一个几乎没有任何解释的立项代号——“rea”。三个字母连个点都没有需求文档里翻来覆去也就一句话做一个跨平台App双端要一起交付。后来内部拉开架势讨论了一次才慢慢把“rea”落地成了一套清晰的目标React Native Application同时它也时时刻刻提醒我们——Reduce Everything App在一款工具型应用里凡是能砍掉的复杂度一律砍掉。我们最终交付的版本功能不多但启动快、包体小、崩溃率低双端体验高度一致。“rea”这个项目也因此从一串无含义字母变成了一条贯穿开发始终的实践原则。这篇内容我整理成了一份完整复盘覆盖需求拆解、技术选型、工程搭建、核心模块落地、性能优化、双端打包排坑全程都按“rea”项目实战的真实推进顺序来写。如果你是第一次从零搭React Native项目或者正在接手一个已经跑起来的跨端代码库又或者正被包体膨胀、首屏卡顿、双端行为不一致这些问题折磨这篇东西应该能帮你少走不少弯路。## 1. 项目定位与需求拆解为什么叫“rea”是件重要的事1.1 用代号代替模糊需求先统一认知再看资源我们最初拿到的需求确实只有刚才那句——“做一个跨平台App双端一起交付”。没有产品原型没有功能清单也没有视觉稿。这种状态下如果直接开干十有八九会在两周后发现方向对不上。所以第一步我们没有急着铺代码而是先给这个项目起了一个足够简短的代号就是rea。不要小看代号这件事它本质上是把“模糊需求”压缩成一个团队内部可以反复引用的锚点。所有的技术决策、排期沟通、需求评审都会围绕这个锚点展开。“rea”在我们内部被解读成两层含义。表面上是React Native Application的缩写对应技术路线深层含义则是Reduce Everything App对应产品哲学。定了这个基调之后我们明确问了自己几个问题这个App最重要的三个功能是什么什么功能砍掉对用户影响最小首版必须支持多大的用户规模答案分别是核心信息流浏览、离线收藏、多端登录状态同步。对了还有一个附加关键词复用。因为我们预算有限团队里没有专门的双端iOS和Android开发所以复用性必须排在选型因素的前列。1.2 核心需求与功能边界的取舍没有边界的项目是最危险的所以我根据“rea”的定位把需求拆成了这样几层才落工单必须具备的功能信息流列表展示、下拉刷新、离线缓存阅读记录、账号登录和状态持久化。可以后置的功能分享卡片生成、深色模式、消息推送、多语言这些全部丢给V2版本。明确不做的东西聊天功能、实时协同、复杂富文本编辑器这些和工具型场景矛盾会迅速吞噬双端排期。这里我有一个非常个人的建议如果你的项目也叫不上名字来起一个像rea这样足够短、没有歧义的代号比立刻去定义产品细节有用得多。因为代号一旦确定讨论中“这个功能影响rea的定位吗”这句话会反复帮你拦截掉那些“顺手加个小功能”之类的需求蔓延。1.3 目标场景与用户画像给谁用解决什么“rea”定位的目标场景非常明确面向经常需要在移动端快速查阅、收藏、离线查看内容的用户。不是给重型业务管理用的也不是给强社交互动场景用的。用户最典型的使用路径是打开App看到信息流点进详情划重点收藏关闭。整个过程应该像打开一个原生工具那样轻。我们根据这个路径把用户体验目标定为三条可量化的红线后续所有技术选型都有围绕这三条红线修改的判断冷启动到首屏内容可见不超过2.5秒中低端Android机也纳入验收范围。信息流滑动掉帧率大部分时间保持在60fps低端机上允许偶尔掉到45fps左右但不能持续掉帧。离线打开收藏内容必须做到秒开不出现白屏或loading超过300毫秒。这三条红线后来帮了大忙。比如我们砍掉了一些比较重的动画库抛弃了冗余的数据预加载方案都是因为会让滑动掉帧率超标。如果没有明确红线这些“看起来很美”的东西很容易溜进项目里拉低真实体验。2. 技术选型与工程搭建React Native之外没有更合适的答案2.1 为什么选React Native而不是Flutter或原生双栈关于实现方案确实纠结过。Flutter当时在UI一致性和渲染性能上都很有说法原生双栈则是最稳妥的保底选项。但按照“rea”的约束条件——预算有限、团队以Web技术栈为主、双端必须并行交付——React Native是唯一能在现有技术储备和交付速度之间达成平衡的选项。我们选定React Native核心理由有三条都是基于当时团队实际状况考量的不是单纯追新团队熟悉JavaScript和React的组件化心智RN的应用成本比Flutter的Dart低很多上手更快。RN的JS层修复可以通过热更新机制动态下发对首版这种“迭代节奏偏快、可能边用边修”的项目救急能力远胜原生。社区和生态足够成熟列表、存储、导航、权限这些基础模块都有已经过大规模验证的稳定库可选不需要像Flutter那样频繁翻pub.dev碰运气。如果你团队里原生开发经验很丰富那原生双栈无可厚非。如果你团队只有七八个人还都是一专多能型的前端为主“rea”这种场景下React Native确实比Flutter更贴近现实生产力。2.2 工程初始化与依赖锁定策略工程搭建这块我们用的是社区维护的标准脚手架初始化模板然后第一时间锁定了所有核心依赖的精确版本号。这里我必须强调一个不太会写在官方文档里的经验React Native项目的依赖版本千万不能随便用^号加Latest策略。RN对依赖版本极其敏感很多跑不起来的奇怪问题最终都能追溯到某个依赖被自动升级到了不兼容的版本。我们项目里最终锁定的模板依赖大致如下{ react: 18.2.0, react-native: 0.72.5, react-navigation: ^6.1.7, zustand: 4.4.1, react-native-mmkv: 2.10.2, shopify/flash-list: 1.6.3 }几个选型决定背后的逻辑也顺带说说状态管理选了Zustand而不是Redux Toolkit原因是“rea”的全局状态并不复杂Zustand的样板代码更少、依赖更轻、心智负担更低。如果你预判项目会有大量复杂交互的状态流转比如表单联动、SSR同步之类Redux生态更成熟但单纯为了一个移动端工具型AppZustand确实是清爽的选择。本地存储选了MMKV而不是AsyncStorage核心原因是MMKV是同步操作可以避免异步读取偶发白屏而且读写性能要快一个数量级。后面做离线收藏秒开就靠它扛着。长列表选了FlashList而不是基础版FlatList原因是FlashList对cell的回收复用实现更激进在低端机上的滑动流畅度有可感知的提升。2.3 目录结构与代码规范让“rea”保持易维护的工程底线如果说依赖锁定解决的是“能不能跑”的问题那目录结构和代码规范解决的就是“跑了之后能不能改”的问题。我们按业务边界而非技术类型来划分目录因为“rea”的核心业务路径非常清晰这种方式让新同学接手时能秒懂代码位置。最终的目录结构精简成这样src/ api/ // 网络请求统一封装 components/ // 通用UI组件 screens/ // 页面级容器 store/ // zustand状态模块 utils/ // 工具函数 hooks/ // 复用逻辑 types/ // TS类型定义 constants/ // 全局常量这套结构谈不上惊艳但它解决了我们在“rea”里遇到的最实际问题不会再出现一个几百行的“杂项组件”躺在components根目录里也不会有人为了找一个fetch函数翻遍整个项目。这阶段还要做好两件事一是TypeScript严格模式从第一天就开到底二是ESLint规则统一。不值得为“写起来方便”妥协移动端项目一旦上了规模类型不严格的成本会指数级增加。3. 核心模块落地与关键实现从列表到离线存储3.1 信息流列表FlashList替换FlatList前后的感知变化“rea”的主页面就是一个信息流列表。最初我们用基础版FlatList后来在真机调试时发现切换页签或快速滚动时偶尔会出现白屏闪烁和组件重建痕迹虽然不致命但视觉上很不舒服。于是我们换成了FlashList。FlashList和FlatList使用上高度接近核心是将长列表的回收机制做得更激进并支持自动按可视区域裁剪。我们当时的迁移代码基本只改变了组件引入和props命名很平滑import { FlashList } from shopify/flash-list; FlashList data{feedItems} renderItem{renderItem} estimatedItemSize{120} keyExtractor{(item) item.id} onEndReached{loadMore} onEndReachedThreshold{0.3} /这里有一个极其重要的参数estimatedItemSize。它必须和你实际的cell高度接近否则FlashList的预裁剪会出错表现为滚动时内容“跳来跳去”。我们在设置这个值之前实测过平均cell高度并把详情页作为独立页面处理不在列表内做高度变化的动态卡片才把滑动体验稳定住。如果你也打算迁移FlashList我的建议是不要在复杂cell里使用绝对定位做太多覆盖层FlashList对绝对定位元素的回收判断偶尔会出现视觉残留这是我们在V1里踩过的一个比较典型的问题。3.2 离线收藏与阅读记录缓存同步存储是靠谱的选择传统方案里续读位置、收藏列表这类数据一般会走AsyncStorage异步读写。但“rea”在需求层面就给了一条硬指标离线打开收藏内容要秒开。这就意味着用户点击“收藏”按钮后下次冷启动进入收藏列表时我们不能等待异步I/O返回。我们最终选择用MMKV做同步存储核心读写都走同步API。页面加载时直接从store里取数据省去loading状态体验上等于离线版也是秒开。代码形态大概是这样import { MMKV } from react-native-mmkv; export const storage new MMKV({ id: rea-offline-store, encryptionKey: your-key-saved-securely, }); export const saveCollection (item: FeedItem) { const collections getCollections(); collections.unshift(item); storage.set(collections, JSON.stringify(collections)); }; export const getCollections (): FeedItem[] { const cached storage.getString(collections); return cached ? JSON.parse(cached) : []; };关于加密这里有一个很容易忽略的细节MMKV本身支持加密但开启加密后会有轻微的性能损耗。如果你存的是纯阅读记录这种敏感程度不高的数据是否加密需要权衡如果涉及真正的token、账号信息我会强烈建议开启加密并且不要把密钥硬编码在代码仓库里。我们当时把密钥放在工程外的分发配置中打包时通过环境变量注入保证代码仓库可以开源也不会把核心key泄出去。3.3 长表单与搜索页渲染粒度的控制“rea”里有一个对内容进行多条件筛选的功能看起来是个不起眼的页面但它非常容易让性能翻车。原因很简单筛选条件包含多个输入框、多个下拉项、还有联动逻辑如果不做控制任何一个状态的变动都会触发整页重渲染。我们的优化思路其实不复杂核心是拆分渲染粒度。搜索框用独立的组件管理自己的输入值筛选条件的结果通过zustand保存筛选操作按钮单独订阅store变化。这样用户每次输入直接变化的只有输入框组件而不是整页所有组件跟着re-render。如果你遇到的页面比这个还复杂我的建议是配合React.memo做一层props浅比较然后所有回调都用useCallback包好。但要记住React.memo不是万能的如果props里有对象字面量或内联函数浅比较基本失效等于白写。所以关键还是状态拆分而不是组件保鲜膜叠叠乐。3.4 权限申请与双端差异的if-else细节移动端绕不开权限。“rea”涉及相机扫码、相册保存、文件下载功能这三个权限在iOS和Android上的行为差异很大。iOS的相册权限描述可以精确到“仅添加照片”Android则在不同的版本上有不同的运行时权限策略。这部分代码看起来就是一堆判断分支但容易踩的坑在于你没有在国产Android厂家ROM上测试过授权失败后的回调路径。很多机器上的“拒绝一次”和“永久拒绝”反馈终点不一样如果代码里只处理了“拒绝”而没有处理“拒绝并不再询问”用户后续就能看到一直无法授权的死局。我们可以封一个统一的权限请求函数把双端差异收敛到内部import { PermissionsAndroid, Platform } from react-native; export async function requestCameraPermission(): Promiseboolean { if (Platform.OS android) { const result await PermissionsAndroid.request( PermissionsAndroid.PERMISSIONS.CAMERA ); return result PermissionsAndroid.RESULTS.GRANTED; } // iOS走系统弹窗只需要获取授权状态 return hasIOSPermission(camera); }同时一定要在进入页面时检测一次授权状态不只依赖用户触发时的回调。不然在一些国产Android改过的授权弹窗流程下用户在外面点完授权回到App里你的页面状态没有刷新就会出现功能开了权限也没生效的诡异情况。4. 性能优化与包体精简实录把“rea”从27MB瘦到17MB4.1 包体瘦身图标字体、ABI裁剪和依赖审查三管齐下打包产物体积在“rea”的项目里是明确考核项所以这块是实打实的数据。我们首次打包双端APK安装包是27MB左右所有优化做完之后稳定在17MB上下降幅接近37%。整个过程并不指望一步到位而是分了三步走。第一步把项目里引用的矢量图标从SVG字体包全部替换为单文件按需引入的SVG组件这一步就砍掉了约6MB。图标字体包虽然是工程化的常规做法但它的体积是固定的哪怕你只用其中一个图标也要付全价的重量。第二步合理裁剪原生ABI。我们的最低支持版本聚焦在ARM 64位设备所以把x86和x86_64的so库全部排除。这一点在真机自测时问题不大但如果你是纯模拟器开发党要小心APK在模拟器上的兼容性。我们的做法是保留本地debug包包含全ABIrelease包只保留arm64-v8a不至于让开发者体验降级。第三步拆除重量级依赖。我们发现某几个原来用来做缓存和网络增强的库实际上在“rea”的场景里并没有带来匹配体量的收益比如一些全功能缓存适配器、额外的Cookie同步库都被移除后替换成轻量实现。这一步相对温和但叠加下来也省了约2MB。4.2 启动时间优化首屏渲染路径上的每个延迟点都要清零“rea”的冷启动上我们原本中低端Android实测冷启动首屏大概在3.2秒左右离我们自己划线的那条2.5秒红线还差不少。优化动作集中在四个方面按收益从高到低排是减少入口页面的JS执行量。原来入口页一次性注册了很多全局初始化任务包括埋点、推送、主题同步全部被后置到首帧渲染完成后再通过空闲调度分批执行。用FlashList替代首页原本的FlatList后列表首屏渲染的Scheduling效率提升非常直观早期节点白屏时间缩短了约300毫秒以上。图片加载从“全量加载原图”改为“首屏只加载可视区域缩略图”配合统一的图片尺寸服务首屏图片解码量大幅下降。把Hermes引擎的预编译字节码和序列化缓存打开减少JS解释阶段的耗时。这个阶段我个人最后悔的一件事是没有在项目第一周就接入性能监控工具。如果能更早看到真实设备上的帧率和加载时间曲线很多优化不会等到后期才做。如果你也正从零开始构建一个类似项目建议至少在第二天就接一个最轻量的话性能监控工具哪怕只记录页面加载耗时也比事后脑补提速方向要好得多。4.3 内存治理与低端机体验回收策略比堆料更有效内存这块我们没有选择上重型的图片缓存框架而是做了一个很克制的事图片全部统一走尺寸裁剪、缓存分级控制同时在列表滚出可视区域后主动释放对应图片占用的内存引用。这样折腾下来整个App稳定运行时的内存占用比最初版本低了近四分之一。另外还干了一件事给列表页设置了离屏Cell卸载阈值。FlashList会把离开视口很远的组件直接卸载尽管它会依赖estimatedItemSize重新计算高度但我们实测没有出现白屏闪烁低端机的内存压力明显减少。回头看“rea”项目里几乎没有用过“堆内存”的思路基本都是“省着点用”这对移动端长期稳定性很重要。5. 双端差异与打包排查实录踩坑速度和解决速度成正比5.1 iOS和Android的四个典型行为差异双端一起交付就意味着所有代码都要过两遍不同系统的脾气。“rea”开发生命周期里收集到的典型差异我整理成了一张速查表后续排障我基本就是对着它来场景iOS表现Android表现处理方式列表惯性滚动自然平顺部分机型有滑动粘滞感Android关闭过度滚动阴影并调低弹簧系数软键盘弹出页面自动避让部分机型可能遮挡输入框手动监听键盘高度调整内容容器字体渲染字体细腻但偏细低端机可能出现锯齿感使用已打包字重不依赖系统默认渲染文件下载需配置网页安全域需动态申请存储权限统一由原生模块处理前端只透传状态这里面最隐蔽的坑是软键盘。iOS的默认行为帮你处理了一部分避让逻辑看起来没事但Android上如果你用的不是全屏主题键盘高度波动就可能导致重新布局抖动。我们的处理方式是监听键盘事件在页面底部留出安全区域缓冲不依赖任何自动避让。5.2 构建打包阶段遇到的问题速查打包阶段的问题和运行时的问题不同它往往是“突然出现”的排查起来也更费时间。“rea”项目中我们遇到的几个高频问题解决方案如下iOS执行pod install时经常因为某个本地缓存不匹配卡住。 解法删除Podfile.lock和Pods目录清缓存后重装。虽然麻烦但能解决98%的安装问题。Android构建release时堆内存溢出。 解法在android/gradle.properties里调大JVM内存配置同时开启org.gradle.parallel并行编译。Release包能装但不能启动logcat里有加载JS bundle失败。 解法先确认bundle已正确打包进assets其次确认metro配置的bundle路径和原生代码中读取的路径一致。这个问题绝大多数是路径没匹配上导致的。Debug模式可以正常跑但Release模式点击按钮没响应或页面空白。 解法先排查是否启用了严格模式后API返回数据结构不匹配再排查是否存在原生模块在新架构下被禁用的情况。Release模式里JS报错不像Debug那么明显建议接一个线上日志上报组件。如果你目前卡在某个奇怪的构建问题上我的经验是先把“网络依赖”排除干净。很多构建问题都是仓库源、依赖缓存、不同仓库间版本解析不一致带来的连锁反应而不是代码本身写错了。5.3 热更新使用与安全合规的一并考虑热更新很好用“rea”也确确实实依赖它修复过几个低危Bug。但我必须说移动应用分发和热更新的合规问题直接关系到项目能不能长期安全运转。我们在这方面做的约束是不使用外部热更新框架的私有加密通道不混淆官方渠道发布逻辑。每次热更包发布前都会测试指纹哈希确保包体来源可信避免被中间人篡改。重要敏感操作比如登录支付相关的变更一律走应用市场正式发布不塞进紧急热更通道。这不是技术上的高级技巧但每次发布前花一分钟走一遍这个检查能规避掉很多不可控风险。合规底线这根弦别松。6. 后续扩展与一些没有写进文档的心得“rea”项目本身目前还在持续迭代V2阶段已经排上了离线同步增强和智能推荐。但以“rea”为起点的这段实践我最大的收获反而不是React Native本身的使用技巧而是“克制”这两个字对工程的重要意义。功能上克制依赖上克制甚至状态更新上也克制很多看起来都需要加的东西最后会发现不加才是最优解。如果你也想从零开始一个跨端项目我个人的建议是每天问一遍团队“今天这个需求对rea式的短期交付目标有帮助吗”如果没有就晚点再说。好的工程不取决于添加了多少库而取决于你敢于砍掉多少看似合理的东西。双端稳定包体小启动快用户说不出来具体哪里好但体验就是顺畅。这大概就是我们做“rea”时最值得说出口的成绩。