项目简介

这是一个基于微信生态的剧本杀拼团平台。通过微信小程序和服务号，充分利用微信生态的传播优势，让玩家可以快速组队，让线下剧本杀店更轻松地扩展客源。

项目预览

首页	我的
附近的团	拼车详情

幕后花絮

这是我的第一个微信小程序项目，也是一次全新的挑战：在此之前我并未系统的学习过网页开发（HTML、CSS、Typescript）和任何前端开发框架。

幸运的是，这个项目刚启动时，我有相对充裕的学习时间，和自由发挥的空间。让我得以真正从零到一，完成了整个项目的基础架构和工程化构建。

我也将之前 Flutter 开发移动端 APP 时积累的经验，迁移运用到了这个项目中。

虽然前期架构费了点功夫，但磨刀不误砍柴工，在后来的业务快速迭代中，它带来了极高的开发效率，交付质量和稳定性，时刻保持最佳的性能和用户体验。

主要贡献

1. 完善的基础设施建设

应用层面：封装常用的业务组件库、状态管理、页面路由、网络请求、local/remote 存储和日志监控等模块。这些模块按照复用程度划分为 Common 和 Application 两个层级。Common 下存放的是企业内部可以跨项目使用的公共模块，比如基础的 utils, hooks 和 components 等。而 Application 下存放的则是当前项目相关的一些业务模块，比如一些定制的小组件等。
工程化层面：包括使用 ESlint、Prettier 统一代码风格和格式化规则；配置 husky、lintstage 和 commitlint 规范成员 commit msg，提交代码时自动检测代码缺陷和敏感信息；模块按功能和类别划分目录，方便成员查阅和取用；
CI/CD 层面：此项目构建时有 toB、toC 两个 target，通过编写自动构建脚本和 CLI，在构建过程中剔除不相关的模块，自动优化分包产物体积，简化打包流程，降低手动构建带来的出错概率。

2. 超丝滑的虚拟列表

由于微信小程序存在 DOM 数量上限（最大 16000 个，超出会提示：Dom limit exceeded, please check if there's any mistake you've made.），在处理一些长列表（或无限加载列表）的业务场景时，往往会超出这个限制。对此，使用虚拟列表是一个可行的解决方案。

但传统的虚拟列表方案，在微信小程序容器内的性能表现并不理想：当页面快速滑动时，会出现明显的白屏问题，给人带来卡顿的感觉。这是由于微信小程序容器的双线程模型，渲染线程与 JS 业务逻辑线程是相互独立的，二者之间的通讯效率远低于正常的浏览器环境。当用户快速滑动页面时，虚拟列表频繁更新，视图层的响应速度跟不上用户实际的滑动距离，导致白屏现象的发生。

针对上述问题和成因分析，我在原始虚拟列表的基础上，通过 Page + Item 双重数组批量更新的方式，降低了虚拟列表更新时页面的刷新数据量，从而提高列表刷新性能。除此之外，原始列表的 item 组件并不需要采取任何额外的处理，而且还支持 item 动态高度。

经过线上真实场景实践，在中端机型上快速滚动列表时，白屏现象由原来的稍微大幅滚动，就出现半屏或全屏白屏，变为即使以手机最快速度滑动，虚拟列表也只有上下 10% 区域的轻微白屏，提升效果显著（10x），几乎可以媲美「美团小程序」首页列表滚动效果（我用过的长列表性能做的最好的小程序）。

3. 自定义首页 Tab 组件

虽然微信小程序提供了底部 Tab 组件，但是存在一些问题：

Tab 首次切换时会有短暂的白屏（分包加载过程）。
样式自定义程度不高，比如无法调整间距和消息红点样式等。

为此，我封装了一个与原生 Tab 接口基本保持一致的组件，可以实现 Tab 切换时无闪烁（白屏）和完全自定义的组件样式。

实现原理也非常简单，就是一个堆叠的 Stack 布局，通过控制 Page 的 zIndex 和 visibility 来控制显示内容的切换，优点是只需操作 CSS 属性值，无需 rebuild 整个页面，降低 Tab 切换开销。

4. 高还原度的海报合成

众所周知，在微信小程序里实时绘制分享海报是比较麻烦的。在我们的业务场景里，设计给出的分享海报图片包含行列，层叠，圆角，渐变等多种布局属性，相比其他的简单布局要复杂一些。经过和设计的沟通与协作，最后还是攻克了这个问题，实现了相对完美的排版效果。

分享海报