截止到目前最新的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文件应该就创建完了。

组件库示例已上传鸿蒙应用市场，欢迎大家下载体验；
插件地址：https://ext.dcloud.net.cn/plugin?id=24907

'''对于开发者来说，应用完成后最关键的一步就是 苹果上架，也就是将应用发布到 App Store。
不同于 Android 市场的相对宽松，苹果上架流程 更加严格，涉及证书、打包、上传、测试和审核等多个环节。
特别是使用 uni-app 进行跨平台开发的团队，在 iOS 应用发布时需要格外注意流程规范，否则很容易卡在上架环节。

本文将结合实战经验，全面解析 苹果上架流程，帮助开发者快速掌握 iOS 应用发布的关键步骤与避坑经验。

一、苹果上架前的准备：开发者账号与证书

Apple 开发者账号

• 个人账号：适合独立开发者，费用较低。
• 企业账号：适合团队或公司，支持更灵活的分发方式。

iOS 证书与描述文件

• 开发证书：用于调试和测试。
• 发布证书：用于 TestFlight 与 App Store 上架。
• 描述文件：定义应用分发方式（Ad Hoc、App Store 等）。

工具选择：

• Xcode：Mac 用户可直接生成。
• Appuploader：Windows/Linux 用户可跨平台申请并导出 .p12 文件，便于团队共享。

二、打包流程：uni-app 项目到 ipa 的生成

HBuilderX 云打包

• 上传证书和描述文件，云端直接生成 ipa。
• 适合小团队、没有 Mac 的开发者。

Xcode 本地打包

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

实战建议：

• 小更新 → 云打包快速产出 ipa。
• 大版本 → 本地打包，保证可控性和稳定性。

三、上传阶段：苹果上架的关键一步

生成 ipa 后，需要将其上传至苹果服务器，才能进入 TestFlight 或提交审核。

上传方式

• Xcode 上传：官方方式，但上传大文件时可能卡住。
• Transporter：苹果官方工具，上传大文件更稳定。
• Appuploader：跨平台上传工具，支持 Windows/Linux，免 Mac 上传 ipa。
• Fastlane：命令行工具，适合自动化上传，常用于 CI/CD。

推荐组合：

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

四、测试分发：让应用覆盖不同 iOS 设备

在正式上架之前，必须进行多轮测试，确保应用稳定性。

测试方式

1. Ad Hoc 分发：最多支持 100 台设备，适合小范围调试。
2. TestFlight 内测：最多 25 名团队成员，快速验证功能。
3. TestFlight 外测：最多 10,000 用户，适合大规模测试。
4. 二维码安装：Appuploader 可生成二维码，方便非技术同事快速安装体验。

实战经验：

• 内部调试用 Ad Hoc，团队协作用 TestFlight 内测，外部验证用 TestFlight 外测，逐步扩大覆盖范围。

五、App Store 审核：苹果上架的最后关口

苹果审核是上架过程中最不可控的环节，常见拒绝原因包括：

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

审核优化技巧

• 功能必须完整，避免“套壳”应用。
• 在 App Store Connect 上传完整截图和多语言描述。
• 使用 Appuploader 批量上传截图，提高效率。
• 在 Info.plist 中明确说明权限用途，提升通过率。
• 紧急情况下可申请 加急审核。

六、实战案例：一个 uni-app 电商应用的苹果上架流程

一个 5 人团队开发的电商类应用，采用 uni-app 构建，具体流程如下：

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

整个过程仅依赖一台 Mac，大大降低了团队硬件成本。

七、经验总结

1. 证书集中管理：避免重复申请和丢失。
2. 打包方式结合使用：云打包快速，本地打包稳定。
3. 上传工具多样化：Appuploader、Fastlane、Xcode、Transporter 互补。
4. 测试分发分阶段：从 Ad Hoc → TestFlight 内测 → TestFlight 外测。
5. 审核准备充分：素材齐全、权限说明到位，避免不必要的驳回。

苹果上架流程 虽然复杂，但并非无法掌握。
通过合理的工具选择与团队分工，开发者完全可以在有限资源下完成从 uni-app 打包、跨平台上传，到 App Store 审核发布 的全过程。
利用 HBuilderX、Appuploader、Xcode、Fastlane、TestFlight，无论是独立开发者还是团队，都能高效完成 iOS 应用发布。'''

