WiseArt 项目深挖面试知识点整理

整理自项目模拟面试，覆盖 AI 生图任务链路、AI 写真素材上传、Firebase Storage 与 CDN 图片加载、图片压缩、订阅与积分购买、订阅有效性校验与项目难点

一、WiseArt 这个项目的核心技术链路是什么

一句话

• 这是一个 AI 生图应用，核心链路不是“点一下直接出图”，而是 参数组装 -> 创建生成任务 -> 轮询状态 -> 结果落库 -> 页面与历史记录更新。

为什么要做成任务化

• AI 生图是耗时异步任务，不适合按普通同步接口处理
• 需要处理生成中、成功、失败、超时、重试、中断、后台恢复等状态
• 还要把订阅、积分、广告解锁、免费次数这些商业化规则统一收口

客户端的主要职责

1. 收集 prompt、style、pose、会员/积分状态
2. 在本地先注册一个任务并落库
3. 调服务端创建生图任务，拿到 job_id
4. 根据 job_id 轮询结果
5. 成功后把图片结果写回本地任务
6. 驱动结果页、历史页和通知更新

二、文生图的核心代码逻辑是什么

入口层

• 文生图页面在 ArtsActivity
• 用户输入 prompt、选择 style 后，会组装 DrawParameter
• 然后交给 ArtGenerateLauncher.generate(...)

业务编排层

• ArtGenerateLauncher 不只是发请求
• 它会先判断用户走哪种生成路径：
• 会员直出
• 积分生成
• 激励广告解锁生成
• 最终都会统一走：
• ArtTaskMgr.registerTask(...)
• ArtTaskMgr.send(...)

任务管理层

• ArtTaskMgr 会把一次生成抽象成 ArtTaskEntity
• 任务里会保存：
• 来源 from
• 参数 JSON parameter
• 任务类型 task_type
• 服务端任务 ID task_server_id
• 状态 task_status
• 失败原因 task_fail_type
• 图片结果 image_urls

网络层

• 文生图提交接口是 /image/sd/txt2img
• 查询接口是 /image/sd/img
• 先提交生成请求拿 job_id
• 再根据 job_id 轮询结果

状态轮询层

• ArtDataSource.queryNet(...) 负责轮询
• 前台 2 秒一轮，后台 5 秒一轮
• 文生图最长超时 10 分钟
• 成功后会预拉取图片，确认资源可用，再更新数据库和 UI

这样设计的价值

• 页面退出后任务不丢
• 支持后台恢复和系统通知
• 失败、超时、重试、中断都能统一管理

三、AI 写真是如何做的，是否需要上传用户人脸

先说结论

• AI 写真需要先上传用户的人脸照片，而且通常不是只传一张，而是先做一轮人脸素材准备，再基于这些素材生成写真。

为什么不是生成时临时传一张图

• 写真通常依赖多张人脸素材做更稳定的人像特征建模
• 一次上传后，后续换不同 style、pose 时可以直接复用
• 能减少重复上传成本，也更利于服务端做素材管理

素材上传链路

1. 用户选择多张照片
2. 客户端先做本地压缩
3. 做基础人脸检测和质量判断
4. 上传到 Firebase Storage
5. 服务端/客户端用 faceUploaded 标记素材是否已经准备好

生成时传了什么

• 写真生成时并不会再把图片 URL 直接塞进生成参数
• PhotosParameter 主要传：
• style_id
• pose_id
• is_pro
• is_free
• use_credit
• 说明写真生成依赖的是服务端已经准备好的用户素材

边界场景

• 如果服务端返回 SERVER_STORAGE_EMPTY
• 客户端会把本地 faceUploaded 置回 false
• 并重新拉取素材状态
• 说明生成链路和素材链路之间有状态校验

四、图片上传前是如何压缩的

一句话

• 项目里的图片压缩主要发生在上传前，不是展示时再压。

用的是什么方案

• 统一走项目内置的 thirdlib.compressor.Compressor
• 它会先把原图复制到缓存目录
• 再按约束逐步压缩直到满足条件

AI 写真人脸图的压缩策略

• 在 FaceUploadManager 里：
• maxResolution(720)
• format(Bitmap.CompressFormat.WEBP, 90)

AI 滤镜上传图的压缩策略

• 在 FilterUploadManager 里：
• maxResolution(1024)
• format(Bitmap.CompressFormat.WEBP, 90)

为什么这样做

• 降低上传耗时和失败率
• 减少带宽和存储成本
• 控制服务端处理压力
• 兼顾结果质量和上传体验

五、图片都是用 Firebase Storage 吗，是怎么加载的

先说结论

• 上传和存储层大量使用 Firebase Storage
• 但线上展示主链路大多不是直接用 Firebase SDK 读图，而是通过 CDN URL + Glide 加载

存储侧

• 人脸图、滤镜图这类素材上传时，会写入 Firebase Storage bucket
• 客户端本地只保存 storagePath

展示侧

• 展示图片时，客户端会把 storagePath 拼成 CDN 地址
• 然后统一交给 Glide 加载
• 主要通过这些扩展方法：
• loadStorage
• loadStorageBitmap
• cacheStorage
• cacheStorageInto

为什么线上更倾向 CDN

• 更适合图片分发，边缘缓存能力更强
• 加载链路更统一，业务层只需要关心 path
• 更方便做图片请求监控和埋点

自定义 Firebase Loader 的角色

• 项目里保留了 SingleFirebaseImageLoader
• 允许 Glide 直接 load(StorageReference)
• 它更像能力补充或兜底方案
• 但线上主链路主要还是走 CDN URL

