卡顿的本质

iOS 屏幕每 16.67ms 刷新一次（120Hz 设备是 8.33ms）。一帧内的工作没做完，就会错过刷新，表现为掉帧。所以排查卡顿，核心就一个问题：这一帧的时间被谁用掉了？

拆开来看只有三个环节：主线程、渲染、GPU。

第一问：主线程忙不忙？

主线程负责布局、图片解码、文本排版。这些事任何一件超过 16ms，直接掉帧。

常见的大头：

• Auto Layout：复杂视图层级下约束求解很慢，列表滚动时反复触发更严重。
• 图片解码：不预先解码，第一次显示时主线程解码，大图直接破帧。
• 圆角和阴影：会触发离屏渲染，CPU 要先画一份额外图像再合成。
• 富文本排版：多行文本、动态字体，排版计算不便宜。

怎么解决？原则只有一个：能提前做的别拖到主线程当下做。图片异步解码、圆角预先画好、布局结果缓存、文本排版预计算。

第二问：渲染准备有没有坑？

主线程干完活，Core Animation 要把更新打包交给 GPU。这一步的坑比较隐蔽：

• 视图层级太深：几十层 view 叠在一起，每层都有固定成本。
• 半透明太多：透明视图需要混合计算，大面积叠加会明显变慢。
• 重写了 drawRect：一旦重写，就绕开 GPU 走 CPU 绘制，能不用就不用。

排查方法很简单，Simulator 里打开 Color Blended Layers，绿色正常，红色就是要优化的混合区域，让红色尽量消失。

第三问：GPU 扛得住吗？

GPU 的负载看两个数：设备利用率和 Tile 利用率。

设备利用率接近 100%，GPU 已经满了；Tile 利用率超过 85%，多半是纹理问题——纹理太大、没压缩、没用 Mipmap。

优化方向：

• 大图用 ASTC 压缩格式
• 不透明 view 设置 isOpaque = true，减少无效绘制
• 减少离屏渲染的触发

别只看 FPS

FPS 是一秒内的平均值，会掩盖问题。一秒内前 30 帧 8ms、后 30 帧 25ms，平均还是 55 FPS，但用户会感到明显卡顿。

真正该关注的是帧间隔的稳定性。单帧延迟的尖峰，才是卡顿的真实来源。高刷设备上尤其明显。

排查顺序

1. 看帧延迟曲线，确认卡顿是周期性还是无规律
2. 看主线程占用，判断是不是 CPU 瓶颈
3. 看 GPU 利用率，判断是不是 GPU 瓶颈
4. 针对具体环节优化，改完对比帧延迟分布，而不是只看 FPS

核心就一句话：每一帧都赶上车，比平均速度好看更重要。

承接各类软件外包开发
✅技术范围
uni‑app /uni‑app‑x
微信小程序｜抖音小程序
App 端（安卓 /iOS）
前端页面｜后端接口｜管理后台
✅可做业务
全新定制开发
项目二次开发
Bug 修复调试
功能迭代、页面改版
接口对接、后台搭建
有需求直接发需求文档 / 原型，快速评估报价工期，高效交付。
联系：15622289461 （微信同号）

uniapp 提供的stripe 支付无法实现，ACH 美国银行支付 ， https://uniapp.dcloud.net.cn/tutorial/app-payment-stripe.html#%E5%BC%80%E9%80%9A

雄安新区周边有没有靠谱的开发个人或者团队，可以长期合作。项目稳定。主要是做公司内部需求开发、报表开发等基本不涉及流程类功能开发。可以联系19933338642

仓库地址 https://gitee.com/tuzhi-open/tuzhi-mobile-open

凸知（Tuzhi） 是一套完整的知识付费解决方案，支持私有化部署，覆盖课程售卖、直播授课、圈子社区、考试测评、分销营销、实物商品等完整业务场景，提供管理后台、移动端（H5 / 微信小程序）、PC 学员端等多端入口，帮助个人 IP、教培机构与品牌商家搭建自有卖课平台。

凸知移动端 是一款基于 uni-app（Vue 2）+ TDesign 开发的知识付费移动端前端，支持 H5 / 微信小程序 多端编译（不支持 App 打包）。覆盖课程点播、直播、专栏、圈子社区、订单支付（前端交互）、优惠券、余额红包、考试答题等完整学习场景。

系统演示：

一、功能特性