'''在 iOS 应用开发与运维中，文件管理 与 能耗调试 往往被分开处理：前者关注数据存储与缓存，后者关注电池电量与CPU/GPU消耗。
但在实际开发，特别是 uni-app 跨平台项目 中，这两者往往高度相关：

• 缓存文件未清理，导致磁盘频繁读写，耗电明显增加；
• 日志文件过大，App 启动和后台任务都受影响；
• 数据库文件管理不当，引发性能下降和能耗上升；
• 版本升级未做数据迁移，不仅文件丢失，还可能触发异常能耗。

本文将结合 多工具协作，分享如何在 iOS 平台上同时进行文件管理与能耗调试，形成一套完整的优化闭环。

一、为什么文件管理与能耗紧密相关？

1. 缓存影响 I/O 与耗电
   • 图片、音频缓存未清理会造成磁盘频繁写入，影响性能与电池寿命。
2. 日志文件拖慢性能
   • 大量 debug 日志会增加 I/O 消耗，并在后台运行时持续耗电。
3. 数据库文件读写压力
   • SQLite 文件频繁更新或未做索引，容易让 CPU 与磁盘占用升高。
4. 系统清理机制触发
   • 临时目录使用不当，导致系统反复清理，引发额外电量消耗。

二、常见工具与功能定位

三、实战案例一：缓存文件引发高耗电

背景

某 uni-app 新闻类应用，用户反馈设备发热，电池掉电快。

调试流程

1. iMazing 导出缓存目录，发现数千张图片未清理。
2. 克魔 监控电量曲线，后台耗电比平时高出 20%。
3. Instruments 分析 I/O，确认缓存写入频繁。
4. 优化方案：增加缓存清理策略，限制后台写入频率。
5. 效果：耗电量下降 18%，App 运行更流畅。

四、实战案例二：日志文件过大导致性能下降

背景

一个 uni-app 教育应用，启动时卡顿严重。

调试流程

1. 克魔 导出日志目录，发现单个日志文件超过 500MB。
2. itools 快速查看日志文件增长情况。
3. Instruments → Energy Log 分析显示磁盘读写异常频繁。
4. 优化方案：日志分割与定期清理机制。
5. 效果：启动时间减少 40%，电池消耗明显降低。

五、实战案例三：数据库管理不当引发能耗异常

背景

某 uni-app 电商应用在购物车操作时，用户反馈耗电快。

调试流程

1. 克魔 导出 SQLite 数据库文件，对比发现冗余索引过多。
2. Instruments 定位 CPU 使用率在写入时飙升。
3. 优化方案：精简数据库结构，增加事务批处理。
4. 结果：耗电降低 15%，页面卡顿问题解决。

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

[开发阶段] → Instruments 分析能耗瓶颈，调试文件 I/O    
[测试阶段] → 克魔 导出缓存与日志，监控电量曲线    
[验证阶段] → iMazing/itools 快速检查文件目录与增长趋势    
[运维阶段] → Firebase 收集线上能耗，Crashlytics 捕捉文件相关崩溃  

• 开发：关注代码级文件读写效率与能耗；
• 测试：多工具结合验证缓存、日志、数据库对能耗的影响；
• 运维：持续监控用户电池数据，防止能耗退化。

在 uni-app iOS 开发中，文件管理与能耗调试往往相辅相成。
通过 Xcode Instruments、克魔(KeyMob)、iMazing/itools、Firebase 等多工具协作，团队可以：

• 发现缓存、日志、数据库对能耗的真实影响；
• 优化文件存储策略，降低 CPU/GPU/I/O 压力；
• 构建完整的 文件管理 + 能耗优化闭环，提升用户体验与电池续航。

这种综合调优方式，能让你的 App 在 iOS 平台既流畅又省电。'''

