为保障短信服务的规范化和高效使用，自 2025 年 9 月 10 日起，平台将正式实施 短信签名有效期管理规则：

一、规则说明

• 签名有效期管理
  对于连续 6 个月未活跃（包括但不限于未补充信息、未修改签名、未使用该签名发送短信等操作）的短信签名，系统将自动标记为 “失效状态”。（失效状态不会直接清理或删除数据）

• 恢复方式
  已失效的签名需通过 uniCloud 后台 → 短信服务 → 签名管理 页面，点击 编辑 并重新提交报备申请，经审核通过后方可恢复使用。

• 使用限制
  在签名失效期间，该签名将无法用于短信发送，请您提前做好相关业务调整。

二、风险提示与建议

为避免签名失效影响业务，建议您：

• 定期检查
  登录 uniCloud 后台 → 短信服务 → 签名管理 页面，关注名下签名的状态及最后一次短信发送记录；

• 保持活跃度
  若签名暂时未在业务中使用，可通过 补充信息 或 发送测试短信 等操作，维持签名的活跃状态；

• 关注提醒
  平台将在签名即将失效前，通过邮件向您发送倒计时提醒，请根据提示及时完成必要操作。

'''无论是个人开发者还是团队，应用开发完成后都必须面对一个核心问题：app上架流程。
与 Android 平台的相对宽松不同，苹果 App Store 上架流程 更严格，涉及 开发者账号、证书准备、应用打包、ipa 上传、测试分发、审核发布 等多个环节。
特别是使用 uni-app 跨平台开发的团队，虽然开发阶段效率更高，但在 iOS 应用发布 时依然需要精准操作，才能顺利完成上架。

本文将结合实战经验，全面解析 app上架流程，并分享多工具组合（Xcode、Transporter、Appuploader、Fastlane）的最佳实践。

一、App 上架流程的第一步：开发者账号与证书

1. Apple 开发者账号

• 个人账号：适合独立开发者，99 美元/年。
• 企业账号：适合公司团队，支持更多分发方式。

2. iOS 证书与描述文件

• 开发证书：用于真机调试。
• 发布证书：用于 TestFlight 与 App Store 上架。
• 描述文件：控制应用的分发方式（Ad Hoc、App Store）。

工具支持：

• Xcode：适合 Mac 用户，自动生成证书。
• Appuploader：适合 Windows/Linux 用户，生成 .p12 和 .mobileprovision 文件，方便团队协作。

二、uni-app 应用的打包方式

1. HBuilderX 云打包

• 上传证书与描述文件，云端自动生成 ipa 文件。
• 适合没有 Mac 的小团队。

2. Xcode 本地打包

• 从 HBuilderX 导出 Xcode 工程，在 Mac 上 Archive 打包。
• 灵活性更强，适合正式发布。

实战经验：小版本更新走云打包，大版本发布走 Xcode 打包。

三、ipa 上传：app 上架流程的核心环节

生成 ipa 后，必须上传到苹果服务器。

上传工具对比

• Xcode 上传：最常见方式，但大文件容易失败。
• Transporter App：苹果官方上传工具，更稳定。
• Appuploader：跨平台支持 Windows/Linux，免 Mac 上传 ipa。
• Fastlane：自动化上传工具，适合团队 CI/CD 流程。

推荐组合：

• 独立开发者：Xcode + Transporter。
• 团队开发：Fastlane 自动化上传，Appuploader 备用。

四、测试分发：验证应用在不同设备上的稳定性

在正式上架之前，测试分发是必不可少的环节。

1. Ad Hoc 分发
   • 限制 100 台设备，适合内部调试。
2. TestFlight 内测
   • 最多 25 名团队成员，适合小范围验证。
3. TestFlight 外测
   • 最多 10,000 用户，适合大规模测试。
4. 二维码安装
   • 使用 Appuploader 生成二维码，方便产品与运营快速安装体验。

五、App Store 审核：app 上架流程的最后一关

苹果审核严格，常见驳回原因包括：

• 壳应用嫌疑：uni-app 应用如果只是简单封装 H5 页面，容易被拒。
• 素材不足：缺少截图或多语言描述。
• 权限说明不全：如相机、麦克风、定位用途未明确说明。

审核优化技巧

• 功能必须完整，避免“套壳”应用。
• 在 App Store Connect 上传完整截图和多语言描述。
• 使用 Appuploader 批量上传截图，减少人工操作。
• 在 Info.plist 中写明权限用途，确保合规。
• 紧急情况下可申请 加急审核。

六、实战案例：一个 uni-app 工具类应用的上架过程

一个 5 人团队开发的工具类应用，他们的 app 上架流程 如下：

1. 运维人员在 Windows 用 Appuploader 生成证书并共享。
2. 开发人员用 HBuilderX 云打包生成 ipa。
3. 测试人员用 Transporter 上传 ipa 至 TestFlight，覆盖多款 iOS 设备。
4. 产品经理在 App Store Connect 上传截图和多语言描述。
5. 应用审核一次性通过，成功上架 App Store。

这种流程让团队即使只有一台 Mac，也能顺利完成整个流程。

七、经验总结

1. 证书管理必须规范，避免签名错误。
2. 打包方式要结合使用，云打包快速，本地打包稳定。
3. 上传工具多样化，Xcode、Transporter、Appuploader、Fastlane 各有优势。
4. 测试分发要分阶段，先内部验证，再外部扩展。
5. 审核要准备充分，素材完整、权限说明清晰。

app 上架流程 虽然复杂，但并非不可掌握。
通过合理使用 HBuilderX、Xcode、Transporter、Appuploader、Fastlane 等工具，开发者完全可以高效完成从 应用开发到 App Store 发布 的全过程。
无论是独立开发者还是团队，掌握这些实战经验，才能让应用更顺利进入市场。'''

