ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

easy-vibe 跨平台实战:用 Flutter 从 0 到 1 开发门店费用簿应用

easy-vibe 跨平台实战:用 Flutter 从 0 到 1 开发门店费用簿应用 教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载本指南以 easy-vibe 项目第三阶段「跨平台开发」中的 Flutter 实战教程为骨架从空项目出发用一套 Dart 代码搭建一个可运行的门店费用簿原型完整跑通「录入 → 字段校验 → 本机保存 → 刷新恢复」这条核心链路。读完本文你将掌握 Flutter/Dart 的分工、环境检查与项目创建流程、表单校验与持久化方案以及analyze/test/build三条自动化验证命令的真实用法与发布边界。为什么选 FlutterDart 与框架的分工第一次接触 Flutter 时先要把两个名字分开理解Dart是编写页面、状态和业务逻辑的语言Flutter是界面框架和开发工具提供 Widget、渲染、调试、测试和各平台构建能力。Flutter 不是把网页套进手机外壳。发布到 Android 或 iOS 时应用会包含 Flutter 引擎并通过平台嵌入层接入系统相机、定位、通知和本地存储等常用能力通常通过插件使用插件未覆盖的能力还可以用 Kotlin 或 Swift 编写平台代码。对本教程要做的「门店费用簿」来说Flutter 的吸引力不只是少写一套界面Android 与 iOS 两端流程基本相同又希望颜色、间距、动画和组件保持一致Flutter 能让团队共用设计和业务实现。反过来如果产品长期依赖大量 Android 或 Apple 独有能力、两端交互差异很大原生 Compose 和 SwiftUI 往往更直接。easy-vibe 项目在跨平台技术选型章节中对这类取舍有更系统的对比。对产品团队而言Flutter 比较适合这些情况Android 和 iOS 的主要页面与业务流程接近团队准备从零做会员、交易、内容、门店或企业内部应用产品有自己的设计系统希望两端视觉一致除了手机以后还可能提供 Web 或桌面版本团队愿意学习 Dart并保留少量 Kotlin、Swift 的接入能力。如果产品只是已有网站的简单包装可以优先考虑 PWA仓库中对应的实践见 PWA 本地应用教程如果最重要的是蓝牙、车机、系统扩展、后台音视频或最新平台 API则应先用一个关键功能原型对比 Flutter 与原生方案不要只凭「一套代码」决定长期架构。三个已上线的 Flutter 应用教我们什么教程先带我们看三个真实产品My BMW、Google Pay 和 Nubank。它们面向的用户完全不同却都在正式产品中使用了 Flutter其页面状态安排、已有功能迁移方式和测试组织为后面的费用簿提供了直接参考。My BMW先让用户看见当前状态BMW 曾发现 iOS 与 Android 车主应用的功能和设计差距越来越大同时还要维护不同品牌、系统和四十多个市场的版本后来用 Flutter 建立统一移动平台My BMW App 于 2020 年发布并扩展到 47 个国家。据 Flutter 官方案例记录它的流水线每天自动构建、测试和部署多个变体而不是让一套源码替代发布工程。这个案例最值得借鉴的不是汽车界面而是两个做法用户先看见当前状态再决定下一步操作团队按业务领域拆模块同时自动验证不同市场和平台的构建。门店费用簿也遵循同样的思路首页先显示本月金额、备用金、最后同步时间和待同步数量然后才是明细和「记一笔」按钮绝不把「同步成功」藏在日志里。Google Pay先跑通一条可以验收的流程Google Pay 原来的 Android 和 iOS 实现合计约 170 万行代码。据 Flutter 官方案例记录迁移前团队先让三名资深工程师做首页、聊天和支付的纵向原型把关键原生插件也放进去验证得到反馈后才逐步扩大到正式重写新代码库约 110 万行工程投入减少约 60% 到 70%但安全审查和平台接入并没有因此消失。这个案例给费用簿的直接提醒是先跑通一条可以验收的流程第一版只做「看汇总 → 录入费用 → 看到错误或成功反馈 → 刷新后恢复」不顺手加入审批、报销、角色和云同步。涉及付款、工单或费用的场景点击按钮后不能毫无反应也不能因重试生成两条相同记录——费用簿用字段旁的错误文字、保存成功提示和「待同步」状态把结果说清楚。Nubank用标准比较取代跟风迁移巴西数字银行 Nubank 没有因为 Flutter 热门就直接迁移。据 Flutter 官方案例记录团队先用 11 项标准比较 Kotlin Native、React Native 和 Flutter还让不同经验的开发者完成一小时任务并收集反馈选定 Flutter 后新功能逐步采用、旧功能按计划迁移随后建立自己的设计系统并把单元、组件和端到端测试纳入开发方式。费用簿没有照抄 Nubank 的紫色银行界面而是借用它的工程做法整页颜色由主题统一汇总卡、预算、费用行和同步提示拆成小组件表单规则有单独的可见反馈最常用的「打开首页和录入表单」写成 Widget Test。三个案例放在一起方向就很明确了Flutter 省下的是重复实现不是产品判断、平台适配、测试和发布流程。环境准备先跑 flutter doctor再看本机缺什么安装 Flutter 后第一件事不是让 AI 改一串环境变量而是运行诊断命令flutter doctor -v然后把检查结果交给 AI让它只告诉你第一个必须修复的问题修完一项再重新检查。注意Web 旁边出现对勾不代表 Android SDK 和 iOS 签名也已经准备好。教程的实际验证环境是Flutter 3.44.9、Dart 3.12.2 和 Chrome 151。当时flutter doctor -v显示Chrome 可以使用但本机没有 Android SDKXcode 已安装却没有可用的 iOS Simulator RuntimeCocoaPods 也没有安装。因此教程中的截图全部来自实际运行的 Flutter Web 构建没有冒充 Android 模拟器或 iPhone 真机——这一点在中文完整版教程中有明确交代。创建项目先跑通空白页再写业务在准备存放项目的目录执行flutter create store_expense_flutter cd store_expense_flutter flutter devices flutter run -d chromeflutter devices会列出当前真正能用的目标。看到 Chrome 不等于手机环境已经完成Android Emulator 和 iOS Simulator 也应分别出现在列表里教程环境里它们确实没有就绪。如果空白项目没有启动只把第一段有效错误交给 AI让它只修复启动问题先确认计数器模板能运行再开始写费用簿这样后面出错时你能判断问题来自业务修改而非 SDK 或设备配置。首页与表单从演示数据到「记一笔」第一轮只使用演示数据把首页改成「门店费用簿」显示本月金额、备用金、最近费用和「记一笔」按钮。此时先看信息顺序不要急着接数据库——打开页面后店长应该马上看见总额、预算和最近几笔记录主要按钮只有一个颜色和字号可以调整但不要用五六种卡片同时抢注意力。随后把离线和同步状态摆到页面上。成熟应用不会用一个转圈图标代替所有状态至少分清「已经存在本机」和「已经到达服务器」两件事。教程实际构建并打开的首页如下这张图来自 Chrome 中运行的 Flutter Web 生产构建顶部写着最后同步时间和待同步数量费用行也标记了「待同步」而不是只在控制台打印一条日志。需要说明的是当前版本没有真实服务器「待同步」只是清楚表达产品状态不能据此宣称云端同步已经完成。首页稳定以后再增加一个最小表单点击「记一笔」时打开底部表单只填写费用说明和金额。底部表单适合短任务因为用户还能看见原来的页面字段变多、需要拍照或审批信息时就应该换成完整页面不要把所有内容硬塞进一个弹层。校验与保存不要让「保存」按钮静悄悄地失败这一轮只处理错误反馈费用说明不能为空金额必须大于 0保存失败时把原因写在对应字段下面。实际点击空表单的「保存到本机」以后两个字段会变红并分别说明缺少什么这里没有只写「参数错误」也没有弹出一个马上消失的统一提示——用户能在出错的位置直接修改。接着补保存成功反馈保存成功后关闭表单、把新记录放到列表顶部并明确告诉用户已经保存在本机教程实测输入「打印纸」和金额56后金额从 ¥890.50 变为 ¥946.50待同步数量从 1 变为 2列表顶部出现新记录底部同时显示「已保存在本机联网后再同步」。这类反馈看起来只是文案却能避免用户因为不确定而连续点五次以后接真实后端还要让服务端识别重复提交不能只靠按钮暂时禁用。数据保留关闭应用以后记录还要回来少量演示数据可以先使用shared_preferences费用列表序列化后保存在本机flutter pub add shared_preferences然后只给 AI 一个目标「请把费用记录保存在本机。页面刷新或应用重启后新记录仍然存在。」教程保存「打印纸 ¥56」后重新加载了整个 Web 应用刷新后的首页仍能看到这笔记录——这一步验证的是本机持久化不是服务器同步。需要明确边界shared_preferences适合设置和少量简单值不适合大量费用、附件、查询和事务。产品继续扩大时应该换成数据库并把数据层放进 Repository架构拆分可以参考教程「按 View、ViewModel、Repository 和 Service 说明费用簿应该怎样拆分」的做法View 负责显示和交互ViewModel 保存界面状态与操作Repository 作为数据来源入口Service 封装本机数据库、REST API 或平台能力。不要为了看起来「企业级」一开始创建几十个空目录先让费用列表、录入和同步真正产生不同职责再逐步拆开。自适应、平台能力与测试自适应布局同一套界面不等于把手机页面横向拉长。教程原型在宽窗口中限制了内容宽度避免汇总卡和表单从屏幕左边一直拉到右边随后分别拖动浏览器窗口、旋转模拟器并打开系统大字体来验证。不要根据「这是手机还是平板」写死页面建议先抽出共用信息、测量当前可用空间、再选择布局如果平板以后要同时显示门店列表和费用明细再把底部导航改成侧边导航或双栏布局。平台能力真实费用应用可能需要拍小票、扫描发票或使用生物认证。先查有没有维护正常、支持目标平台的插件再用最小原型验证权限、异常和生命周期。插件不支持某个能力时可以用 Platform Channel 调用 Kotlin、Java、Swift 或 Objective-C——跨平台不是禁止原生代码而是把原生代码控制在真正需要的位置。自动化验证先跑静态分析和现有测试flutter analyze flutter test再让 AI 增加一条用户流程 Widget Test打开首页、点击「记一笔」、确认费用说明、金额和保存按钮出现表单校验稳定后再补「空表单不能保存并能看见两个错误提示」。教程临时项目的实际结果是flutter analyze没有发现问题Widget Test 通过 1 项验证了首页能够显示并打开录入表单空表单提示和本机恢复是通过浏览器实际操作验证的尚未写成完整自动化测试——教程没有把它们冒充成测试套件已覆盖。项目扩大后费用计算和 ViewModel 适合单元测试页面状态适合 Widget Test登录、上传、离线恢复和同步适合集成测试。构建与发布Web、Android、iOS 是三条独立流水线Web 生产构建可以运行flutter build web教程实际执行成功产物生成在build/web随后通过本地静态服务器打开这个生产构建完成录入、错误反馈、保存和刷新恢复测试——不要直接双击 HTML 文件来验证。Android 上架一般生成 App Bundleflutter build appbundle它仍然需要 Android SDK、应用编号、版本号、发布签名和商店配置。iOS 发布在 Mac 上完成flutter build ipa它需要 Xcode、签名证书、Provisioning Profile、唯一 Bundle ID 和商店账号配置生成 IPA 只是开始后面还要上传、测试并提交审核。两个商店的隐私说明、截图、审核规则和账号都不同推送、内购和登录也有平台政策差异——「一套 Dart 代码」不会生成一个同时提交给两个商店的万能安装包。教程环境flutter doctor找不到 Android SDK、Xcode 没有可用的 iOS Simulator Runtime、项目使用了需要 CocoaPods 的插件决定了 Android 与 iOS 的模拟器/真机验证这一步尚未完成两端的运行截图也不能用 Web 截图替代准备好对应环境后应把 Android 模拟器、iOS 模拟器和至少一台真机的运行截图补进来。从仓库结构看Android 应用教程、iOS 应用教程 和 应用发布章节 分别覆盖了这些平台特有的签名、真机与商店发布细节可作为下一步验证的依据。结语一笔费用能保存和恢复原型才算跑通回到教程的验收标准这个费用簿不只是几张静态卡片——空表单会告诉用户哪里不对保存以后汇总和列表一起更新页面明确区分本机保存与服务器同步刷新整个应用后新记录还在。下一步不必急着加图表和十几个入口。如果准备给真实门店试用先接一套测试后端只做「上传一笔费用」和「失败后重试」再用两个账号检查门店隔离、用飞行模式检查离线队列等这条链路稳定再增加小票、审批和统计。Flutter 真正省事的地方是 Android 和 iOS 可以共同维护这条业务链路真正不能省的仍然是两端设备、权限、签名、商店和失败场景的逐项验证。完整的中文主教程见 docs/zh-cn/stage-3/cross-platform/flutter-app/index.md阿拉伯语版对应文档为 docs/ar-sa/stage-3/cross-platform/flutter-app/index.md两者共用同一套运行截图资源。赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐easy-vibe 跨平台实战用 Flutter 与 Vibe Coding 从零构建门店费用簿应用easy vibe 跨平台实战用 Flutter 与 Vibe Coding 从零构建门店费用簿应用 本文是 easy vibe 教程「高级开发 · 跨平台」教程文档人工智能Vibe Coding用 Flutter 开发跨平台应用从门店费用簿原型到可验证的多端构建用 Flutter 开发跨平台应用从门店费用簿原型到可验证的多端构建 Flutter 可以用一套 Dart 代码同时产出 Android、iOS 与 Web教程文档人工智能Vibe CodingAvalonia桌面应用开发完整项目实战Avalonia桌面应用开发完整项目实战 还在为跨平台桌面应用开发而烦恼想要一套代码同时运行在Windows、macOS和Linux上Avalonia U跨平台桌面应用UI组件上一篇告别枯燥报表Metabase可视化让数据会说话下一篇WinUtil终极指南从入门到精通的Windows优化神器创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表