鸿蒙应用如何注册和声明 DeepLink 和 AppLinking 可参考 《通过 URL Scheme 唤起鸿蒙应用》

这里重点介绍如何在应用中唤起其他应用和元服务。

鸿蒙唤起鸿蒙、元服务已经迁移到文档 《鸿蒙应用唤起鸿蒙应用、元服务》

鸿蒙元服务唤起鸿蒙应用已经迁移到文档 《鸿蒙元服务唤起鸿蒙应用》

'''对于很多开发者来说，App Store 软件上架 是 iOS 开发流程中最具挑战性的环节。
即便应用开发完成，要想成功发布到 App Store，还需要经历 证书申请、打包生成、上传分发、审核合规 等多个步骤。
如果是基于 uni-app 开发的跨平台应用，虽然开发效率更高，但在上架流程中依然需要面对苹果生态的严格要求。

本文将结合实战经验，系统解析 App Store 软件上架流程，并介绍多工具组合的最佳实践，帮助开发者少走弯路。

一、准备工作：开发者账号与证书

在开始 App Store 上架前，必须完成以下准备：

1. Apple Developer 账号
   • 个人账号：适合独立开发者。
   • 企业账号：适合团队或公司。
2. iOS 证书与描述文件
   • 开发证书：用于调试和测试。
   • 发布证书：用于 App Store 上架。
   • 描述文件：决定应用能安装在哪些设备上。

工具选择

• Xcode：适合 Mac 用户，自动生成证书和描述文件。
• Appuploader：适合 Windows/Linux 用户，支持跨平台申请证书并生成 .p12 文件。

二、打包阶段：uni-app 到 ipa 的转换

1. HBuilderX 云打包

• 上传证书与描述文件，云端自动生成 ipa。
• 适合小团队或无 Mac 环境的开发者。

2. 本地打包（Xcode）

• 导出 Xcode 工程，在 Mac 上 Archive 打包。
• 更灵活，支持个性化配置，适合正式版本。

实践经验

• 小版本更新：优先使用 HBuilderX 云打包，快速产出 ipa。
• 大版本发布：使用 Xcode 本地打包，保证稳定性与可控性。

三、上传阶段：将应用提交到苹果服务器

生成 ipa 后，需要上传到苹果服务器，进入 TestFlight 或 App Store。

上传工具选择

• Xcode 上传：直观但容易卡住。
• Transporter：苹果官方工具，适合大文件上传。
• Appuploader：全平台支持 Windows/Linux/Mac，免 Mac 上传 ipa。
• Fastlane：自动化上传工具，适合中大型团队 CI/CD。

实战建议

• 小团队：优先选择 Appuploader，跨平台高效上传。
• 大团队：集成 Fastlane 与 Jenkins，实现持续集成。

四、测试分发：让应用在不同设备上运行

在 App Store 审核前，必须进行多轮测试，确保应用稳定性与兼容性。

1. Ad Hoc 分发
   • 绑定设备 UDID，最多支持 100 台设备。
   • 适合小范围调试。
2. TestFlight 内测
   • 最多支持 25 名团队成员。
   • 无需审核，可快速体验。
3. TestFlight 外测
   • 最多支持 10,000 用户。
   • 需要苹果审核（约 24 小时）。
4. 二维码安装
   • 使用 Appuploader 生成二维码，方便非技术成员快速安装测试。

五、App Store 审核：把握通过的关键

苹果审核严格，常见的驳回理由有：

• 功能不完整：应用被判定为“壳应用”。
• 素材不足：截图或描述缺失。
• 权限说明缺失：相机、麦克风、定位权限用途不明确。

审核优化策略

• 确保功能完整，避免单纯加载 H5 页面。
• 在 App Store Connect 配置多语言截图和描述。
• 使用 Appuploader 批量上传截图，减少人工操作。
• 在 Info.plist 中明确写明每个权限的使用场景。

六、实战案例：基于 uni-app 的工具类应用上架流程

一个 4 人团队在开发工具类应用时，采用了以下上架流程：

1. 运维人员在 Windows 上用 Appuploader 申请证书，导出 .p12 文件并共享。
2. 开发人员用 HBuilderX 云打包生成 ipa。
3. 测试人员用 Appuploader 上传 ipa 至 TestFlight，覆盖 iPhone 与 iPad。
4. 产品经理在 App Store Connect 上传截图与多语言描述。
5. 应用一次审核通过，成功上架 App Store。

这种多工具组合，让团队在仅有一台 Mac 的情况下，顺利完成了全流程。

七、经验总结

1. 证书集中管理：避免重复申请与丢失。
2. 打包方式结合使用：云打包快速，本地打包稳定。
3. 上传工具多样化：Appuploader、Fastlane、Xcode 互为补充。
4. 分发分阶段：Ad Hoc → 内测 TF → 外测 TF。
5. 审核准备充分：素材齐全、功能完整、权限说明到位。

App Store 软件上架流程 涉及多个环节，但通过合理的工具选择与分工，完全可以大幅提升效率。
结合 HBuilderX、Appuploader、Xcode、Fastlane、TestFlight 等工具，开发者和团队都能在有限资源下高效完成应用发布。

'''