4.76更新HBuilderx定位元素失效布局变紊乱
打包必须android/iOS一起打包，中途不能停止（sb设计）

'''在 iOS 应用开发中，性能监控 是决定用户体验的核心环节。
一个 App 如果存在 CPU 占用过高、内存泄漏、掉帧卡顿、耗电过快、网络请求缓慢 等问题，就算功能再丰富，也会被用户迅速抛弃。

对于 uni-app 跨平台开发 而言，性能监控显得尤为重要：跨层桥接、WebView 渲染和插件调用常常隐藏潜在的性能瓶颈。
因此，开发者需要掌握一套 完整的 iOS App 性能监控方法，覆盖从开发调试到线上运维的全流程。

一、iOS App 性能监控的核心指标

1. CPU 占用
   • 是否存在高强度计算或死循环。
2. 内存使用
   • 是否出现内存泄漏或频繁分配释放。
3. GPU 压力
   • 动画与渲染是否造成掉帧。
4. 帧率 (FPS)
   • 是否能稳定保持在 55–60fps。
5. 电池能耗
   • 前台与后台运行时的耗电曲线。
6. 网络延迟
   • 接口响应时间是否过长，弱网环境是否正常。

二、常用性能监控工具与分工

三、实战案例一：页面切换掉帧问题

背景

某 uni-app 社交应用在聊天页面切换时卡顿严重。

调试步骤

1. Xcode Instruments (Core Animation)：定位 GPU 占用过高，FPS 降至 20。
2. 克魔：监控多设备，发现低端机卡顿更严重。
3. 优化方案：减少动画过渡，延迟非必要 UI 渲染。
4. 效果：FPS 恢复至 55 以上，页面切换流畅。

四、实战案例二：后台运行耗电过快

背景

某 uni-app 新闻类应用在后台仍消耗过多电量。

调试步骤

1. 克魔：电量曲线显示后台 CPU 占用稳定在 20%。
2. Xcode Instruments → Energy Log：确认后台定时任务频繁触发。
3. 优化方案：减少后台任务执行次数，采用批处理模式。
4. 效果：耗电降低 22%，续航显著改善。

五、实战案例三：接口延迟影响启动速度

背景

某 uni-app 电商应用首页加载缓慢，用户流失率增加。

调试步骤

1. Charles：发现部分接口响应超过 2 秒。
2. Firebase Performance：收集线上数据，平均启动耗时 3 秒。
3. 优化方案：增加缓存策略，并行加载接口数据。
4. 效果：启动耗时缩短至 1.4 秒，用户留存率提升。

六、多工具协作的推荐流程

[开发阶段] → Instruments 定位 CPU/GPU/内存/能耗问题    
[测试阶段] → 克魔 监控电量曲线和 FPS，Charles 验证网络延迟    
[运维阶段] → Firebase 收集真实用户性能数据，Crashlytics 捕捉异常  

• 开发：深入代码级别定位瓶颈；
• 测试：多设备性能验证，覆盖真实使用场景；
• 运维：线上性能监控，形成持续优化闭环。

在 iOS 应用开发中，性能监控决定了用户体验的好坏。
通过 Xcode Instruments、克魔 KeyMob、Firebase、Charles、iMazing/itools 的多工具协作，团队可以：

• 实时监控 CPU、内存、GPU、帧率、电量与网络；
• 快速定位卡顿与耗电根因；
• 构建开发–测试–运维的性能闭环，保障 App 长期稳定。

对于 uni-app 项目而言，这样的性能监控体系更是必不可少，能有效避免跨平台性能损耗带来的用户体验问题。'''

