T3 Code 移动应用商店截图自动化用真实应用与种子环境产出可上传的 App Store / Google Play 素材【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code本文面向维护者终端用户请阅读 docs/user完整讲解 T3 Code 仓库中移动应用商店截图 harness 的设计原理与实操方法。这套工具运行真实的移动应用连接三个一次性本地 T3 环境通过正常配对流程和 React Navigation 生产路由完成捕获一条pnpm screenshots:mobile命令即可产出符合 App Store Connect 与 Google Play 上传规格尺寸、宽高比、PNG 格式、文件大小、数量的整套素材。读完本文你将掌握默认矩阵的组成、种子环境的构造原理、全部 CLI 参数、上传资产校验规则以及 GitHub Actions 一键捕获的配置方式。截图的是真实应用不是演示模式这套截图 harness 的核心设计原则是不创建任何截图专用屏幕来重绘应用 UI。所有捕获画面都来自真实的移动应用本身——Home、Thread、ThreadTerminal、ThreadReview、SettingsEnvironments 这些生产路由由 React Navigation 直接打开本地环境卡片来自真实配对的服务器。EXPO_PUBLIC_SHOWCASE1环境变量只做三件事对应实现见 ShowcaseCaptureCoordinator.tsx启用一个不参与渲染的配对/就绪协调器它负责读取原生侧传入的配对 URL、场景名、主题与朝向驱动应用完成与三个临时服务器的配对并在场景渲染稳定后向原生侧写入就绪标记禁用终端自动聚焦确保捕获画面不会出现软件键盘向真实的环境设置SettingsEnvironments屏幕提供确定性的 T3 Connect 发现行——即通过原生启动参数注入配对 URL让三个本地 fixture 以真实环境卡片的形式出现在屏幕上。原生桥接层的实现见 nativeShowcaseScene.tsgetShowcasePairingUrl()、getShowcaseScene()、getShowcaseTheme()、applyShowcaseOrientation()、markShowcaseReady()等能力通过 Expo 的requireOptionalNativeModule(T3NativeControls)桥接iOS 与 Android 各有一套原生实现。值得注意的细节是未知主题 ID 会被读取为null而非静默回退从源码注释看这是刻意为之——a capture never claims to show a theme it does not避免产出标注错误的截图。一条命令捕获默认矩阵在仓库根目录执行pnpm screenshots:mobile该命令定义在根目录 package.json 的screenshots:mobilescript 中node scripts/mobile-showcase.ts。一次完整运行会依次完成以下 8 个阶段与文档描述一一对应调用链可见 mobile-showcase.ts 的main()创建三个临时 T3 base 目录并为每个目录在可用端口启动一个本地服务器startShowcaseServer通过node apps/server/src/bin.ts serve --host 0.0.0.0 --port port --base-dir dir --no-browser拉起创建 T3 Code、React、Linux 三个真实 Git 仓库带可识别的 favicon、feature 分支以及确定性的 T3 Code review diff向每个服务器已迁移的 SQLite 数据库播种数据线程、消息、活动activity、终端历史再额外加入两条等待发送的持久化 mobile-outbox 任务对应 Pending 状态行启动隔离的 Metro 服务器用 Expo clean production prebuild 重新生成并构建所选原生应用然后启动每个设备将每个干净安装的应用与三个环境配对Moonbase Terminal、Suspense Station、Kernel Cabin为每个请求的场景导航到真实应用路由设置系统外观与调色板规范化状态栏iOS 固定 9:41、电量 100%、Wi-Fi 3 格Android 通过 systemui demo 广播固定时钟 09:41、电量 100%把捕获转换为24-bit RGB PNG无 alpha并校验尺寸、宽高比、文件大小与截图数量在artifacts/app-store/screenshots/下写出可直接上传到 App Store Connect 或 Google Play Console 的 store-ready 文件夹。运行结束后servers、Metro、临时根目录与设备都会被清理。若想保留现场检查加--keep-runningrunner 会打印 base-directory 路径和服务器端口。捕获过程会等待真实环境快照水合完成、等待请求的路由变为活动状态——两个平台都会把就绪状态记录在模拟器/模拟器应用容器中iOS 写Library/Caches/T3ShowcaseReadySceneAndroid 通过run-as package cat files/t3-showcase-ready读取。最终还有一个 settle 延迟配置默认settleDelayMs: 2500让原生终端与 Git review 数据完成渲染。默认设备与上传槽位矩阵输出文件夹捕获目标上传尺寸Store 槽位apple/iphone-6.9/dark/t3-code/iPhone 17 Pro Max1320×2868App Store Connect iPhone 6.9-inchapple/iphone-6.5/dark/t3-code/一次性 iPhone 14 Plus1284×2778App Store Connect iPhone 6.5-inchapple/ipad-13/dark/t3-code/iPad Pro 13-inch (M5)2752×2064App Store Connect iPad 13-inch横屏google-play/phone/dark/t3-code/Pixel AVD 420 dpi1080×1920Google Play 手机竖屏 9:16google-play/tablet-7/dark/t3-code/Pixel AVD 600dp 宽1080×1920Google Play 7 英寸平板竖屏 9:16google-play/tablet-10/dark/t3-code/Pixel AVD 800dp 宽1440×2560Google Play 10 英寸平板竖屏 9:16每个目标捕获 5 个场景thread线程详情、terminal终端、review代码评审、threads线程列表、environments环境设置。每个调色板文件夹内的 5 张截图恰好满足各商店的槽位数量规则Apple 限制 1–10 张、Google Play 手机要求 2–8 张、Google 平板推荐/槽位最低 4 张且最多 8 张。每个调色板拥有独立的叶子文件夹保证一个上传槽位绝不混用主题且每个文件夹都保持商店合法的截图数量。输出目录树生成的目录结构与商店上传字段严格对齐artifacts/app-store/screenshots/ ├── apple/ │ ├── iphone-6.9/dark/t3-code/{thread,terminal,review,threads,environments}.png │ ├── iphone-6.5/dark/t3-code/{thread,terminal,review,threads,environments}.png │ └── ipad-13/dark/t3-code/{thread,terminal,review,threads,environments}.png └── google-play/ ├── phone/dark/t3-code/{thread,terminal,review,threads,environments}.png ├── tablet-7/dark/t3-code/{thread,terminal,review,threads,environments}.png └── tablet-10/dark/t3-code/{thread,terminal,review,threads,environments}.png纯浅色运行会写出light/下的同构目录--appearance both同时写出两种外观每个请求的主题在t3-code/旁追加一个兄弟文件夹。种子环境揭秘三个机器、三个仓库、一套确定数据所有截图数据的源头在 mobile-showcase-environment.ts。三个环境被命名为Moonbase Terminal、Suspense Station、Kernel Cabin分别对应三个真实仓库项目项目仓库用途T3 Code主项目线程详情、终端、评审等主场景React伴生项目线程列表中的多样化内容Linux伴生项目线程列表中的多样化内容每个项目都内置了可识别的内联 SVG faviconT3 Code 黑底白字、React 原子图标、Linux 企鹅徽标并创建真实 Git 仓库初始化main分支提交再开出带明显语义的 feature 分支如 T3 Code 的feat/remote-command-center形成有真实 diff 可展示的评审场景。T3 Code 工作区还会写入两个源文件environmentPresence.ts与RemoteHandoffCard.tsx的修改作为 review 场景的确定性 diff 内容。播种阶段会在服务器完成 SQLite 迁移后对projection_projects、projection_threads、projection_turns、projection_thread_messages、projection_thread_activities、projection_thread_sessions、projection_state等投影表做清空重插代码中特意用BEGIN IMMEDIATE 30 秒 busy timeout 处理与运行中服务器的写锁竞争。线程标题、请求/回复文本、活动摘要612 tests passed · 3 environments online 等全部是手工打磨的确定性内容并且时间戳相对捕获启动时刻生成——这样每个路由都能显示稳定的相对时间标签3 分钟前而服务器收到的仍是合法的最新数据。终端场景则直接写入一份精心构造的终端缓冲文件SHOWCASE_TERMINAL_BUFFERzsh 风格提示符、vpr dev启动输出、VITE 版本行、Local/Network 地址、612 passed测试摘要和READY徽标完整覆盖粗体、暗色、下划线、六种强调色与背景色单元格用于在截图中充分展示终端渲染能力。三个环境iPhone、iPad、Android 手机、Android 平板共享同一套确定性数据响应式差异完全来自生产应用布局而不是为不同设备准备不同数据。Pending 行与 Environments 卡片的实现细节截图中的 Pending 任务行使用生产环境的 offline outbox指向真实的 T3 Code 和 React fixture 项目。协调器会在捕获期间把这两条 outbox 条目保持为编辑中holdEditingQueuedMessage模拟任务正在编辑中的真实状态防止重连种子环境后在截图前就把它们投递并移除。Environments 场景把三个本地 fixture transport 呈现为Tailscale HTTPS 主机名、赫尔辛基 VPS 主机名、Tailnet IPv4 地址。这是纯展示级替换harness 通过一个假的scutil/hostnamectl探针createShowcaseLabelProbe生成的脚本向应用提供环境标签让卡片保持远程优先的观感同时底层仍使用可靠的 loopback 连接到临时服务器。设备与捕获矩阵配置所有设备、场景、外观、调色板与输出目录都在 mobile-showcase.config.ts 中集中声明。其核心类型如下ShowcaseConfigoutputDirectory默认artifacts/app-store/screenshots、metroPort固定8199、settleDelayMs默认2500、devices设备数组ShowcaseStoreAssetSpecstoreapple或google-play、directory、width/height、minimumUploadCount/maximumUploadCount、可选maximumFileSizeBytes——每个目标都声明并校验其精确上传尺寸SDK 或模拟器变化无法静默产生非法文件ShowcaseIosDevicesimulatorxcrun simctl list devices available中的精确名称、simulatorDeviceType缺失时用于创建一次性模拟器、appearance、theme、orientation默认竖屏iPad 配置为landscape、scenesShowcaseAndroidDeviceavdemulator -list-avds的精确名称、abi、可选viewport尺寸与 density缺省时用 AVD 原生尺寸。具体到默认矩阵iphone-6.9使用 iPhone 17 Pro Max 模拟器1320×2868最小 1 张/最大 10 张iphone-6.5使用名为 T3 Showcase iPhone 14 Plus 的一次性模拟器——本机没有该模拟器时 runner 会按com.apple.CoreSimulator.SimDeviceType.iPhone-14-Plus设备类型用simctl create现建一个捕获后删除见ensureIosSimulator与清理逻辑ipad-13使用 iPad Pro 13-inch (M5)方向为横屏捕获 2752×2064三个 Android 目标复用同一个Pixel_10_ProAVD仅通过wm size/wm density调整 viewport 来模拟手机1080×1920 420dpi、7 英寸平板1080×1920 288dpi与 10 英寸平板1440×2560 288dpi。Android ABI 通过resolveShowcaseAndroidAbi解析读取环境变量T3_SHOWCASE_ANDROID_ABI缺省返回arm64-v8a本地 Apple Silicon 开发默认仅接受arm64-v8a、x86_64、x86、armeabi-v7a四种取值其余直接抛错。CI 通过把该变量设为x86_64让 debug APK 匹配其 KVM 加速模拟器。可捕获的调色板 ID 来自 themePalettes.ts 的MOBILE_THEME_IDSt3-code、t3-chat、grove、ocean、ember、iris因此harness 与应用的外观设置永远不会漂移——应用新增或移除调色板时截图工具的校验集合自动跟随。修改 mobile-showcase.config.ts 可调整模拟器/AVD 名称、深浅外观、默认调色板、iOS 方向、场景、输出目录、捕获延迟、Android ABI 或 viewport。CLI 参数速查与快速迭代harness 的 CLI 解析实现于 mobile-showcase.ts 的parseShowcaseCliArgs支持的参数如下参数取值说明--platformios、android、all可重复选择平台--device设备 ID可重复选择单个设备未知 ID 报错--scenethreads、thread、terminal、review、environments可重复选择场景--appearancelight、dark、both覆盖配置的外观--theme调色板 ID 或all可重复覆盖配置的调色板未知 ID 直接拒绝--skip-build—复用已有模拟器应用 / debug APK--skip-metro—复用已在运行的 showcase Metro--keep-running—捕获后保留设备与 Metro--validate-only—只校验已有上传资产不启动任何进程--list—打印帮助与配置矩阵只捕获单个场景或设备pnpm screenshots:mobile --device iphone-6.9 --scene thread pnpm screenshots:mobile --platform android --scene review覆盖外观或同时捕获两种变体pnpm screenshots:mobile --appearance light pnpm screenshots:mobile --appearance dark pnpm screenshots:mobile --appearance both捕获其他调色板pnpm screenshots:mobile --device iphone-6.9 --theme ocean pnpm screenshots:mobile --device iphone-6.9 --theme ocean --theme ember pnpm screenshots:mobile --device iphone-6.9 --theme all复用原生构建并保留一次性环境pnpm screenshots:mobile --device ipad-13 --skip-build --keep-running把 Metro 放到独立终端运行默认让 runner 在 8199 端口启动 Metro如需分离在apps/mobile下用相同的 showcase 环境与显式端口启动cd apps/mobile APP_VARIANTdevelopment EXPO_PUBLIC_SHOWCASE1 pnpm exec expo start --dev-client --port 8199然后在仓库根目录执行pnpm screenshots:mobile --skip-build --skip-metro --device iphone-6.9注意pnpm --filter t3tools/mobile showcase会在 Expo 的正常端口启动与 harness 的--skip-metro模式不兼容。查看矩阵与全部参数pnpm screenshots:mobile --list不启动 Metro、服务器、模拟器即可校验已有文件pnpm screenshots:mobile --validate-only pnpm screenshots:mobile --platform ios --validate-only关于 Metro 端口 8199harness 固定使用 Metro 端口8199与 Expo 的常规默认端口隔离但它跨所有 checkout 共享。就绪检查只验证端口已打开、不验证进程归属因此不同 worktree 中的并发截图 harness 可能相互冲突或挂到错误的 Metro 进程上——文档明确提示这是需要留意的前提限制。外观与调色板矩阵默认情况下每个配置的设备都是深色外观 t3-code调色板因此直接执行pnpm screenshots:mobile产出30 张深色 PNG6 目标 × 5 场景。可选值--appearance light/--appearance dark/--appearance bothboth将产出60 张 PNG--theme id可重复或--theme all覆盖为其他调色板——t3-code、t3-chat、grove、ocean、ember、iris。--theme all会把运行次数乘以 6但只有一次原生构建是共享的。调色板的生效机制很严谨runner 把调色板作为启动参数传给应用iOS 通过simctl launch的--showcaseThemeAndroid 通过 intent extrashowcaseTheme应用将其应用到明暗两套色彩方案协调器只在请求的调色板已激活后才报告场景就绪themeIds.light requestedTheme themeIds.dark requestedTheme所以截图永远不会拍到上一个主题。同理场景就绪还要求orientationSettled为真避免在旋转动画未完成时截到错误尺寸。上传资产校验PNG 格式与商店规则捕获文件在落盘前会经过严格的归一化与校验见 mobile-showcase.ts 的normalizeStorePng、validateStoreAsset、validateStoreAssetCount格式使用pngjs把捕获统一重写为8-bit、24-bit RGBcolorType 2、无 alpha的 PNG读取时通过解析 PNG 头校验bitDepth、colorType与hasAlpha尺寸必须与目标storeAsset规格逐像素一致否则捕获直接失败——例如 iPhone 6.9 目标必须恰为 1320×2868Google Play 附加规则短边 ≥ 320px、长边 ≤ 3840px、长边不超过短边的 2 倍且必须严格满足9:16 竖屏宽高比校验表达式为width * 16 height * 9文件大小Google Play 目标配置了maximumFileSizeBytes: 8 * 1024 * 10248MB超限即失败数量每个输出文件夹必须包含全部预期场景文件缺失即失败且总数落在该槽位的minimumUploadCount/maximumUploadCount之间。文档对此的结论是harness 是上传尺寸的唯一事实来源source of truth不要对其输出做 resize。如果商店规则变化应更新对应目标的storeAsset规格。一次完整捕获只有当 PNG 尺寸正确、无 alpha、8-bit RGB、文件大小不超限、不违反 Google Play 的 9:16 形状/边界、且完整输出集不低于商店最小值时才判定成功。--validate-only模式复用同一套校验逻辑适合在不上传前对既有素材做快速体检。GitHub Actions 一键捕获仓库自带Mobile Showcase Screenshots工作流mobile-showcase-screenshots.yml从 GitHub Actions 标签页手动触发workflow_dispatch三个输入platformall、ios或androidappearancelight、dark或boththemet3-code、t3-chat、grove、ocean、ember、iris或all选all时每个 job 的超时从 60 分钟提升到300 分钟。默认分发同时捕获t3-code调色板的明暗两种外观iOS 与 Android 并行iPhone 6.9 / iPhone 6.5 / iPad 13 在 12 vCPU 的 Blacksmith macOS runner 上捕获Android 手机、7 英寸平板、10 英寸平板在 16 vCPU 的 Blacksmith Linux runner 上使用 KVM 加速的 x86_64 模拟器API 36Pixel_10_ProAVD8 核 4GB RAM捕获。工作流的关键容错设计每个 job即使捕获失败也会上传 PNGupload 步骤if: always()部分结果对诊断仍然有用独立的验证步骤是success-gated只有捕获成功才会运行--validate-only捕获失败时always()上传仍会发布部分 PNG但不再重新校验产物从运行页的 Artifacts 区下载名称为app-store-connect-screenshots和google-play-screenshots保留 14 天工作流与本地捕获共用同一套 check-in 的设备和场景矩阵Android job 显式设置T3_SHOWCASE_ANDROID_ABIx86_64使 debug APK 匹配其加速模拟器而本地 Apple Silicon 开发默认保持 ARM64。本地前置条件与注意事项iOS需要 Xcode command-line tools、配置的模拟器运行时simulator runtimes以及已安装的 CocoaPods。AndroidSDK 解析顺序为ANDROID_HOME→ANDROID_SDK_ROOT→ 默认 macOS 的$HOME/Library/Android/sdk或其他平台的$HOME/Android/SdkresolveAndroidSdkRoot的实现同时兼容 Windows 的USERPROFILE。解析出的 SDK 必须提供adb与emulator且配置的 AVD默认Pixel_10_Pro必须已存在。首次完整捕获会用 Expo 的 clean production prebuild 重新生成所选原生工程再构建重复捕获首次构建之后应使用--skip-build加速。小结这套 harness 的价值在于把商店截图从人工摆拍变成了可复现、可校验、可入 CI 的工程化流程种子环境提供确定性数据真实应用与真实配对链路保证截图内容即产品实况storeAsset规格把商店上传约束固化为硬校验--validate-only与 GitHub Actions 则让截图过期/非法这类回归在发布前就被拦截。若需调整设备、场景、外观或调色板修改 mobile-showcase.config.ts 即可若需定制种子项目、线程、对话与 Git 变更则编辑 mobile-showcase-environment.ts整体设备编排逻辑位于 mobile-showcase.ts。【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
T3 Code 移动应用商店截图自动化：用真实应用与种子环境产出可上传的 App Store / Google Play 素材
T3 Code 移动应用商店截图自动化用真实应用与种子环境产出可上传的 App Store / Google Play 素材【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code本文面向维护者终端用户请阅读 docs/user完整讲解 T3 Code 仓库中移动应用商店截图 harness 的设计原理与实操方法。这套工具运行真实的移动应用连接三个一次性本地 T3 环境通过正常配对流程和 React Navigation 生产路由完成捕获一条pnpm screenshots:mobile命令即可产出符合 App Store Connect 与 Google Play 上传规格尺寸、宽高比、PNG 格式、文件大小、数量的整套素材。读完本文你将掌握默认矩阵的组成、种子环境的构造原理、全部 CLI 参数、上传资产校验规则以及 GitHub Actions 一键捕获的配置方式。截图的是真实应用不是演示模式这套截图 harness 的核心设计原则是不创建任何截图专用屏幕来重绘应用 UI。所有捕获画面都来自真实的移动应用本身——Home、Thread、ThreadTerminal、ThreadReview、SettingsEnvironments 这些生产路由由 React Navigation 直接打开本地环境卡片来自真实配对的服务器。EXPO_PUBLIC_SHOWCASE1环境变量只做三件事对应实现见 ShowcaseCaptureCoordinator.tsx启用一个不参与渲染的配对/就绪协调器它负责读取原生侧传入的配对 URL、场景名、主题与朝向驱动应用完成与三个临时服务器的配对并在场景渲染稳定后向原生侧写入就绪标记禁用终端自动聚焦确保捕获画面不会出现软件键盘向真实的环境设置SettingsEnvironments屏幕提供确定性的 T3 Connect 发现行——即通过原生启动参数注入配对 URL让三个本地 fixture 以真实环境卡片的形式出现在屏幕上。原生桥接层的实现见 nativeShowcaseScene.tsgetShowcasePairingUrl()、getShowcaseScene()、getShowcaseTheme()、applyShowcaseOrientation()、markShowcaseReady()等能力通过 Expo 的requireOptionalNativeModule(T3NativeControls)桥接iOS 与 Android 各有一套原生实现。值得注意的细节是未知主题 ID 会被读取为null而非静默回退从源码注释看这是刻意为之——a capture never claims to show a theme it does not避免产出标注错误的截图。一条命令捕获默认矩阵在仓库根目录执行pnpm screenshots:mobile该命令定义在根目录 package.json 的screenshots:mobilescript 中node scripts/mobile-showcase.ts。一次完整运行会依次完成以下 8 个阶段与文档描述一一对应调用链可见 mobile-showcase.ts 的main()创建三个临时 T3 base 目录并为每个目录在可用端口启动一个本地服务器startShowcaseServer通过node apps/server/src/bin.ts serve --host 0.0.0.0 --port port --base-dir dir --no-browser拉起创建 T3 Code、React、Linux 三个真实 Git 仓库带可识别的 favicon、feature 分支以及确定性的 T3 Code review diff向每个服务器已迁移的 SQLite 数据库播种数据线程、消息、活动activity、终端历史再额外加入两条等待发送的持久化 mobile-outbox 任务对应 Pending 状态行启动隔离的 Metro 服务器用 Expo clean production prebuild 重新生成并构建所选原生应用然后启动每个设备将每个干净安装的应用与三个环境配对Moonbase Terminal、Suspense Station、Kernel Cabin为每个请求的场景导航到真实应用路由设置系统外观与调色板规范化状态栏iOS 固定 9:41、电量 100%、Wi-Fi 3 格Android 通过 systemui demo 广播固定时钟 09:41、电量 100%把捕获转换为24-bit RGB PNG无 alpha并校验尺寸、宽高比、文件大小与截图数量在artifacts/app-store/screenshots/下写出可直接上传到 App Store Connect 或 Google Play Console 的 store-ready 文件夹。运行结束后servers、Metro、临时根目录与设备都会被清理。若想保留现场检查加--keep-runningrunner 会打印 base-directory 路径和服务器端口。捕获过程会等待真实环境快照水合完成、等待请求的路由变为活动状态——两个平台都会把就绪状态记录在模拟器/模拟器应用容器中iOS 写Library/Caches/T3ShowcaseReadySceneAndroid 通过run-as package cat files/t3-showcase-ready读取。最终还有一个 settle 延迟配置默认settleDelayMs: 2500让原生终端与 Git review 数据完成渲染。默认设备与上传槽位矩阵输出文件夹捕获目标上传尺寸Store 槽位apple/iphone-6.9/dark/t3-code/iPhone 17 Pro Max1320×2868App Store Connect iPhone 6.9-inchapple/iphone-6.5/dark/t3-code/一次性 iPhone 14 Plus1284×2778App Store Connect iPhone 6.5-inchapple/ipad-13/dark/t3-code/iPad Pro 13-inch (M5)2752×2064App Store Connect iPad 13-inch横屏google-play/phone/dark/t3-code/Pixel AVD 420 dpi1080×1920Google Play 手机竖屏 9:16google-play/tablet-7/dark/t3-code/Pixel AVD 600dp 宽1080×1920Google Play 7 英寸平板竖屏 9:16google-play/tablet-10/dark/t3-code/Pixel AVD 800dp 宽1440×2560Google Play 10 英寸平板竖屏 9:16每个目标捕获 5 个场景thread线程详情、terminal终端、review代码评审、threads线程列表、environments环境设置。每个调色板文件夹内的 5 张截图恰好满足各商店的槽位数量规则Apple 限制 1–10 张、Google Play 手机要求 2–8 张、Google 平板推荐/槽位最低 4 张且最多 8 张。每个调色板拥有独立的叶子文件夹保证一个上传槽位绝不混用主题且每个文件夹都保持商店合法的截图数量。输出目录树生成的目录结构与商店上传字段严格对齐artifacts/app-store/screenshots/ ├── apple/ │ ├── iphone-6.9/dark/t3-code/{thread,terminal,review,threads,environments}.png │ ├── iphone-6.5/dark/t3-code/{thread,terminal,review,threads,environments}.png │ └── ipad-13/dark/t3-code/{thread,terminal,review,threads,environments}.png └── google-play/ ├── phone/dark/t3-code/{thread,terminal,review,threads,environments}.png ├── tablet-7/dark/t3-code/{thread,terminal,review,threads,environments}.png └── tablet-10/dark/t3-code/{thread,terminal,review,threads,environments}.png纯浅色运行会写出light/下的同构目录--appearance both同时写出两种外观每个请求的主题在t3-code/旁追加一个兄弟文件夹。种子环境揭秘三个机器、三个仓库、一套确定数据所有截图数据的源头在 mobile-showcase-environment.ts。三个环境被命名为Moonbase Terminal、Suspense Station、Kernel Cabin分别对应三个真实仓库项目项目仓库用途T3 Code主项目线程详情、终端、评审等主场景React伴生项目线程列表中的多样化内容Linux伴生项目线程列表中的多样化内容每个项目都内置了可识别的内联 SVG faviconT3 Code 黑底白字、React 原子图标、Linux 企鹅徽标并创建真实 Git 仓库初始化main分支提交再开出带明显语义的 feature 分支如 T3 Code 的feat/remote-command-center形成有真实 diff 可展示的评审场景。T3 Code 工作区还会写入两个源文件environmentPresence.ts与RemoteHandoffCard.tsx的修改作为 review 场景的确定性 diff 内容。播种阶段会在服务器完成 SQLite 迁移后对projection_projects、projection_threads、projection_turns、projection_thread_messages、projection_thread_activities、projection_thread_sessions、projection_state等投影表做清空重插代码中特意用BEGIN IMMEDIATE 30 秒 busy timeout 处理与运行中服务器的写锁竞争。线程标题、请求/回复文本、活动摘要612 tests passed · 3 environments online 等全部是手工打磨的确定性内容并且时间戳相对捕获启动时刻生成——这样每个路由都能显示稳定的相对时间标签3 分钟前而服务器收到的仍是合法的最新数据。终端场景则直接写入一份精心构造的终端缓冲文件SHOWCASE_TERMINAL_BUFFERzsh 风格提示符、vpr dev启动输出、VITE 版本行、Local/Network 地址、612 passed测试摘要和READY徽标完整覆盖粗体、暗色、下划线、六种强调色与背景色单元格用于在截图中充分展示终端渲染能力。三个环境iPhone、iPad、Android 手机、Android 平板共享同一套确定性数据响应式差异完全来自生产应用布局而不是为不同设备准备不同数据。Pending 行与 Environments 卡片的实现细节截图中的 Pending 任务行使用生产环境的 offline outbox指向真实的 T3 Code 和 React fixture 项目。协调器会在捕获期间把这两条 outbox 条目保持为编辑中holdEditingQueuedMessage模拟任务正在编辑中的真实状态防止重连种子环境后在截图前就把它们投递并移除。Environments 场景把三个本地 fixture transport 呈现为Tailscale HTTPS 主机名、赫尔辛基 VPS 主机名、Tailnet IPv4 地址。这是纯展示级替换harness 通过一个假的scutil/hostnamectl探针createShowcaseLabelProbe生成的脚本向应用提供环境标签让卡片保持远程优先的观感同时底层仍使用可靠的 loopback 连接到临时服务器。设备与捕获矩阵配置所有设备、场景、外观、调色板与输出目录都在 mobile-showcase.config.ts 中集中声明。其核心类型如下ShowcaseConfigoutputDirectory默认artifacts/app-store/screenshots、metroPort固定8199、settleDelayMs默认2500、devices设备数组ShowcaseStoreAssetSpecstoreapple或google-play、directory、width/height、minimumUploadCount/maximumUploadCount、可选maximumFileSizeBytes——每个目标都声明并校验其精确上传尺寸SDK 或模拟器变化无法静默产生非法文件ShowcaseIosDevicesimulatorxcrun simctl list devices available中的精确名称、simulatorDeviceType缺失时用于创建一次性模拟器、appearance、theme、orientation默认竖屏iPad 配置为landscape、scenesShowcaseAndroidDeviceavdemulator -list-avds的精确名称、abi、可选viewport尺寸与 density缺省时用 AVD 原生尺寸。具体到默认矩阵iphone-6.9使用 iPhone 17 Pro Max 模拟器1320×2868最小 1 张/最大 10 张iphone-6.5使用名为 T3 Showcase iPhone 14 Plus 的一次性模拟器——本机没有该模拟器时 runner 会按com.apple.CoreSimulator.SimDeviceType.iPhone-14-Plus设备类型用simctl create现建一个捕获后删除见ensureIosSimulator与清理逻辑ipad-13使用 iPad Pro 13-inch (M5)方向为横屏捕获 2752×2064三个 Android 目标复用同一个Pixel_10_ProAVD仅通过wm size/wm density调整 viewport 来模拟手机1080×1920 420dpi、7 英寸平板1080×1920 288dpi与 10 英寸平板1440×2560 288dpi。Android ABI 通过resolveShowcaseAndroidAbi解析读取环境变量T3_SHOWCASE_ANDROID_ABI缺省返回arm64-v8a本地 Apple Silicon 开发默认仅接受arm64-v8a、x86_64、x86、armeabi-v7a四种取值其余直接抛错。CI 通过把该变量设为x86_64让 debug APK 匹配其 KVM 加速模拟器。可捕获的调色板 ID 来自 themePalettes.ts 的MOBILE_THEME_IDSt3-code、t3-chat、grove、ocean、ember、iris因此harness 与应用的外观设置永远不会漂移——应用新增或移除调色板时截图工具的校验集合自动跟随。修改 mobile-showcase.config.ts 可调整模拟器/AVD 名称、深浅外观、默认调色板、iOS 方向、场景、输出目录、捕获延迟、Android ABI 或 viewport。CLI 参数速查与快速迭代harness 的 CLI 解析实现于 mobile-showcase.ts 的parseShowcaseCliArgs支持的参数如下参数取值说明--platformios、android、all可重复选择平台--device设备 ID可重复选择单个设备未知 ID 报错--scenethreads、thread、terminal、review、environments可重复选择场景--appearancelight、dark、both覆盖配置的外观--theme调色板 ID 或all可重复覆盖配置的调色板未知 ID 直接拒绝--skip-build—复用已有模拟器应用 / debug APK--skip-metro—复用已在运行的 showcase Metro--keep-running—捕获后保留设备与 Metro--validate-only—只校验已有上传资产不启动任何进程--list—打印帮助与配置矩阵只捕获单个场景或设备pnpm screenshots:mobile --device iphone-6.9 --scene thread pnpm screenshots:mobile --platform android --scene review覆盖外观或同时捕获两种变体pnpm screenshots:mobile --appearance light pnpm screenshots:mobile --appearance dark pnpm screenshots:mobile --appearance both捕获其他调色板pnpm screenshots:mobile --device iphone-6.9 --theme ocean pnpm screenshots:mobile --device iphone-6.9 --theme ocean --theme ember pnpm screenshots:mobile --device iphone-6.9 --theme all复用原生构建并保留一次性环境pnpm screenshots:mobile --device ipad-13 --skip-build --keep-running把 Metro 放到独立终端运行默认让 runner 在 8199 端口启动 Metro如需分离在apps/mobile下用相同的 showcase 环境与显式端口启动cd apps/mobile APP_VARIANTdevelopment EXPO_PUBLIC_SHOWCASE1 pnpm exec expo start --dev-client --port 8199然后在仓库根目录执行pnpm screenshots:mobile --skip-build --skip-metro --device iphone-6.9注意pnpm --filter t3tools/mobile showcase会在 Expo 的正常端口启动与 harness 的--skip-metro模式不兼容。查看矩阵与全部参数pnpm screenshots:mobile --list不启动 Metro、服务器、模拟器即可校验已有文件pnpm screenshots:mobile --validate-only pnpm screenshots:mobile --platform ios --validate-only关于 Metro 端口 8199harness 固定使用 Metro 端口8199与 Expo 的常规默认端口隔离但它跨所有 checkout 共享。就绪检查只验证端口已打开、不验证进程归属因此不同 worktree 中的并发截图 harness 可能相互冲突或挂到错误的 Metro 进程上——文档明确提示这是需要留意的前提限制。外观与调色板矩阵默认情况下每个配置的设备都是深色外观 t3-code调色板因此直接执行pnpm screenshots:mobile产出30 张深色 PNG6 目标 × 5 场景。可选值--appearance light/--appearance dark/--appearance bothboth将产出60 张 PNG--theme id可重复或--theme all覆盖为其他调色板——t3-code、t3-chat、grove、ocean、ember、iris。--theme all会把运行次数乘以 6但只有一次原生构建是共享的。调色板的生效机制很严谨runner 把调色板作为启动参数传给应用iOS 通过simctl launch的--showcaseThemeAndroid 通过 intent extrashowcaseTheme应用将其应用到明暗两套色彩方案协调器只在请求的调色板已激活后才报告场景就绪themeIds.light requestedTheme themeIds.dark requestedTheme所以截图永远不会拍到上一个主题。同理场景就绪还要求orientationSettled为真避免在旋转动画未完成时截到错误尺寸。上传资产校验PNG 格式与商店规则捕获文件在落盘前会经过严格的归一化与校验见 mobile-showcase.ts 的normalizeStorePng、validateStoreAsset、validateStoreAssetCount格式使用pngjs把捕获统一重写为8-bit、24-bit RGBcolorType 2、无 alpha的 PNG读取时通过解析 PNG 头校验bitDepth、colorType与hasAlpha尺寸必须与目标storeAsset规格逐像素一致否则捕获直接失败——例如 iPhone 6.9 目标必须恰为 1320×2868Google Play 附加规则短边 ≥ 320px、长边 ≤ 3840px、长边不超过短边的 2 倍且必须严格满足9:16 竖屏宽高比校验表达式为width * 16 height * 9文件大小Google Play 目标配置了maximumFileSizeBytes: 8 * 1024 * 10248MB超限即失败数量每个输出文件夹必须包含全部预期场景文件缺失即失败且总数落在该槽位的minimumUploadCount/maximumUploadCount之间。文档对此的结论是harness 是上传尺寸的唯一事实来源source of truth不要对其输出做 resize。如果商店规则变化应更新对应目标的storeAsset规格。一次完整捕获只有当 PNG 尺寸正确、无 alpha、8-bit RGB、文件大小不超限、不违反 Google Play 的 9:16 形状/边界、且完整输出集不低于商店最小值时才判定成功。--validate-only模式复用同一套校验逻辑适合在不上传前对既有素材做快速体检。GitHub Actions 一键捕获仓库自带Mobile Showcase Screenshots工作流mobile-showcase-screenshots.yml从 GitHub Actions 标签页手动触发workflow_dispatch三个输入platformall、ios或androidappearancelight、dark或boththemet3-code、t3-chat、grove、ocean、ember、iris或all选all时每个 job 的超时从 60 分钟提升到300 分钟。默认分发同时捕获t3-code调色板的明暗两种外观iOS 与 Android 并行iPhone 6.9 / iPhone 6.5 / iPad 13 在 12 vCPU 的 Blacksmith macOS runner 上捕获Android 手机、7 英寸平板、10 英寸平板在 16 vCPU 的 Blacksmith Linux runner 上使用 KVM 加速的 x86_64 模拟器API 36Pixel_10_ProAVD8 核 4GB RAM捕获。工作流的关键容错设计每个 job即使捕获失败也会上传 PNGupload 步骤if: always()部分结果对诊断仍然有用独立的验证步骤是success-gated只有捕获成功才会运行--validate-only捕获失败时always()上传仍会发布部分 PNG但不再重新校验产物从运行页的 Artifacts 区下载名称为app-store-connect-screenshots和google-play-screenshots保留 14 天工作流与本地捕获共用同一套 check-in 的设备和场景矩阵Android job 显式设置T3_SHOWCASE_ANDROID_ABIx86_64使 debug APK 匹配其加速模拟器而本地 Apple Silicon 开发默认保持 ARM64。本地前置条件与注意事项iOS需要 Xcode command-line tools、配置的模拟器运行时simulator runtimes以及已安装的 CocoaPods。AndroidSDK 解析顺序为ANDROID_HOME→ANDROID_SDK_ROOT→ 默认 macOS 的$HOME/Library/Android/sdk或其他平台的$HOME/Android/SdkresolveAndroidSdkRoot的实现同时兼容 Windows 的USERPROFILE。解析出的 SDK 必须提供adb与emulator且配置的 AVD默认Pixel_10_Pro必须已存在。首次完整捕获会用 Expo 的 clean production prebuild 重新生成所选原生工程再构建重复捕获首次构建之后应使用--skip-build加速。小结这套 harness 的价值在于把商店截图从人工摆拍变成了可复现、可校验、可入 CI 的工程化流程种子环境提供确定性数据真实应用与真实配对链路保证截图内容即产品实况storeAsset规格把商店上传约束固化为硬校验--validate-only与 GitHub Actions 则让截图过期/非法这类回归在发布前就被拦截。若需调整设备、场景、外观或调色板修改 mobile-showcase.config.ts 即可若需定制种子项目、线程、对话与 Git 变更则编辑 mobile-showcase-environment.ts整体设备编排逻辑位于 mobile-showcase.ts。【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