原因可能是 请求Authorization Code时无法携带quickLoginMobilePhone scope

<template>  
  <view>  
    <button @click="getProviderSync">getProviderSync</button>  
    <button @click="login">login</button>  
    <button @click="getUserInfo">getUserInfo</button>  
  </view>  
</template>  
<script setup>  
const getProviderSync = () => {  
  const provider = uni.getProviderSync({service: 'oauth'})  
  console.log('provider :>> ' + JSON.stringify(provider));  
}  

const login = () => {  
  uni.login({  
    provider: 'huawei',  
    success(res) {  
      console.log(JSON.stringify(res))  
    },  
    fail(err) {  
      console.log(JSON.stringify(err))  
    },  
  })  
}  

const getUserInfo = () => {  
  uni.getUserInfo({  
    provider: 'huawei',  
    success(res) {  
      console.log(JSON.stringify(res))  
    },  
    fail(err) {  
      console.log(JSON.stringify(err))  
    },  
  })  
}  
</script>  

'''在 uni-app 跨平台开发中，性能始终是用户最关心的体验指标之一。
无论是页面滚动是否流畅，后台运行是否省电，还是接口响应是否及时，都需要依赖 iOS 性能监控 来发现瓶颈并优化。

uni-app 在 iOS 平台上的性能挑战主要包括：

• JS 与 Native 桥接导致的 CPU 开销；
• WebView 与原生 UI 混合渲染带来的 GPU 压力；
• 缓存、数据库读写造成的 I/O 延迟；
• 后台任务执行过多引发耗电与发热。

本文将结合 多工具协作，分享如何在 uni-app iOS 开发中系统化进行性能监控与优化。

一、iOS 性能监控的关键指标

1. CPU 占用：JS 循环计算、数据解析导致过高。
2. 内存使用：文件或对象未释放，出现内存泄漏。
3. GPU 负载：复杂动画、图片渲染引起掉帧。
4. 帧率 (FPS)：是否稳定在 55–60fps。
5. 网络延迟：接口请求是否过慢。
6. 能耗与电池消耗：后台运行是否合理。

二、常见工具与定位

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

背景

某 uni-app 社交应用，用户切换聊天页面时明显卡顿。

调试流程

1. Xcode Instruments (Core Animation)
   • 定位 GPU 占用高达 80%，FPS 降至 20。
2. 克魔
   • 多设备监控确认问题在低端机更明显。
3. 优化方案
   • 减少页面过渡动画，延迟非必要元素渲染。
4. 效果
   • FPS 恢复至 55，用户反馈流畅度提升。

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

背景

新闻类 uni-app 应用在后台运行时发热、掉电快。

调试流程

1. 克魔
   • 电量曲线显示后台 CPU 占用保持 25%。
2. Instruments → Energy Log
   • 定位后台定时任务与缓存写入频繁触发。
3. 优化方案
   • 限制后台刷新频率，缓存写入改为批量模式。
4. 效果
   • 耗电降低 18%，后台运行更稳定。

五、实战案例三：接口请求过慢

背景

某 uni-app 电商应用首页加载缓慢。

调试流程

1. Charles 抓包
   • 发现接口响应延迟超过 2 秒。
2. Firebase Performance
   • 收集线上数据，平均启动耗时 3 秒。
3. 优化方案
   • 开启并发请求，增加缓存策略。
4. 效果
   • 页面加载时间缩短至 1.2 秒，用户留存率提升。

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

[开发阶段] → Xcode Instruments 精细调试    
[测试阶段] → 克魔 多机监控 + itools 文件验证    
[运维阶段] → Firebase 收集线上数据 + Crashlytics 崩溃追踪  

• Xcode Instruments：适合开发阶段的精细调试；
• 克魔 KeyMob：核心测试与运维工具，支持跨平台与实时监控；
• itools：辅助测试，快速验证缓存与文件问题；
• Firebase：运维阶段的线上数据收集工具。

在 uni-app iOS 开发中，性能优化不能仅依赖单一工具。
通过 Xcode Instruments + 克魔 KeyMob + Firebase + itools 的协作，团队可以：

• 快速定位 CPU、GPU、内存、能耗问题；
• 验证优化前后的效果，确保版本稳定；
• 持续追踪线上数据，防止性能退化。

这种工具互补的方式，能够让 uni-app 应用在 iOS 平台上保持流畅与高效，真正提升用户体验。'''

