前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载导读本指南以仓库内 .agent/skills/mobile-design/decision-trees.md 为核心系统讲解移动端项目iOS / Android / 跨平台在架构起航阶段必须做出的五类关键决策框架选型、状态管理、导航模式、存储策略、离线与认证方案。文档在仓库中的定位是mobile-design技能包.agent/skills/mobile-design/SKILL.md的决策参考文件配套 mobile-design-thinking.md、mobile-navigation.md、mobile-backend.md 等深度参考并被mobile-developer智能体见 .agent/ARCHITECTURE.md在移动端开发任务中按需加载。读完本文你将掌握一套先问需求、再选技术的决策框架能够根据 OTA 更新诉求、UI 一致性要求、离线依赖程度等真实约束为任意移动端项目搭出可落地、可扩展的技术栈。重要定位这套决策树是思考指南THINKING guides不是可直接照抄的答案copy-paste answers。文档开篇即强调每个项目都有独特的约束需求模糊时必须先向用户提出澄清问题依据实际需要而非默认习惯做选择。一、第一层决策框架选型Framework Selection框架选择是移动端架构的总开关它决定了后续所有模式与工具链的可用范围。原文档给出了一张主决策树Master Decision Tree以下是其完整逻辑WHAT ARE YOU BUILDING? │ ├── Need OTA updates without app store review? │ │ │ ├── Yes → React Native Expo │ │ ├── Expo Go for development │ │ ├── EAS Update for production OTA │ │ └── Best for: rapid iteration, web teams │ │ │ └── No → Continue ▼ │ ├── Need pixel-perfect custom UI across platforms? │ │ │ ├── Yes → Flutter │ │ ├── Custom rendering engine │ │ ├── Single UI for iOS Android │ │ └── Best for: branded, visual apps │ │ │ └── No → Continue ▼ │ ├── Heavy native features (ARKit, HealthKit, specific sensors)? │ │ │ ├── iOS only → SwiftUI / UIKit │ │ └── Maximum native capability │ │ │ ├── Android only → Kotlin Jetpack Compose │ │ └── Maximum native capability │ │ │ └── Both → Consider native with shared logic │ └── Kotlin Multiplatform for shared │ ├── Existing web team TypeScript codebase? │ │ │ └── Yes → React Native │ ├── Familiar paradigm for React devs │ ├── Share code with web (limited) │ └── Large ecosystem │ └── Enterprise with existing Flutter team? │ └── Yes → Flutter └── Leverage existing expertise框架横向对比因素React NativeFlutter原生Swift/KotlinOTA 更新✅ Expo❌ 不支持❌ 不支持学习曲线低React 开发者中等较高性能良好优秀最佳UI 一致性平台原生风格双端完全一致平台原生风格包体积中等较大最小原生能力访问通过 bridge通过 channel直接热重载✅✅✅Xcode 15对比表揭示了一个容易被忽略的核心权衡Flutter 的双端 UI 完全一致是以放弃平台原生视觉语言为代价的而 React Native 更接近用 Web 团队熟悉的范式写移动应用其 OTA 能力Expo EAS Update是另外两大路线不具备的差异化优势。何时选原生NativeCHOOSE NATIVE WHEN: ├── 需要极致性能游戏、3D ├── 需要深度 OS 集成 ├── 平台专属功能是核心卖点 ├── 团队具备原生开发经验 ├── App Store 是主要分发渠道 └── 长期维护优先级高 AVOID NATIVE WHEN: ├── 预算/时间有限 ├── 需要快速迭代 ├── 双端需要完全一致的 UI ├── 团队以 Web 技术为主 └── 跨平台是首要诉求仓库中的配套佐证框架决策树在技能包中的位置.agent/skills/mobile-design/SKILL.md 末尾的 Framework Decision Tree 是本文档的精简版并明确指引完整决策树见 decision-trees.md相对链接已指向本文档SKILL.md 中亦有对应条目。React Native 参考栈.agent/skills/app-builder/templates/react-native-app/TEMPLATE.md 给出了与决策树一致的具体组合React Native Expo 框架、TypeScript 语言、Expo Router 导航、Zustand React Query 状态、NativeWind 样式、Jest RNTL 测试可作为选型后的脚手架蓝本。框架选择与智能体职责的对应.agent/ARCHITECTURE.md 中mobile-developer智能体的职责被定义为 iOS, Android, RN使用的技能正是mobile-design说明该决策树是实际开发流程中被强制加载的决策依据。二、第二层决策状态管理选型State Management Selection选定框架后下一个关键决策是状态管理。原文档分别针对 React Native 与 Flutter 给出了两棵决策树。React Native 状态决策树WHATS YOUR STATE COMPLEXITY? │ ├── 简单应用、页面少、共享状态极少 │ │ │ └── Zustand或直接用 useState/Context │ ├── 样板代码最少 │ ├── 易于理解 │ └── 可扩展至中型应用 │ ├── 以服务端数据为主API 驱动 │ │ │ └── TanStack Query (React Query) Zustand │ ├── Query 管服务端状态 │ ├── Zustand 管 UI 状态 │ └── 优秀的缓存与自动重取能力 │ ├── 功能复杂的大型应用 │ │ │ └── Redux Toolkit RTK Query │ ├── 可预测、可调试 │ ├── RTK Query 负责 API │ └── 适合大型团队 │ └── 原子化、细粒度状态需求 │ └── Jotai ├── 基于 atom类似 Recoil ├── 最小化重渲染 └── 擅长派生状态Flutter 状态决策树WHATS YOUR STATE COMPLEXITY? │ ├── 简单应用、正在学习 Flutter │ │ │ └── Provider或 setState │ ├── 官方方案、简单 │ ├── Flutter 内置 │ └── 适合小应用 │ ├── 现代、类型安全、可测试 │ │ │ └── Riverpod 2.0 │ ├── 编译期安全 │ ├── 代码生成 │ ├── 非常适合中大型应用 │ └── 新项目推荐 │ ├── 企业级、需要严格模式 │ │ │ └── BLoC │ ├── Event → State 模式 │ ├── 非常可测试 │ ├── 样板代码较多 │ └── 适合大型团队 │ └── 快速原型 │ └── GetX谨慎使用 ├── 实现快 ├── 模式约束弱 └── 大规模时容易失控状态管理反模式清单❌ 不要 ├── 用全局状态管理一切 ├── 混用多种状态管理方案 ├── 把服务端状态存进本地状态 ├── 跳过状态归一化normalization ├── 滥用 Context重渲染开销大 └── 把导航状态放进应用状态 ✅ 要做 ├── 服务端状态 → 交给 Query 库 ├── UI 状态 → 尽量局部、本地优先 ├── 仅在必要时提升lift状态 ├── 每个项目只选一种方案 └── 让状态保持在它被使用的地方附近仓库中的配套佐证服务端状态交给 Query 库与 React Native 模板一致.agent/skills/app-builder/templates/react-native-app/TEMPLATE.md 明确列出zustand本地状态与tanstack/react-query服务端状态的分工正是决策树Query 管服务端、Zustand 管 UI的落地形态。不要滥用 Context的深层原因状态管理之所以强调最小化重渲染是因为移动端渲染性能直接关系到 60fps 流畅度——.agent/skills/mobile-design/mobile-performance.md 指出每帧必须在 16.67ms60fps内完成超时即掉帧、产生卡顿感知。Context 变化引发的大范围重渲染正是移动端常见的性能杀手。混用方案反模式的额外佐证.agent/skills/mobile-design/mobile-design-thinking.md 的 Pattern Questioning Matrix 对状态默认项提出同样质疑例如Redux everywhere→ 简单应用用 Zustand服务端用 TanStack Query。三、导航模式选型Navigation Pattern Selection导航是应用的骨架。原文档以顶层目的地数量为第一判断维度给出了清晰的决策树HOW MANY TOP-LEVEL DESTINATIONS? │ ├── 2 个目的地 │ └── 考虑顶部 Tab 或简单 Stack │ ├── 3-5 个目的地重要性相当 │ └── ✅ Tab Bar / 底部导航 │ ├── 最常见模式 │ └── 易于发现 │ ├── 5 个目的地 │ │ │ ├── 全部重要 → Drawer 导航 │ │ └── 隐藏但选项多 │ │ │ └── 部分次要 → Tab bar drawer 混合 │ └── 单一线性流程 └── 仅 Stack 导航 └── 引导注册、结算流程等按应用类型的导航模式速查应用类型推荐模式理由社交类如 InstagramTab bar频繁切换电商Tab bar stack分类作为 tab邮箱如 GmailDrawer 列表-详情文件夹众多设置仅 Stack逐层深入引导注册Stack 向导线性流程即时通讯Tab会话 stack线程化仓库中的配套佐证导航决策树的完整版.agent/skills/mobile-design/mobile-navigation.md 以应用类型为入口给出了与之互补的另一棵决策树3-5 个同等重要分区 → Tab Bar深度层级内容 → Stack超 5 个顶层目的地 → Drawer单一线性流程 → 仅 Stack平板/折叠屏 → Navigation Rail 列表-详情并深入展开 Tab 状态保持每个 Tab 维护独立导航栈、返回键处理iOS 边缘右滑 vs Android 系统返回、深链导航规则等细节可作为本节的进阶阅读。Tab 状态保持是决策树未展开的隐性要求原文档导航模式一节虽短但其背后遵循的原则——切换 Tab 不重置栈、返回永远沿栈向上、不得劫持返回键——都在 .agent/skills/mobile-design/mobile-navigation.md 中被列为硬性规则如 Back ALWAYS navigates up the stack、Never hijack back for other purposes。四、存储策略选型Storage Strategy Selection存储决策应当按数据类型分门别类而不是一个方案打天下。原文档给出的决策树WHAT TYPE OF DATA? │ ├── 敏感数据令牌、密码、密钥 │ │ │ └── ✅ 安全存储Secure Storage │ ├── iOS: Keychain │ ├── Android: EncryptedSharedPreferences │ └── RN: expo-secure-store / react-native-keychain │ ├── 用户偏好设置、主题 │ │ │ └── ✅ 键值存储Key-Value Storage │ ├── iOS: UserDefaults │ ├── Android: SharedPreferences │ └── RN: AsyncStorage / MMKV │ ├── 结构化数据实体、关系 │ │ │ └── ✅ 数据库Database │ ├── SQLiteexpo-sqlite, sqflite │ ├── RealmNoSQL, 响应式 │ └── WatermelonDB大数据集 │ ├── 大文件图片、文档 │ │ │ └── ✅ 文件系统File System │ ├── iOS: Documents / Caches 目录 │ ├── Android: 内部/外部存储 │ └── RN: react-native-fs / expo-file-system │ └── API 缓存数据 │ └── ✅ Query 库缓存 ├── TanStack QueryRN ├── Riverpod asyncFlutter └── 自动失效机制存储方案对比存储类型速度安全性容量适用场景安全存储中等 高小令牌、密钥键值存储快低中等设置项SQLite快低大结构化数据文件系统中等低非常大媒体、文档Query 缓存快低中等API 响应仓库中的配套佐证令牌必须安全存储在技能包中被上升为强制纪律.agent/skills/mobile-design/SKILL.md 的 Security Sins 表格将Token in AsyncStorage列为绝不许可的行为正确做法是SecureStore/Keychain/EncryptedSharedPreferences.agent/skills/mobile-design/mobile-backend.md 进一步给出令牌分层策略短生命周期 access token 存内存、长生命周期 refresh token 存 SecureStore/Keychain 并每次使用轮换。RN 模板中的存储落地.agent/skills/app-builder/templates/react-native-app/TEMPLATE.md 的存储组件明确为Expo SecureStore与决策树的安全存储分支完全对应。五、离线策略选型Offline Strategy Selection离线能力是移动应用区别于 Web 应用的核心约束之一。原文档按离线的重要性划分三档HOW CRITICAL IS OFFLINE? │ ├── 锦上添花有网时正常用即可 │ │ │ └── 缓存最近数据 展示过期数据 │ ├── 实现简单 │ ├── TanStack Query staleTime │ └── 显示最后更新时间 │ ├── 核心功能必须离线可用 │ │ │ └── Offline-first 架构 │ ├── 本地数据库作为数据源source of truth │ ├── 联网后同步到服务端 │ ├── 制定冲突解决策略 │ └── 操作入队等待后续同步 │ └── 实时性至关重要协作、聊天 │ └── WebSocket 本地队列 ├── 乐观更新 ├── 最终一致性 └── 复杂的冲突处理四种离线实现模式1. CACHE-FIRST简单 请求 → 查缓存 → 若过期则拉取 → 更新缓存 2. STALE-WHILE-REVALIDATE 请求 → 先返回缓存 → 后台拉取更新 → 更新 UI 3. OFFLINE-FIRST复杂 操作 → 写入本地数据库 → 入同步队列 → 联网时同步 4. SYNC ENGINE同步引擎 使用Firebase、Realm Sync、Supabase realtime 自动处理冲突解决仓库中的配套佐证冲突解决策略的展开.agent/skills/mobile-design/mobile-backend.md 给出了与Offline-first配套的冲突解决策略谱系——Last-write-wins简单数据、单用户、Server-wins关键交易、Client-wins重度离线应用、Merge文档类按字段合并、CRDT实时协作并给出了客户端同步队列的标准流程本地写入 → 入队{ action, data, timestamp, retries }→ 有网时 FIFO 处理 → 失败指数退避重试最多 5 次→ 冲突按策略解决。展示最后更新时间的缓存细节对锦上添花档.agent/skills/mobile-design/mobile-backend.md 补充了只读数据新闻、目录应使用简单缓存 TTL ETag/Last-Modified 失效的具体实现让缓存最后数据这一原则可落地。六、认证模式选型Authentication Pattern Selection认证决策树以需要何种认证为入口WHAT AUTH TYPE NEEDED? │ ├── 简单邮箱/密码 │ │ │ └── 基于令牌JWT │ ├── refresh token 安全存储 │ ├── access token 存内存 │ └── 静默刷新流程 │ ├── 社交登录Google、Apple 等 │ │ │ └── OAuth 2.0 PKCE │ ├── 使用平台 SDK │ ├── Deep link 回调 │ └── iOS 必须接入 Apple Sign-In │ ├── 企业级/SSO │ │ │ └── OIDC / SAML │ ├── WebView 或系统浏览器 │ └── 正确处理重定向 │ └── 生物识别FaceID、指纹 │ └── 本地认证 安全令牌 ├── 生物识别解锁存储的令牌 ├── 不能替代服务端认证 └── 提供 PIN/密码回退令牌存储的红线与正确做法❌ 绝不把令牌存在 ├── AsyncStorage明文 ├── Redux/state未正确持久化 ├── 等价于本地存储的地方 └── 日志或调试输出 ✅ 令牌永远存在 ├── iOS: Keychain ├── Android: EncryptedSharedPreferences ├── Expo: SecureStore ├── 支持生物识别保护则优先仓库中的配套佐证静默刷新流程的完整逻辑.agent/skills/mobile-design/mobile-backend.md 补充了原文档未展开的静默再认证请求流携带 access token 请求 → 收到 401 → 有 refresh token 则调用/auth/refresh→ 成功则重试原请求、失败则强制登出并给出三层令牌模型access / refresh / device token其中 device token 用于支持登出所有设备。不用 AsyncStorage 存令牌与安全纪律一致这与第四节存储策略、.agent/skills/mobile-design/SKILL.md 的 Security Sins 表完全闭环——三处文档对同一规则反复强调可见该约束在技能体系中的重要级别。七、项目类型模板Project Type Templates决策树的价值在于组合应用。原文档给出三类典型项目的推荐栈可直接作为选型后的总装清单。电商应用E-Commerce AppRECOMMENDED STACK: ├── 框架: React Native Expo定价策略需要 OTA ├── 导航: Tab bar首页、搜索、购物车、账户 ├── 状态: TanStack Query商品 Zustand购物车 ├── 存储: SecureStore认证 SQLite购物车缓存 ├── 离线: 缓存商品、购物车操作入队 └── 认证: 邮箱/密码 社交登录 Apple Pay KEY DECISIONS: ├── 商品图片: 懒加载、积极缓存 ├── 购物车: 通过 API 跨设备同步 ├── 结算: 安全、步骤最少 └── 深链: 商品分享、营销活动社交/内容应用Social/Content AppRECOMMENDED STACK: ├── 框架: React Native 或 Flutter ├── 导航: Tab bar动态流、搜索、发布、通知、个人主页 ├── 状态: TanStack Query动态流 ZustandUI ├── 存储: SQLite动态流缓存、草稿 ├── 离线: 缓存动态流、发布操作入队 └── 认证: 以社交登录为主Apple 登录必需 KEY DECISIONS: ├── 动态流: 无限滚动、列表项记忆化 ├── 媒体: 上传队列、后台上传 ├── 推送: 深链到具体内容 └── 实时: WebSocket 推送通知生产力/SaaS 应用Productivity/SaaS AppRECOMMENDED STACK: ├── 框架: FlutterUI 一致或 RN ├── 导航: Drawer 或 Tab bar ├── 状态: Riverpod/BLoC 或 Redux Toolkit ├── 存储: SQLite离线、SecureStore认证 ├── 离线: 全量离线编辑 同步 └── 认证: 企业级 SSO/OIDC KEY DECISIONS: ├── 数据同步: 冲突解决策略 ├── 协作: 实时还是最终一致 ├── 文件: 大文件处理 └── 企业: MDM、合规要求仓库中的配套佐证模板与决策树的组合一致性三类模板恰好分别示范了不同决策路径的组合结果——电商选择了OTA 优先路径RN Expo生产力应用选择了UI 一致性优先路径Flutter与第一节主决策树的分支逻辑一一对应。更多应用类型的决策细化.agent/skills/mobile-design/mobile-design-thinking.md 的 CONTEXT-BASED DECISION PROTOCOL 还补充了 Utility工具类可仅 Stack 导航、快速启动优先与 Media/Streaming媒体流横向轮播 预加载 后台播放两类应用的差异化决策点。八、决策清单与澄清问题Decision Checklist Questions to Ask User任何项目启动前的检查清单目标平台已定义iOS/Android/双端已基于标准完成框架选择已确定状态管理方案已选定导航模式每种数据类型都有存储策略已明确离线需求已设计认证流程从一开始就规划了深链deep linking项目需求模糊时必须向用户提出的问题If project details are vague, ASK: 1. 是否需要不经过应用商店审核的 OTA 更新 → 影响框架选择Expo 可以 2. iOS 和 Android 是否需要完全一致的 UI → 影响框架Flutter 一致 3. 离线需求是什么 → 影响架构复杂度 4. 是否已有后端/认证系统 → 影响认证与 API 方案 5. 目标设备仅手机还是需要平板 → 影响导航与布局 6. 企业级还是消费级 → 影响认证SSO、安全、合规仓库中的配套佐证先问再做是技能包的强制要求.agent/skills/mobile-design/SKILL.md 设有专门章节 CRITICAL: ASK BEFORE ASSUMING (MANDATORY)要求当用户需求开放式时必须询问平台、框架、导航、状态管理、离线、目标设备六项mobile-design-thinking.md的 MOBILE DESIGN COMMITMENT 也要求开工前填写项目平台、将避免的默认模式、平台差异等承诺项——填不出来就说明对项目理解不足应回头补调研。深链必须从第一天规划原文档清单强调 deep linking 前置规划.agent/skills/mobile-design/mobile-navigation.md 从反面印证了这一点——后来再补深链很难需要导航重构、屏幕依赖不清晰、参数传递复杂并给出 URL 结构应镜像导航层级如myapp://home/product/123/reviews的规范。九、反模式决策Anti-Pattern Decisions常见决策反模式速查反模式为什么糟糕更优做法简单应用用 Redux严重过度设计Zustand 或 ContextMVP 用原生开发开发速度慢跨平台 MVP只有 3 个分区却用 Drawer导航被隐藏Tab bar用 AsyncStorage 存令牌不安全SecureStore完全不考虑离线地铁里应用直接崩溃一开始就规划所有项目用同一套栈不适应具体场景按项目评估仓库中的配套佐证反模式清单的体系化呼应这张表与 .agent/skills/mobile-design/SKILL.md 的 AI MOBILE ANTI-PATTERNS 清单性能罪、触控/UX 罪、安全罪、架构罪四大类以及mobile-design-thinking.md的 AI MOBILE SAFE HARBOR 默认模式警告Tab bar 就用到底、Redux 到处都是、FlatList 一律默认等构成了完整的反默认防御体系。三者共同传达的核心信息是选型必须基于项目上下文而非训练数据中的流行默认值。按项目评估与智能体架构的配合.agent/ARCHITECTURE.md中 16 个专职智能体按领域拆分mobile-developer用mobile-design技能其设计意图正是让每个决策都发生在对应的上下文里避免同一套栈套用所有项目。十、快速参考Quick Reference框架快速选择需要 OTA → React Native Expo 需要双端一致 UI → Flutter 追求极致性能 → 原生 有 Web 团队 → React Native 快速原型 → Expo状态管理快速选择简单应用 → Zustand / Provider 服务端数据为主 → TanStack Query / Riverpod 企业级 → Redux / BLoC 原子化状态 → Jotai存储快速选择密钥类 → SecureStore / Keychain 设置项 → AsyncStorage / UserDefaults 结构化数据 → SQLite API 缓存 → Query 库结语决策树是思考框架不是答案库原文档在结尾给出了最重要的提醒值得在落地时反复回味Remember:These trees are guides for THINKING, not rules to follow blindly. Every project has unique constraints. ASK clarifying questions when requirements are vague, and choose based on actual needs, not defaults.结合仓库中与之配套的 .agent/skills/mobile-design/mobile-design-thinking.md 与 .agent/skills/mobile-design/SKILL.md可以提炼出完整的落地方法先用本文的决策树锚定该选什么的方向再用思考协议对每个默认选择提出质疑为什么选它有没有替代性能影响是什么平台差异在哪最后用澄清问题确认项目真实约束。这套决策树 反默认质疑 澄清提问的组合正是让移动端架构选型从拍脑袋走向可论证的关键路径。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐ag-kit 移动端技术选型决策树框架、状态管理、存储与离线架构实战指南ag kit 移动端技术选型决策树框架、状态管理、存储与离线架构实战指南 本指南基于 ag kit 仓库 .agents/skills/mobile desi人工智能AI 技能react-slingshot 前端架构决策框架系统化技术选型react slingshot 前端架构决策框架系统化技术选型 你是否曾在前端项目初始化时陷入技术选型困境面对React生态中数十种状态管理方案、构建工前端示例工程前端架构决策指南MDN Learning Area技术选型框架与方法前端架构决策指南MDN Learning Area技术选型框架与方法 前端架构决策直接影响产品性能、可维护性及用户体验。MDN Learning Area作为教程示例工程上一篇3大技术突破开源散热控制器如何彻底改变Dell笔记本性能下一篇PaddleSpeech LibriSpeech 实战U2Transformer/ConformerASR 完整训练、评测与推理指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