'''在移动应用开发中，苹果app上架流程 一直被认为比 Android 更加复杂和严格。
从 开发者账号注册、证书申请、应用打包、ipa 文件上传、测试分发到 App Store 审核，每一步都可能出现问题。
尤其是使用 uni-app 进行跨平台开发的团队，虽然开发阶段效率更高，但在 iOS 应用发布 时依然需要遵循完整的苹果上架标准。

本文将结合实战经验，详细解析 苹果app上架流程，并介绍多工具组合（Xcode、Transporter、Appuploader、Fastlane）的使用方法，帮助开发者高效完成 iOS 应用发布。

一、苹果App上架流程第一步：开发者账号与证书

在上架之前，必须完成以下准备：

1. Apple 开发者账号
   • 个人账号：99 美元/年，适合独立开发者。
   • 企业账号：适合公司团队，支持更多分发方式。
2. iOS 证书与描述文件
   • 开发证书：用于真机调试。
   • 发布证书：用于 TestFlight 与 App Store 发布。
   • 描述文件：决定应用的分发方式（Ad Hoc、App Store 等）。

工具选择：

• Mac 用户：直接使用 Xcode 生成证书与描述文件。
• Windows/Linux 用户：使用 Appuploader 申请证书，生成 .p12 与 .mobileprovision 文件。

二、uni-app 应用的打包方式

1. HBuilderX 云打包

• 上传证书与描述文件，云端自动生成 ipa 文件。
• 无需 Mac，适合小团队和快速版本发布。

2. Xcode 本地打包

• 从 HBuilderX 导出 Xcode 工程，在 Mac 上 Archive 打包生成 ipa。
• 灵活性高，支持更多配置，适合正式版本发布。

实战经验：小版本更新建议使用云打包，大版本发布建议使用本地打包。

三、ipa 上传：苹果app上架流程的关键环节

生成 ipa 文件后，必须上传到苹果服务器，进入 TestFlight 或 App Store。

常见上传方式

• Xcode 上传：操作直观，但大文件可能失败。
• Transporter App：苹果官方工具，适合大文件上传，更稳定。
• Appuploader：支持 Windows/Linux/Mac 跨平台上传，免 Mac 环境。
• Fastlane：命令行自动化上传工具，适合 CI/CD 流程。

推荐组合：

• 独立开发者：Xcode + Transporter。
• 团队开发：Fastlane 自动化上传，Appuploader 备用。

四、测试分发：验证应用稳定性与兼容性

在正式上架之前，需要经过多轮测试分发：

1. Ad Hoc 分发
   • 绑定设备 UDID，最多 100 台设备。
   • 适合 QA 内部测试。
2. TestFlight 内测
   • 最多支持 25 名团队成员。
   • 适合小规模功能验证。
3. TestFlight 外测
   • 最多支持 10,000 用户，适合大规模用户测试。
4. 二维码安装
   • 使用 Appuploader 生成二维码，便于产品或运营人员快速安装。

五、App Store 审核：苹果app上架流程的最后一关

苹果审核严格，常见驳回原因包括：

• 壳应用嫌疑：uni-app 应用如果只是简单封装 H5 页面，容易被拒。
• 素材不完整：缺少截图或多语言描述。
• 权限说明不全：相机、定位、麦克风用途未明确说明。

审核优化建议

• 功能必须完整，避免“套壳”嫌疑。
• 在 App Store Connect 上传完整截图和多语言描述。
• 使用 Appuploader 批量上传截图，减少重复操作。
• 在 Info.plist 文件中详细说明权限用途。
• 紧急情况下可申请 加急审核。

六、实战案例：苹果app上架流程的团队经验

一个 6 人团队开发的工具类应用，完整的上架流程如下：

1. 运维人员（Windows）用 Appuploader 生成证书并共享。
2. 开发者用 HBuilderX 云打包生成 ipa。
3. 测试人员用 Transporter 上传 ipa 至 TestFlight，进行多机型测试。
4. 产品经理在 App Store Connect 上传截图与多语言描述。
5. 应用一次审核通过，成功上架 App Store。

这种方式大幅减少了对 Mac 的依赖，提高了团队协作效率。

七、经验总结

1. 证书与账号管理必须规范，避免签名错误。
2. 打包方式灵活选择，云打包快速，本地打包稳定。
3. 上传工具多样化，Transporter、Xcode、Appuploader、Fastlane 各有优势。
4. 测试分发分阶段，逐步扩大测试范围。
5. 审核要准备充分，功能完整、素材齐全、权限说明到位。

苹果app上架流程 虽然复杂，但并非无法掌握。
通过合理使用 HBuilderX、Xcode、Transporter、Appuploader、Fastlane 等工具，开发者完全可以高效完成 iOS 应用从打包到 App Store 发布 的全过程。
无论是独立开发者还是团队，掌握这些经验，才能让应用更顺利地进入市场。

'''