管理员打开cmd，运行以下命令

adb kill-server && adb start-server

使用 HBuilderX 开发 uni-app (x) 应用，可以很容易地构建出一款鸿蒙应用。

多数开发者都是要通过华为的应用商店来发布自己的应用，但是也有开发者是为企业开发的内部应用，在这个场景下，只需要把应用的安装包分发给特定的少数用户就可以了。

华为的应用商店也支持这个场景，即非公开发布：开发者可以将不适合公开分发的应用以非公开方式在华为应用市场上发布，使其仅可通过链接被用户发现。

不过，对于开发者而言，要发布这样的应用有一定的资质要求，每次发版的时候也是要走流程，要接受审核，好处就是可以享受华为应用商店的分发服务。

所以，有些开发者希望能绕过这个发布流程，通过自有的下载服务直接向使用者提供安装包，即：内部分发。

HBuilderX 的开发流程是可以支持内部分发模式的，只不过有些环节需要手动操作来配合。

本文假设读者已经熟悉了 HBuilderX 开发鸿蒙应用的基本操作，下面我们就一步一步来看怎么实现应用的内部分发。

先说一下内部分发的局限性：

• 要有自己的下载服务，可以是自建的 Web Server，也可以是购买的云服务。

• 内部分发的目标用户是事先确定的（要先采集到他们的设备唯一标识），每个安装包可以分发给最多 100 个设备。

要实现内部分发，需要以下几个步骤：

一. 准备数字签名相关资料。

二. 用 HBuilderX 以【运行到鸿蒙】的方式得到 .hap 安装包。

三. 编写内部分发所需要的相关文件，并上传到服务器供用户下载。

下面详细说明每个步骤。我将使用 DCloud 官方提供的开源项目 hello-uni-app-x 来演示操作。

一. 准备数字签名相关资料

在 HBuilderX 里面打开项目的 manifest.json 文件，进入【鸿蒙App配置】，点击调试证书那个【配置】按钮。

弹出了【配置调试证书】的对话框：

能看到这里有个【自动申请调试证书】的按钮，但是，不要点击它！
因为用调试证书签名的安装包只能使用 hdc 命令安装到开启了开发者选项的手机上，这不是我们想要的。