• 终端覆盖：电脑端 / 微信公众号（H5）/ 微信小程序多端学习
• 课程内容：图文 / 视频 / 音频 / 专栏售卖，支持试看试听、课件资料与内容保护
• 互动教学：练习 / 考试测评 / 题库 / 试卷库 / 证书 / 表单 / 圈子社区
• 直播能力：直播授课 / 伪直播 / 回放 / 直播带货 / 送礼物 / 发红包
• 营销增长：分销推广 / 优惠券 / 每日签到 / 积分商城 / 付费会员卡 / 组合商品 / 卡密兑换
• 实物商品：商品管理 / 多规格 SKU / 限购设置 / 售后退换
• 交易支付：购物车 / 订单管理 / 余额支付 / 微信支付 / 支付宝支付
• 用户数据：用户管理 / 订阅记录 / 学习分析 / 交易分析 / 订单管理
• 系统安全：页面 DIY 装修 / 云存储 / 短信与消息推送 / 管理员权限 / 版权保护（跑马灯 / 防录屏）

界面预览：

二、系统架构

凸知是一套完整的知识付费系统，由四个部分组成：

凸知终端技术结构：

整体调用链路：移动端 / PC 学员端 / 管理后台 → 后端接口服务（{code, msg, data} 协议）→ MySQL 数据库。

本仓库仅开源移动端前端源码；如需后端服务或管理后台等其余端的源码，需购买商业授权获取，详见「十一、使用许可」与授权价格。

三、技术栈

四、快速开始

环境要求：Node.js >= 14（建议 16/18）、npm

# ① 安装依赖  
npm install  

# ② H5 开发（默认不启用 Mock，对接真实后端；如需 Mock 见「Mock 数据」）  
npm run dev:h5

浏览器访问 http://localhost:8080 即可看到完整页面效果。

微信小程序编译：

# ③ 小程序开发模式（监听编译，产物在 dist/dev/mp-weixin）  
npm run dev:mp-weixin  

# ④ 小程序生产构建（内置 TDesign 适配补丁，产物在 dist/build/mp-weixin）  
npm run build:mp-weixin

用微信开发者工具「导入项目」选择对应产物目录（开发选 dist/dev/mp-weixin，生产选 dist/build/mp-weixin），并在 src/manifest.json 中替换为自己的 appid。

对接真实后端：

1. 修改 src/siteinfo.js 中的 siteroot 为你的后端地址；
2. 在 src/common/request/api_list.js 中核对接口地址与 {code, msg, data} 协议；
3. 微信小程序构建需在 src/manifest.json 中替换为自己的 appid。

五、构建

小程序构建内置 TDesign 适配补丁（scripts/），构建成功后产物在 dist/build/ 下。

⚠️ 注意：当前版本不支持 App 打包，仅支持 H5 与微信小程序两个平台。

六、Mock 数据

• H5 开发模式（NODE_ENV=development）默认关闭，全部走真实后端接口；
• 开启方式：将 src/static/config.js 的 enableMock 改为 true（显式设置优先级最高），或通过 uni.setStorageSync('enableMock', true) / 环境变量 MOCK_ENABLE 切换；
• 覆盖 200+ 接口，fixture 位于 src/mock/data/，按 module/action 路由镜像；
• 未覆盖的接口自动透传真实网络并输出提示；
• Mock 数据由仓库内 mock-crawler 工具采集真实后端响应生成，发布前已做敏感字段脱敏（token/openid/手机号等）。

七、目录结构

src/  
├── pages/        页面（index 主包 + public/app/user/order/course 五个分包，约 100+ 页面）  
│   ├── index/        首页（主包唯一页面，tabBar 入口）  
│   ├── launch/       启动页（加载与参数透传跳转，未在 pages.json 注册）  
│   ├── public/       公共分包：登录 / 注册 / 找回密码 / 协议 / 搜索 / 消息 / 结果页等  
│   ├── app/          业务功能分包：活动 / 圈子 / 考试 / 优惠券 / 积分 / 签到 / 证书 / 分销 / 直播带货等  
│   ├── user/         用户分包：个人中心 / 资产 / 余额 / 地址 / 收藏 / 学习记录 / 订阅 / 红包等  
│   ├── order/        订单分包：订单列表 / 详情 / 提交 / 评价 / 售后 / 物流等  
│   ├── course/       课程分包：课程详情 / 分类 / 专栏 / 小组 / 直播等  
│   └── template/     页面模板（新建页面的三文件拆分参考，未在 pages.json 注册）  
├── components/   组件（tz/ 自研组件库、uview-ui、qiun-data-charts、视频播放器等）  
├── common/       公共层  
│   ├── request/  接口封装（$api 点分路由、统一鉴权/错误处理）  
│   ├── utils/    工具（路由映射、支付、直播、OSS 签名等）  
│   ├── order/    订单状态处理  
│   └── wechat/   微信登录/分享 SDK 封装  
├── mock/         Mock 数据（H5 开发模式默认关闭，开启方式见「六、Mock 数据」）  
├── static/       静态资源  
├── pages.json    页面路由与分包配置  
└── manifest.json 应用配置（appid 等）

