立项背景与目标:Dokki 面向当代年轻人真实社交需求,解决线上尬聊、无效社交的问题,通过线下活动结伴,让用户在运动、聚会、旅行等具体场景中建立真实连接。目标是打造一个轻量、真实、有温度的线下社交组局平台。
软件功能与核心模块介绍:核心包括活动发现、活动发布、报名管理、匹配推荐、即时沟通等模块,用户可以加入热门活动,也可一键发起局;并通过兴趣标签、好友邀请、活动打卡、评价沉淀等形成持续的社交资产。
业务流程与功能路径:用户注册→选择兴趣→浏览推荐活动→参与或发布活动→线下组局体验→活动结束反馈→平台通过兴趣与行为再优化推荐,形成“发现—参加—结识—留存”的闭环。
1)整体架构与设计思路
1.多端分层:
App:Flutter(Provider做状态管理,Dio 网络,GoRouter 路由,Intl 多语言,SQLite 本地缓存)。
小程序:Taro 4(React 语法,taro-request 封装,taro-ui 组件,mobx 等轻量状态)。
2.Web:React(TypeScript,Next.js,TailwindCSS)。
服务层:统一 API 网关(REST),JWT/Token 鉴权;对象存储做图片与视频;CDN 做加速。
3.设计思路:
以“活动”为核心聚合用户与内容;组件库抽象“活动卡片、报名流程、聊天入口、评价卡”等跨端可复用 UI 模块;保障多端一致的主题与动效。
4.工程化:
ESLint/Prettier/Commitlint 规范;GitHub Actions 做 CI;Sentry 埋点;
2)我负责的模块与结果
1.活动发布与报名流(App + 小程序 + Web):搭建“发起→审核→报名→核销”闭环,表单校验与并发提交防抖。
结果:活动转化率从 12% → 21%(+9pp),错误提交率 -43%。
2.即时沟通与通知:封装聊天室组件与系统通知中心(本地通知 + 小程序订阅消息)。
结果:活动成团率 +18%,人均消息数 +35%。
3.性能优化:
Flutter:长列表分片渲染、图片预取与缓存、首屏骨架屏;
Web:路由按需、资源切分与懒加载、指标追踪。
3)难点/坑与解决方案
1.多端一致性(Flutter vs Taro vs React)
难点:同一业务流程在不同端的能力差异与组件表现不一致。
方案:UI 层做端适配,逻辑层共享。
2.长列表卡顿与图片闪烁
难点:活动瀑布流、头像与海报大量加载。
方案:App 使用 CachedNetworkImage + 占位骨架;Web 用 懒加载 + 响应式图;列表虚拟化。
3.搜索与推荐的精准度
难点:兴趣标签稀疏、冷启动推荐不准。
方案:建立“兴趣 × 地理 × 时间窗”的多维权重;新用户采用热门+地理近邻混排;活动后评价进入特征回填。
4.表单并发与重复支付
难点:高峰报名造成重复点击与并发写入。
方案:前端按钮去抖;支付回调与前端状态解耦,确保“只成功一次”。
5.SEO 与首屏体验(Web)
难点:客户端渲染导致 SEO 弱、首屏慢。
方案:重要页面 SSR;关键资源预加载,路由级代码分割;监测 LCP/FID/CWV 指标并持续优化。