在《优酷鸿蒙开发实际｜鸿蒙卡片开发》一文中曾经提到，要实现“在优酷主客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值为a1000000+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 [password] -storepass [password] //生成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 篇挪动技术实际&干货给你思考！
转载请注明原文链接：优酷鸿蒙开发实践｜优酷-Android-与HarmonyOS-Hap-混合打包