六、Glide 加载是否用了自定义 loader 和 target

自定义 loader

• 项目注册了自定义 ModelLoader
• 通过 MyAppGlideModule 把 StorageReference -> InputStream 的加载能力接进 Glide
• 具体实现是 SingleFirebaseImageLoader

自定义 target / future target

• 有一个 EmptyViewTarget
• 用于只关心请求生命周期、不关心默认渲染逻辑的场景
• 另外还有 CallbackFutureTarget
• 它包装了 Glide 的 FutureTarget
• 目的是在 submit().get() 这种阻塞式取结果时，仍然能触发失败监听

主要使用场景

• 图片预下载
• 图片缓存
• 分享、保存前拿 Bitmap
• 失败埋点补偿

七、CDN 图片请求状况打点是怎么做的

接入方式

• 在 Glide 的统一图片加载入口里挂 RequestListener
• 即 CDNImageRequestListener
• 只要业务层走公共的 loadStorage / loadStorageBitmap / cacheStorage，就天然带上打点

采集字段

• path：图片路径
• from：请求来源
• display
• download
• cache
• precache
• type：图片类型
• aiphotos
• text2art
• face
• other
• success：是否成功
• error：错误类型

成功上报时机

• 在 onResourceReady 中
• 且只统计 dataSource == REMOTE 的远端成功请求

失败上报时机

• 在 onLoadFailed 中
• 错误会归类为：
• timeout
• http-error_xxx
• img-corrupted
• other

这样做的价值

• 能区分是人脸图、写真图还是文生图请求出问题
• 能区分问题发生在展示、下载还是预缓存阶段
• 更方便看趋势和做线上排查

局限性

• 主要是客户端视角，看不到 CDN 回源和对象存储侧的完整链路
• 成功埋点更偏“远端请求成功率”，不是“用户看到图片的成功率”
• 缺少精确时延信息
• 图片类型依赖路径规则，维护成本较高

八、订阅和积分购买是如何做的

总体思路

• 两条变现链路都接 Google Play Billing
• 但订阅对应持续性的 VIP 权益
• 积分购买对应一次性的 in-app 商品

订阅商品

• 周/月/季套餐
• 同时区分试用版和无试用版 SKU
• 统一由 BillingWrapper 注册、查询商品详情并发起购买

订阅成功后的处理

1. Google Play 返回 purchase
2. 客户端转成 SubsPurchaseModel
3. 调服务端 addOrder(...) 做订单绑定
4. 成功后更新本地 hasBoundVip
5. 合并进当前购买态

积分商品

• 积分包是一次性 in-app 商品
• 比如 wiseart_credit_10

积分成功后的处理

1. Google Play 返回 purchase
2. 客户端转成 InAppPurchaseModel
3. 调服务端 addCredit(...)
4. 服务端返回最新积分余额
5. 客户端用 UsageSp.updateCredit(...) 更新本地余额

最终如何消费

• 会员：is_pro = true
• 积分：use_credit = true
• 免费次数：走 UsageSp 的 usageCount

九、订阅是如何校验有效性的，如何管理有效期

先说结论

• 不是只信 Google Play，也不是只信服务端
• 而是 Google Play 有效订阅 + 服务端已绑定 VIP 两边同时成立，才认为用户是真正的会员

Google Play 侧校验

• 从当前购买记录里筛出 SubsPurchaseModel
• 取 expireTime 最大的一条
• 只要存在这条记录，就认为当前是 GP VIP

服务端侧校验

• 本地缓存 hasBoundVip
• 服务端登录/拉用户信息时，也会返回 is_pro
• 客户端会用服务端结果更新本地绑定状态

有效期怎么管理

• 当前有效期主要取 Google Play 返回的最大 expireTime
• 同时缓存到本地 BillingSp.expires
• 用于页面展示和应用重启后的状态恢复

为什么还要记录“上次同步过的 expireTime”

• 每个订单还会缓存一次 setExpireTimeUpdated(orderId, expireTime)
• 作用是避免把同一个过期时间反复同步给服务端

失效与恢复

• 如果本地发现 GP 已经不是会员，但服务端仍标记 VIP
• 会继续查历史订单并对齐状态
• 如果确认没有有效订阅，会把服务端 VIP 也置掉
• 如果用户有购买历史但本地没恢复出来，也支持通过 recoverVip() 重新绑定

十、这个项目的主要难点是什么

难点 1：AI 生图链路天然是异步长链路

• 不能按普通同步接口开发
• 必须处理任务创建、轮询、超时、失败、重试、后台恢复、通知这些完整状态

难点 2：商业化规则和生成链路耦合度高

• 生成前要判断会员、积分、广告解锁、免费次数
• 生成后又要正确消费权益
• 订阅状态、积分余额、使用次数还分别来自 Google Play、本地和服务端

难点 3：AI 写真依赖素材链路

• 不是只上传一张图就结束
• 需要多张人脸素材、压缩、人脸检测、上传、状态同步
• 素材质量会直接影响最终生成效果

难点 4：图片链路既要稳定又要可观测

• 既要控制图片加载性能
• 又要能做 CDN 请求监控和错误排查
• 所以需要把存储、CDN、Glide 加载和埋点串成统一方案

更适合面试的总结

• 这个项目最大的难点不是某一个技术点特别深
• 而是它是一个“AI 生成 + 素材上传 + 商业化 + 图片分发”多链路耦合的产品
• 真正难的是把这些复杂性收口成一个稳定、可维护、用户体验又足够顺的整体方案