'''在移动应用开发与日常使用中，电池健康与电量消耗始终是用户最关注的体验指标之一。
尤其在 iOS 平台，用户常常关心：

• 如何准确查看设备电量与电池寿命？
• 哪些 App 在后台耗电过多？
• 如何通过性能调试工具定位耗电问题？
• 在 uni-app 开发过程中，如何避免应用成为“耗电大户”？

本文将从 iOS 系统工具、开发调试工具与第三方辅助工具 三个角度，系统介绍如何 查看 iOS 设备电量、分析耗电情况并进行优化。

一、iOS 系统自带的电量与电池使用情况查看方式

1. 电池百分比与健康度
   • 路径：设置 → 电池 → 电池健康
   • 可查看电池最大容量与峰值性能状态。
2. 耗电应用统计
   • 路径：设置 → 电池 → 过去 24 小时/10 天
   • 可查看各 App 在前台与后台的耗电占比。
3. 电量曲线
   • 显示一段时间内的电量变化，帮助用户判断耗电高峰。

适合普通用户，但数据维度有限，无法精细分析 CPU、GPU、后台任务对耗电的影响。

二、开发者常用的能耗调试与电量监控工具

三、实战案例一：如何在开发中监控电量消耗

背景

某 uni-app 电商应用在加载首页时，用户反馈手机发热、电池快速下降。

调试步骤

1. Xcode Instruments → Energy Log：发现 GPU 使用率过高，耗电急剧上升。
2. 克魔：监控电量曲线，验证耗电高峰与首页渲染重合。
3. 优化方案：减少首屏渲染元素，延迟加载次要内容。
4. 效果：耗电下降 15%，首页流畅度提升。

四、实战案例二：后台耗电问题排查

背景

某 uni-app 新闻应用，即使在后台运行，电量仍快速下降。

调试步骤

1. 克魔：电量监控显示后台 CPU 占用超过 20%。
2. Instruments：定位后台定时器频繁触发，导致电池掉电快。
3. 优化方案：限制后台刷新频率，合并任务。
4. 效果：后台耗电减少 25%，续航时间延长。

五、实战案例三：版本升级后的电池寿命差异

背景

某 uni-app 教育应用在 v2.0 版本后被用户投诉“电池消耗更快”。

调试步骤

1. 克魔：对比 v1.9 与 v2.0 的电量曲线，发现新版本 GPU 占用更高。
2. iMazing：导出缓存文件，发现日志与图片缓存大量累积。
3. 优化方案：增加缓存清理机制，降低 GPU 渲染压力。
4. 效果：新版本耗电量回到正常水平。

六、推荐的多工具协作流程

[开发阶段] → Instruments 精细监控 CPU/GPU/电池曲线    
[测试阶段] → 克魔 导出电量数据与使用记录，检查多设备表现    
[验证阶段] → iMazing/itools 检查缓存/日志，排查隐性耗电    
[运维阶段] → Firebase 收集线上耗电趋势，Crashlytics 捕捉异常  

• 开发：聚焦代码与渲染逻辑的优化；
• 测试：用克魔采集真实电量数据，结合多机对比；
• 运维：利用 Firebase 收集用户端耗电情况，快速响应反馈。

在 iOS 平台，查看电量与监控能耗不仅是用户关心的问题，更是开发者必须掌握的能力。
通过 Xcode Instruments、克魔 KeyMob、Firebase、iMazing/itools 等工具的协作，团队可以：

• 精准查看 iOS 设备电量与电池寿命；
• 定位 App 的高耗电模块；
• 优化后台任务与渲染逻辑，全面提升续航表现。

这样，uni-app 应用在 iOS 设备上才能兼顾 流畅度与电池续航，真正赢得用户口碑。'''