八、开发约定

• 页面采用 xxx.vue + js.vue + css.css 三文件拆分（<script src="./js.vue"> + @import "./css.css"），逻辑与样式分离；
• 接口调用统一走 this.$api('module.action', data)，登录态、401 跳转、错误提示由拦截器统一处理；
• 业务组件优先复用 components/tz/ 自研组件库；
• 提交信息遵循 Conventional Commits（feat: / fix: / chore:）。

九、相关链接

十、软件安全

安全问题请通过 Issue（需注明"安全"）或邮件私下报告给项目维护团队，请勿在公开渠道描述可利用的漏洞细节。我们将在确认后尽快修复并同步发布。

十一、使用许可

• 本软件遵循 凸知开源协议 V1.0（非商业用途免费，商业用途需购买商业授权），详见 LICENSE；
• 第三方组件许可声明见 THIRD-PARTY-NOTICES.md（发布前请核对）；

【项目转让/可二开】已上线人才×项目撮合平台｜完整前后端+管理后台，可直接部署运营

正文：

手上有一套已经开发完成并上线的人才/项目双边撮合平台，目前准备整体转让，也接受基于现有系统做二次开发。

当前业务场景是：项目方发布需求 → 程序员/服务方入驻 → 平台审核 → 人工匹配撮合 → 跟进项目。

不是单独卖一个前端模板，项目包含完整的：

Web 前端
后端服务
管理后台
数据库结构
用户/需求等核心业务模块
部署配置
已上线域名及现有项目资产（具体交接范围可谈）

系统目前做的是程序员项目撮合，但底层属于双边供需平台，因此也可以继续二开成：

兼职招聘 / 灵活用工 / 自由职业 / 企业服务 / 本地服务 / 技术外包 / 供需撮合等平台。

为什么转让

个人精力和后续发展方向调整，不准备继续长期运营，所以考虑把完整项目交给真正有需求的人继续做。

适合谁
正准备开发人才、兼职、灵工、接单、撮合类产品的人；
想直接拿现成系统二开，不想从0开发的人；
有获客/运营能力，但缺技术产品的团队；
软件公司/工作室，可作为现成项目底座继续开发。
合作方式

A：整套项目独家转让

完成交易后按照约定交接源码、数据库、后台及部署资料等，不是单纯多份源码授权。

B：基于现有系统二开

如果你正好有类似项目需求，但不想直接买整套，也可以把需求发给我，可以在现有系统基础上修改。

有兴趣可以私聊我，先看线上 Demo 和后台，再决定是否继续谈

• 2020年chromium 83之后不再兼容4.4，app端js engine一直停在基于83的版本。uniapp应该提供“现代”的js引擎，让开发者能按需选择

• 更灵活的针对vue3 patch的方式，让开发者能按需使用，或者定期跟进vue 3 大版本

• vite vue3分包下打包到app，依然还是将js合到一个大的app-service.js中，分包的css也不支持手动配置优化。应该能按照vite的打包配置，拆分（js/css）到各个chunk，应用启动时只加载首页资源，同时可以利用类似link prefetch/module preload的特性，让开发者能按需预载其它页面需要的（静态）资源。以达到最高的加载效率

• uniapp目前还在用着老旧的vite/sass版本，但在cli项目中手动更新至vite 7/sass 1.100 其实是能正常运行的，只是组件库基本都因为过时方式导致过多sass警告信息

。。。

分享一下之前的版本

uniappx 基础脚手架，包含功能：

1. 基础简单的登录示例代码
2. request请求封装
3. 跳转 + 登录白名单/拦截
4. 版本更新(多渠道，应用市场， 蒲公英分发或第三方链接等平台)
5. 文件的上传下载
6. 图像裁剪上传封装
7. 主题的切换，包括明暗主题与自定义主题等

2

三点打包。提示还有一分钟开始打包，然后打到五点。 打包两小时。这是不让下班了