共计 4727 个字符，预计需要花费 12 分钟才能阅读完成。
在《优酷鸿蒙开发实际|鸿蒙卡片开发》一文中曾经提到，要实现“在优酷主客 ICON 向上滑动，呼出优酷鸿蒙卡片”，须要卡片的实现代码与优酷主客做混合打包。上面的大节简略介绍了如何实现 Android/ 鸿蒙混合打包的流程。
以后，将大型 Android 利用 (下图图 1) 全副应用鸿蒙 API 改写是不事实的，所以华为设计了上述的演进路线。心愿将 App 中的性能由 Android 模块逐渐替换为鸿蒙 FA/PA, 并混合打包在一起进行散发(下图图 2)，最终到达 100% Pure 鸿蒙的最终状态(下图图 3)。
目前，咱们将优酷 Android 主客和鸿蒙 HAP 混合打包为一个产物，也就是图中“安卓 App 平滑演进及互操作”的两头态。
方才曾经提到，以后的优酷鸿蒙专版蕴含 Android APK 主体，以及桌面 Widget HAP，多屏互动 HAP。
因而，鸿蒙版优酷不仅领有 Android 版优酷的的所有性能, 还领有 Android 版不具备的一些非凡性能。
优酷鸿蒙版是在晚期吃螃蟹, 和华为一起合作开发鸿蒙版 App 先行者之一, 解决了大量理论工程难题，并且与华为独特解决了大量开发环境和运行时的 Bug，最终顺利地让优酷鸿蒙混合包上架华为利用商店。
打包计划 Battle
分包计划
将原 Android Apk 利用和 Harmony Hap（Hap 为 Harmony 利用编译产物，跟 Apk 角色统一）利用别离上架利用市场。
- 长处：Apk 和 Hap 能够不同包名，独自管制版本上架
- 毛病：用户须要同时下载安装 2 次才能够体验残缺性能
混合包计划
将原 Android Apk 和 Harmony Hap 混合打包成 App 上架利用市场。
- 长处：用户下载安装 1 次即可体验残缺性能，不用放心 2 个利用版本差别
- 毛病：打包生产绝对麻烦，对 apk 和 hap 有同包名限度
比照下，分包计划须要装置 2 次才能够实现整体性能体验，这显然是硬伤，合包计划尽管在开发生产侧麻烦一些，但能够给用户带来较好的体验，所以抉择了混合包计划。
混合包
什么是混合包？
Android 的产物是 Apk，Harmony 的产物是 Hap，将 Apk 和 Hap 混合打成一个总产物包称作为混合包（APP）。
混合包应用场景
场景 1：当 Harmony 版利用并不是一个残缺的性能，而只是作为原有 Android 利用的能力补充和加强时，须要将 apk 和 hap 打包成一个整利用。
场景 2：Android 利用短时间内无奈全副迁徙成 Harmony 版，分节奏迁徙过程中可采纳此计划进行混合打包作为一个供 Harmony 零碎可运行的利用。
混合包打包流程
名词解释：
- legacyApk：在原有失常 Android 工程和混合打包插件编译出的 apk 产物，此 apk 不能独立装置和运行，仅用于生产鸿蒙最终 app 的两头产物。如上图：混合打包流程理论就是将 legacyApk（通过加工的原 Android Apk 产物）和鸿蒙利用产物 Hap 打包成一个 App 包（zip）的过程。
混合包要求及限度
名词解释：
- 鸿蒙 entry： 对应 Android 的 application；
- 鸿蒙 feature： 对应 Android 的 module 或 bundle。
限度：
- 鸿蒙工程 entry 中将作为 apk 的父容器，所以不能蕴含任何代码和资源，需将所有的代码和资源移到 feature 中；
- 鸿蒙 entry 和 feature 们的 config.json 中必须保持一致，并且与 Android 的 versionCode versionName 保持一致；
- Android 利用（legacyApk）必须为 64 位包，不能蕴含 32 位的 so。
要求：
- 鸿蒙利用必须与原 Android 利用同包名；
- 混合打包要求 hap（类 Android 的 agp）版本 >= 2.4.2.2，apiVersion（类 Android 的 targetSdkVersion）须要 >=5；
- 鸿蒙利用启动时理论还是独自利用，为了放弃跟原 Android 技术品牌统一，须要放弃 entry 中的 config.json 中的 label 和 icon 与原安卓利用中统一。
生成步骤
第一步：原 Android Apk 侧批改
为了干涉原 Apk 的启动流程，减少鸿蒙利用的启动入口，须要干涉 Android 的 application。鸿蒙侧提供了工程侧打包编译的 plugin，但因为优酷是组件化开发模式，application 作为一个独自的 aar 模块存在，所以混合编译 plugin 并不是实用。
计划：通过理解混合编译 plugin 的职责，间接在 application 模块手动批改父类为 AceHarmonyApplication（ohos.ace.ability.AceHarmonyApplication，此类在鸿蒙提供 abilityshell.jar 中），并手动在 manifest 中增加用于鸿蒙兼容性属性如下：
<!-- 鸿蒙兼容性属性 -->
<uses-feature android:name="zidane.software.ability"
android:required="false" />
<meta-data android:name="permZA" android:value="true" />
<meta-data android:name="multiFrameworkBundle" android:value="true" />将 application 模块集成进 Android 工程，编译后失去产物 legacyApk。
第二步：鸿蒙工程侧批改
1、配置工程参数
build.gradle：entry 和所有 feature 中的 build.gradle 的 compileSdkVersion、compatibleSdkVersion 改成 5（混合包最小反对版本要求为 5）；
config.json：
- entry 和所有 feature 中的 config.json 的 apiVersion 中的 compatible 和 target 改成 5；
- entry 和所有 feature 中增加 originalName 属性并放弃跟 bundleName 统一；
- entry 和所有 feature 中增加 version，并放弃子属性 code 等于 Apk 中的 versionCode，子属性等于 Apk 中的 versionName；
- entry 和所有 feature 中的 vendor 保持一致，config.json 中的 code 和 name 有要求，name 举荐为三段式 ”a.b.c” Code 值为 a 1000000+b1000+c。如 Name 为 1.001.003，Code 值为 1001003。
{“app”:{
"bundleName”:”包名”, // 这是鸿蒙利用包名，混合包要求必须与 Apk 包名统一"vendor”:”xxx”,//entry 和 feature 中要统一
"version":{
"code":xxx,// 对应 Android VersionCode 要求高于 apk 版本，并且依据 name 拼接而成
"name”:”xxx”// 对应 Android VersionName
},
"apiVersion":{
"compatible":5,// 5 才反对混合包
"target":5,
"releaseType":"Release"
}
}
}2、在 entry 模块增加 legacyApkOptions 配置
apply plugin: 'com.huawei.ohos.hap'
ohos {
...
legacyApkOptions {
legacyApk"..\..\legacy_entry.apk" // 指向 legecyApk 文件，并且必须以 entry.apk 结尾
legacyVersionCode "499" // 与 legacyApk 的 AndroidManifest.xml 中配置的 android:versionCode 保持一致
legacyVersionName "9.15.2" // 与 legacyApk 的 AndroidManifest.xml 中配置的 android:versionName 保持一致
}
}3、entry 批改
将 entry 中的所有代码和资源移到 feature 中（鸿蒙工程容许有一个 entry，能够有多个 feature）；增加一个空的 Ability 页面，并批改 icon 和 label 与原 Android 利用统一。
第三步：签名
签名是混合打包中最麻烦的一步，这也是鸿蒙开发最非凡的一步，须要拿原签名文件 (jks 或者 p12) 用 DevEco Studio 生成 csr，而后去华为利用市场申请签名的证书（cer）文件和 Profile（p7b）文件，更多详情也参考华为帮忙文档（https://developer.huawei.com/…）
因为混合包要求 APP 的签名信息要与原 Android 的签名信息统一，所以失常状况下用原 Android 的签名文件（jks）就能够了，但鸿蒙为了安全性，晋升了签名的安全性要求：
- 必须应用 EC 算法
- 密钥明码要”大小写字母 / 数字 / 非凡字 符，至多两种的组合，长度大于等于 8
如果签名文件构建的工夫比拟早，这两个要求都不合乎的话，华为侧提供了如下解决方案：
1、能够应用原 Android 签名文件独自配置 shell Apk 签名
apply plugin: 'com.huawei.ohos.hap'
ohos {
...
legacyApkOptions {
...
signConfig {storeFile file("..\legacyApkJks.jks") // 独自配置的 shell apk 签名资料
}
...
}
}2、应用 keytool 命令行生成 p12 文件和 csr 文件，但要求别名和秘钥跟原 Android 签名保持一致，并且应用 EC 算法
// 生成 p12
keytool -genkey -alias [keyname] -keystore [p12.file] -storetype pkcs12 -keyalg EC -keypass 此处含有隐藏内容，需要正确输入密码后可见！
-storepass 此处含有隐藏内容，需要正确输入密码后可见！
// 生成 csr
keytool -certreq -alias [keyname] -keystore [p12.file] -storetype pkcs12 -file [csr.file]申请下来 cer 和 p7b 文件（须要独自申请调试和公布证书）后，就能够在开发工具中配置签名文件了（更多配置详情也阅览华为配置签名帮忙文档 https://developer.harmonyos.c…）。
而后通过开发工具 DevEco Studio 中 build -> Build Apps 编译失去产物 APP。
工程构造概述：
混合包产物剖析
通过下面的一系列流程，就能够生成一个供鸿蒙运行的混合包了。
因为是公布证书签名，这个混合包实际上是不能间接手动装置到 Harmony OS 上，还须要通过华为平台侧（须要分割华为侧接口人）签名，提供转换之后的安装包供优酷方面测试应用。
测试结束之后，能够间接拿这个混合包上架到华为的鸿蒙利用市场。
鸿蒙版本发版经验总结
- 鸿蒙混合包只有 64 位包；
- 鸿蒙混合包在鸿蒙市场发版节奏、版本号等最好是跟原安卓发版节奏、版本号等保持一致，不然须要非凡思考鸿蒙版本的数据定投问题；
- apk 和 hap 在 app 中理论是物理辨别，打包 app 的时候并不会把 apk 从新编译，所以如果 apk 和 hap 存在同名的类（因为都是 java 类），依据双亲委派机制，在运行时将会呈现问题；
- 如果原安卓利用蕴含通讯录、拨打电话权限，在华为平台申请 p7b 文件时肯定须要勾选申请应用受限权限，如下图：
最初，下周《优酷鸿蒙开发实际》系列第三篇技术文章，咱们将以优酷播放核心的技术储备为切入点，联合鸿蒙零碎的镜像和流转个性，具体介绍一般流转、自在视角和 zoom 等外围能力在鸿蒙上的实际之路。
感激关注【阿里巴巴挪动技术】，咱们下篇技术实际再见。
关注咱们，每周 3 篇挪动技术实际 & 干货给你思考！