精通Java、PHP、Go、Vue、React、UniApp等技术栈，熟悉前后端分离开发、微服务架构、容器化部署等技术，拥有丰富的开发经验。
能够独立完成从项目的分析、设计、开发、测试、部署到维护与优化的全过程，能快速的对需求进行梳理并制定开发计划。
注重代码可维护性、可扩展性、性能优化等方面的工作。
如果您正在寻找一位高效、专业的开发者来完成您的项目，我非常愿意为您提供优质的服务，共同推动项目顺利进行。
如果您对我的技能与工作经验感兴趣，请通过微信联系我，我们可以进一步探讨您的具体项目需求，并且开展合作。
V：TombaughWechat

在uniapp x上，使用webview组件，内嵌一个html文件
我使用的是高德地图。

按照官方给出的文档设置。但是无法正常显示地图出来。
可以检查一下，ID元素有没有设置大小。
不要设置百分比%
建议设置PX单位 例如：width:750px;height:1500px;

用户管理页报错

Error in created hook: "TypeError: Cannot read properties of null (reading 'length')"
原因：uni-data-checkbox组件bug，第388行改为

return this.dataValue&&this.dataValue.length > 0 ? this.dataValue : selectedArr

'''在 iOS 应用开发中，能耗与电池消耗是用户最直观的体验指标。
即便功能完善，如果 App 存在以下问题：

• 电池掉电快、设备发热严重；
• 后台任务执行过多；
• 页面渲染与文件操作引发 CPU/GPU 过载；
• 日志或缓存导致频繁 I/O；

用户都会毫不犹豫地卸载应用。
对于 uni-app 跨平台开发者 来说，能耗监控更是必不可少，因为 JS 与 Native 桥接调用容易隐藏性能陷阱。

本文将系统讲解 iOS 能耗监控 的关键指标、工具组合与实战案例，帮助开发团队构建 电池优化闭环，让 App 更省电、更稳定。

一、iOS 能耗监控的核心指标

1. CPU 占用率
   • 高运算任务或死循环导致耗电急剧增加。
2. GPU 使用率
   • 动画、页面渲染、图像处理压力过大，容易掉帧与发热。
3. 内存使用
   • 频繁分配/未释放的对象导致内存与能耗双重问题。
4. FPS (帧率)
   • 卡顿与掉帧直接影响 GPU 与电量。
5. 电池电量曲线
   • 前台、后台运行下的耗电趋势。
6. 后台任务
   • 定时器、定位、数据写入若未优化，会长期拖慢电池续航。

二、常见工具与功能分工

三、实战案例一：后台耗电过快

背景

某 uni-app 新闻应用，用户反馈即使锁屏，电量仍快速下降。

调试流程

1. 克魔：电量曲线显示后台 CPU 占用 25%，明显异常。
2. Instruments → Energy Log：定位到后台定时任务频繁触发。
3. 修复方案：降低定时任务频率，限制后台刷新。
4. 效果：后台耗电降低 22%，发热问题缓解。

四、实战案例二：缓存与日志文件导致发热

背景

某 uni-app 教育应用，长时间运行后设备发热明显。

调试流程

1. iMazing：导出日志目录，发现日志文件已超过 600MB。
2. 克魔：监控 I/O 与电量消耗，发现频繁写入触发能耗高峰。
3. 优化方案：增加日志分割与自动清理机制。
4. 效果：运行时发热减少，耗电下降 15%。

五、实战案例三：渲染与 GPU 占用过高

背景

某 uni-app 电商应用，在商品详情页面渲染时掉帧严重，耗电快。

调试流程

1. Instruments → Core Animation：GPU 占用接近 90%，FPS 下降至 20。
2. 克魔：多机对比，低端机影响更严重。
3. 优化方案：减少 DOM 节点、延迟加载非关键图片。
4. 效果：FPS 恢复至 55 以上，耗电下降 18%。

六、推荐的能耗监控闭环流程

[开发阶段] → Instruments 精细分析 CPU/GPU/电池消耗    
[测试阶段] → 克魔 长期监控电池曲线与性能趋势    
[验证阶段] → itools/iMazing 检查缓存/日志，排查隐性耗电    
[运维阶段] → Firebase 收集用户耗电数据，Crashlytics 捕捉异常  

• 开发：代码级能耗优化；
• 测试：验证缓存/日志是否拖慢性能；
• 运维：监控线上电量数据，防止退化。

在 iOS 应用开发中，能耗优化=用户体验优化。
通过 Xcode Instruments、克魔 KeyMob、Firebase、iMazing/itools 的协作，团队可以：

• 发现 CPU/GPU/内存与电池消耗的真实关系；
• 追踪后台任务、缓存文件等隐性耗电源；
• 建立 开发–测试–运维 的能耗闭环，全面提升续航表现。

这样，uni-app 应用才能在 iOS 平台上既流畅又省电，让用户真正安心使用。'''