我们需要自己到 AppGallery Connect 网站上手动申请用于内部测试的证书文件，然后再填写到这个对话框里。

注意上面的对话框里面有个【运行设备-检测】按钮，只要把开启了开发者选项的手机连接到电脑上，点击这个按钮就可以采集到设备标识。

完整的手动申请证书的操作可以看鸿蒙的官方文档，我这里只简要介绍一下步骤：

• 创建HarmonyOS应用

这一步需要留意的是你使用的应用包名。

• 注册设备

所有需要参与内部分发的手机都要先采集到设备标识，并 提交到 AppGallery Connect，后续申请 profile 文件时需要它们。

• 生成密钥和证书请求文件

这一步你将得到一个私钥库文件（.p12）和一个证书申请文件（.csr）。
请记住你使用的密码，有两个（一个是访问私钥库的密码，另一个是访问私钥的密码，但一般都使用相同的密码）。
也请记住你使用的私钥别名，这些在最后填写【配置调试证书】的时候都会用到。

• 申请发布证书

这一步需要上传 .csr 文件，你将得到一个发布证书文件（.cer），下载到本地备用。

• 申请内部测试Profile

这一步你将得到一个 profile 文件（.p7b），下载到本地备用。
【类型】请选择【内部测试】，【证书】就选择上一步得到的发布证书，【设备】请选上所有需要参与内部分发的手机，你应该已经把它们都提交过了。

做完上面这几步，你就可以回到 HBuilderX 中，打开【配置调试证书】对话框，把所有的内容都填好并保存。
【运行设备】那里只要有当前连接的设备就好了，对于最后生成的 .hap 没有影响。

二. 用 HBuilderX 以【运行到鸿蒙】的方式得到 .hap 安装包

在 HBuilderX 里面点击菜单项【运行>运行到手机或模拟器>运行到鸿蒙】，弹出运行对话框，选择好运行设备，点击【运行】按钮。

正常来说，应用就可以在手机上运行起来了，而你在 HBuilderX 控制台里面可以看到下面这些内容：

红框里的目录就是用于构建鸿蒙运行包的鸿蒙工程目录，在里面能够找到已签名的运行包：

对于内部分发而言，这个运行包就是所需要的安装包了，你可以把它改成一个更合适的名字（比如 my-internal-app.hap）备用。

请记住这个 app-harmony 目录，下一步有些需要的东西得在这个目录里找。

三. 编写内部分发所需要的相关文件，并上传到服务器供用户下载

这里假定你的服务器域名为 www.my-server.com。

1. 先上传两个文件，并得到下载链接。

把前面得到的安装包（.hap）上传到你的服务器，得到对应的下载链接，比如 https://www.my-server.com/my-internal-app.hap。

再准备两个图片文件，作为下载安装过程中显示的图标。按照鸿蒙官方文档的说法，需要准备一大一小两个图标，但我没有找到关于具体规格的说明，索性就直接用 app-harmony/AppScope/resources/base/media/foreground.png 这个文件把两者都代替了。
上传后也是得到了下载链接，比如 https://www.my-server.com/foreground.png。

2. 编写一个内部分发描述文件 manifest.json5。

须按照 鸿蒙官方文档 的指导编写这个文件。

由于这个文件编写好之后还需要进行签名，所以我们暂且保存为文件名 manifest-unsigned.json5，签名后将得到 manifest.json5。

其中有几个属性值可以从 app-harmony/AppScope/app.json5 文件里找到：

• bundleName
• versionCode
• versionName

还有几个属性需要特别说明一下：

• minAPIVersion 和 targetAPIVersion

在 app-harmony/build-profile.json5 文件中找到 app.products 数组，在里面找到 compatibleSdkVersion 值（可能有多个，但应该是相同的值），把 minAPIVersion 和 targetAPIVersion 都填成这个值就行了。

• deployDomain

这个是将来用于提供下载服务的域名，填写你自己实际的服务域名即可，比如前面说的 www.my-server.com。

• icons 里面的 normal 和 large

这里填写的是将来下载时显示的图标的网址，就填写前面上传图标文件得到的链接地址。

• modules

此项看上去比较复杂，需要参照 app-harmony/build-profile.json5 文件中的 modules 来改写，每个打包出来的独立模块都要在这里填写。

但实际上，多数情况下构建产物里只会有一个模块，就是主模块（该模块的 name 和 type 都是 entry），也就是前面提到的 .hap 文件。

• modules 里面的 packageUrl 和 packageHash

这里的 package 指的就是前面得到的安装包 .hap 文件，packageUrl 填写的是将来下载安装包时使用的网址，packageHash 填写的是这个安装包文件的 SHA256 哈希值。

• sign

这一项是对这个描述文件本身的签名，无需手动填写，下一步将使用签名工具来生成它。

写好的 manifest-unsigned.json5 文件大体上会是下面这个样子：

{  
  "app": {  
    "bundleName": "io.dcloud.uniappx",  
    "bundleType": "app",  
    "versionCode": 10907,  
    "versionName": "1.9.7",  
    "label": "Hello uni-app x",  
    "deployDomain": "www.my-server.com",  
    "icons": {  
      "normal": "https://www.my-server.com/foreground.png",  
      "large": "https://www.my-server.com/foreground.png"  
    },  
    "minAPIVersion": "5.0.1(13)",  
    "targetAPIVersion": "5.0.1(13)",  
    "modules": [  
      {  
        "name": "entry",  
        "type": "entry",  
        "deviceTypes": ["phone", "tablet", "2in1"],  
        "packageUrl": "https://www.my-server.com/my-internal-app.hap",  
        "packageHash": "27005caa60761b863fbf0fbcd0f96159386de038f59102f0ec676532cd49b084"  
      }  
    ]  
  }  
}

3. 对描述文件 manifest.json5 做签名并上传。

先下载 签名工具，注意其中的 manifest-sign-tool-1.0.0.jar，用 java 执行它：

java -jar "<manifest-sign-tool-1.0.0.jar的绝对路径>" \  
-operation sign \  
-mode localjks \  
-inputFile "<前面编写的manifest-unsigned.json5文件的绝对路径>" \  
-outputFile "<将要生成的manifest.json5文件的绝对路径>" \  
-keystore "<私钥库.p12文件的绝对路径>" \  
-keystorepasswd <私钥库密码> \  
-keyaliaspasswd <私钥密码> \  
-privatekey <私钥别名>

这样就会得到包含签名的 manifest.json 文件，上传到服务器，得到对应的下载链接，比如 https://www.my-server.com/manifest.json5。

4. 编写一个网页文件并上传。

编写一个 index.html 文件，内容如下：

<!DOCTYPE html>  
<html lang="zh-CN">  
  <head>  
    <meta charset="UTF-8"/>  
    <meta name="viewport" content="width=device-width, initial-scale=1"/>  
    <title>企业内部分发</title>  
    <script>  
      function openDeepLink() {  
        let url ='store://enterprise/manifest?url=https://www.my-server.com/manifest.json5'  
        window.open(url, '_parent')  
      }  
    </script>  
  </head>  
  <body>  
    <button onclick="openDeepLink()">下载安装</button>  
  </body>  
</html>

注意里面的下载链接，要替换成你自己实际的链接地址。

把 index.html 文件上传到服务器，得到对应的下载链接，比如 https://www.my-server.com/index.html。

好了，大功告成！

下面只要告诉参与内部分发的用户，用手机里面的鸿蒙官方浏览器打开这个网址，就可以点击其中的按钮下载安装了。

你也可以把这个网址做成二维码，让用户使用手机的浏览器扫码访问，这样会更方便。

10:16:09.631 开始编译插件 xxx-baichuan
10:16:13.391 uts插件[xxx-baichuan]编译失败
10:16:13.391 ⁠‌error: no such module 'AlibcTradeUltimateSDK'‌