截止到目前最新的app store上架流程中，需要上传6.9寸、6.5寸和ipad的截图，而且这个步骤是必填的。如下图：

但是我们用uniapp开发，假如使用windows开发是没有ios设备的模拟器的，而且我们也不可能因上架appstore去买这么多种ios设备来截屏， 以为只有上架的时候才需要用到这个截屏，开发的时候是不需要的，购买真机来截屏成本太高。

除了模拟器和真机测试外，还可以借助香蕉云编的合成截屏工具来合成截屏，这样就无需mac电脑，也无需购买真机，截屏工具的地址：

https://www.yunedit.com/jietu

截屏的原理比较简单，只需要上传一样相似比例的图片，它可以帮你合成一张包含ios带电池栏和底部横条栏的截图，而且符合ios的截屏尺寸。

在hbuilderx打包的时候，想放到发布平台去扫码测试，或者上架app store connect，需要使用自建证书打包，不能再使用数据线连接的方式安装到手机。

而创建ios证书的教程，提示我们需要使用mac电脑的钥匙串访问去申请证书，然而我的电脑却是windows电脑。

后来发现没有mac电脑能创建ios证书，可以使用香蕉云编来生成p12私钥证书，profile文件在苹果开发者中心就可以生成，不需要mac电脑。

创建的过程如下：

1）申请苹果开发账号，这个步骤最麻烦最消耗时间，可以参考下面的教程申请苹果开发账号。完成这步后，后面的步骤都很简单。假如你们公司已经有账号就不需要申请账号了。

https://juejin.cn/post/7529496810265575458

2）进入苹果开发者中心，点击证书功能，创建一个证书，创建证书的第一步，选择ios distribution类型的证书。

3) 创建证书的过程中，提示需要提供一个csr文件，提示需要在mac电脑申请这个文件。如下图所示：

4）这个步骤，可以不用mac电脑来申请，可以改用香蕉云编来代替：
https://www.yunedit.com/createcert

5）接着下一步，就生成证书文件了。在苹果开发者中心下载下来，证书是.cer后缀格式的，还不是hbuilderx所需的p12格式的证书。

6）接着使用香蕉云编，生成p12证书的功能，将cer转换成p12格式，生成p12证书前，是需要先上传刚才在苹果开发者中心生成的cer证书去香蕉云编先的，如下图所示：

完成上面6个步骤，p12私钥证书文件就创建完毕了。

还有profile文件需要创建。

7）登录苹果开发者中心，找到Identifiers模块，创建一个应用。
注意，创建应用的时候，填写的应用的APPID，需要填写一个java格式的包名，一般是com.xxname.xxapp这样的格式。
这个appId，是跟hbuilderx的云打包里面的包名对应的，需要一致。

8）创建profile文件，在苹果开发者中心，找到profile模块，就可以创建profile了。
在这里需要提醒的是，创建profile的时候，假如选择app store connect类型，就是创建上架类型的profile。
假如创建的是Ad hoc类型，就是真机测试类型，可以用来给团队其他成员安装测试的。生成ad hoc类型的话，可以放到香蕉云编或者蒲公英这种测试平台来扫码安装。

创建profile的过程还需要绑定APPID（应用）和绑定Certificate（证书）的，就是绑定前几个创建的应用和证书，假如你有多个应用或多个证书，可别选错了。

假如选择的是ad hoc类型，它提示还需要绑定测试设备的udid的，你还是提前获取到你团队的所有udid，再去创建测试类型的profile文件。因为添加了新成员，profile又需要重新创建的，重下下载profile文件的。

获取udid的最简单的方法是使用ios测试设备，扫描香蕉云编获取udid的工具，根据它的提示来获取udid:
https://www.yunedit.com/udid

好了，完成上面的8个步骤，证书和profile文件应该就创建完了。