鸿蒙剥离 AOSP 不兼容 Android 热门问题汇总,不吹不黑不吵

上周发了一篇 《鸿蒙终于不套壳了?纯血 HarmonyOS NEXT 即将到来》的相关资讯,没想到大家「讨(fa)论(xie)」的热情很高,莫名蹭了一波流量,虽然流量对我来说也没什么用,但几百条评论也收获了一些比较有意思的问题,随着评论区「沦陷」,这里统一挑出来汇总下。

⚠️PS,不卖课不推广不站队,只考虑技术角度,如果有更进一步的材料或者问题就更好了,因为目前大部分人都在观望和评估

首先讨论的前提 是基于 「HarmonyOS NEXT 版本,去掉了传统的 AOSP 代码,仅支持鸿蒙内核和鸿蒙系统的应用 」的场景,既然是剥离,那就不是「不支持 apk 后缀安装」的场景了,那么适配的工作量也就随之而来。

目前已经有一些企业在进行适配或者已经适配的,适配的方式基本都是基于 skia 的场景去实现,因为 HarmonyOS NEXT 的渲染底层还是 skia ,所以做一些兼容转化,游戏不用说,基于 OpenGL 和 unity 兼容难度相对不高,主要还是集中于 App 如何兼容的适配等问题上。

那么接下来就是一些有趣的热门问题汇总

鸿蒙应用能安装在 Android 系统上吗?

鸿蒙现在用的是 ArkTs 和 ArkUI ,它们成了唯一指定语言和框架,按照目前的情况看,ArkUI 是无法直接用到 Android 系统,但是华为开源了另外一个项目 ArkUI-XArkUI-X 扩展ArkUI 开发框架到多个 OS 平台,所以从这个角度看,鸿蒙应用又可以运行到其他平台

不负责任的说,有点类似于 compose 和 compose-multiplatform 的关系

当然,ArkUI-X 项目并不是从 0 开始,它和 Flutter 还是有一些缘分

ArkUI-X 项目属于 OpenHarmony 管理,而在 OpenHarmony 下存有 third_party_flutter 等项目依赖,ArkUI-X 里 Flutter 应该只是用于窗口管理和渲染管道到 skia ,没用到 Dart 部分的 UI 框架 ,类似于之前提到的微信小程序 skyline 底层利用 Flutter 渲染输出场景类似。

虽然 ArkUI-X 让鸿蒙 App 可以运行到其他平台,但是大家目前更多诉求是现有 App 可以继续「兼容」到鸿蒙 Next。

鸿蒙 Next 升级会造成断代吗?会和WinPhone 一样滑铁卢吗?

确实,一旦鸿蒙开始正式不支持 Android ,那么对开发者生态和用户肯定会有直接的「冲击」,这也是鸿蒙 Next 需要面对的最大门槛。

目前我个人理解,鸿蒙的策略就是先稳住大厂,尽量让大厂能跟进「首发适配」,已知的小红书、百度、美团、京东等企业都有一定鸿蒙基础,一些团队也许是基于 KPI ,也许是基于领导要求,都提前开始了 鸿蒙 Next 的支持,所以鸿蒙 Next 在初步生态基础上还是比当年的 WinPhone 好一些。

例如美图曾经就有在 skia 层适配鸿蒙的 《让 Flutter 在鸿蒙系统上跑起来》

当然,鸿蒙肯定不会一上来就强制升级,到时候正式推送更新的时候,应该会有提示框告知用户,我猜测会双线「鸿蒙 4」 和「鸿蒙 Next」 共存维护一段时间,就是你不更新,可以继续用打补丁的鸿蒙 4 过度较长的一段时间,过渡期和用户维护还是需要的。

接下来是「个人屁话」时间,用于解释另外一部分评论问题:

从目前来看,鸿蒙 Next 是个博弈,就是华为有存量用户,也有新增用户,就是博弈企业的产品愿不愿意放弃这部分市场份额:

之前的评论区说到的,如果网易音乐适配了,那 QQ 音乐是否会跟进?这是一个看谁愿意卷的问题。

目前华为市场份额大概 9.2%,鸿蒙现阶段还只在国内,Counterpoint 披露的数据显示,2023 年 Q1,在中国市场,鸿蒙操作系统的市占率为 8% 。。。。。而 2023 年第一季度,在中国市场,安卓系统占据 72% 市场份额,iOS为 20%,所以这是一个存量市场和新增市场的博弈

华为手机销量从 2.4 亿台(2019年)达到高峰后,跌至3,000万台(2022年),而 2023 Q1 开始对比 2022 逆势增长41%,所以 2023 年给的目标手机出货量是 4000 万部。

这部分问题在于,它说多不多,但是你说它少,又不能完全忽视,毕竟有存量有新增。

扯远了,这个话题最后说一下两个担心的问题:

  • 升级到 Next 之后,应用数据是否支持升级兼容 ,在整个系统框架都剥离重组的情况下,原先应用的本地数据是否支持兼容或者迁移,这是一个非常影响升级指标的因素,或者说升级后丢失率多高
  • App 后续支持也是一个风向标,应用厂商在鸿蒙上「首发」App 之后,是否能和 Android/iOS 平台一样及时迭代跟进,还是「又不是不能用」的维护躺平?

鸿蒙为什么可以通过 OTA 升级剥离 AOSP?如何兼容高通芯片的机器?

这是评论区一个热门讨论点之一,首先大家可能会觉得,自己如何更新自己的内核?看评论区有人的提到的就是「一个人如何举起自己来」。

这里我也不知道鸿蒙更新的具体路线,根据我的理解和评论区的内容,这里做一些总结:

  • 首先 AOSP 是基于 Linux 内核开发,也就是 AOSP 虽然有 Linux 内核,但是它是以特殊形式存在 AOSP 里,因为一些历史 GPL 传染性协议问题,AOSP 不是一个 GUN Linux发行版,所以 AOSP 和 Linux 内核可以分开处理。
  • 类似于 OpenHarmony 使用 LiteOS 内核,HarmonyOS 这层壳可以在 LiteOS 与 AOSP 直接切换,「十分不严谨」的比喻:「Flutter 可以通过升级把底层渲染从 skia 更新到 Impeller」,这次 Harmony Next 提到的应该是替换为 "鸿蒙内核"与"华为方舟图形引擎"。
  • 类似 Android 的 bootloader 是支持 A/B 更新,可用于引导和传递需要加载对应内核:source.android.com/devices/tec...

以上这个主要是从技术层面介绍「一个人如何举起自己来」的实现,仅作为猜测,不一定是鸿蒙的路子

另外,华为现存高通芯片和麒麟芯片的机器,这些机器如何通过 OTA 升级支持到 Harmony Next ?麒麟不必说,高通如何可以直接说升级兼容?

这个就要说到原本 AOSP 里面的 HAL(Hardware Abstraction Layer) 层的作用了,例如在 Android 8.0之后,framework 与 hal 进行了解耦, framework 存在于 system.img,hal 存在于 vendor.img,进行版本升级时,分为两次升级。

SoC 厂商的兼容,可以通过适配 hal, 将修改打包到 vendor.img, 生成OTA 升级包,推送到手机进行 OTA 升级(framework发生改变,hal 层发生改变) 。

具体可以参考: m.elecfans.com/article/202...

这里有个关键词,SoC 厂商的兼容,也就是到时候可能会是 mate40系列(麒麟)更早可以更新到 next,mate50 系列(高通)会相对晚一些。

剥离后的鸿蒙OS怎么样?和原本 Android 还像吗?开发方式如何?

这个问题大家还是比较关心,用评论区一位网友的总结就是:

" ArkUI这玩意大量使用了napi, 逻辑几乎都封装在c++写的framework里,说个笑话: 用他们的弹框组件改个圆角值都改不了,因为底层写死了。

framework大量借鉴了Android(看ability启动源码可以很好复习activity启动的八股文) , 权限和组件封装又和iOS靠齐,可以说非常适合跨平台开发踩坑。"

所以从 java 层面 Android framework 等的代码已经不见了,Harmony Next 的 framework 基本封装在 c++ 层,与平台调用多数走 ffi 调用。

是不是有一种熟悉的味道?嗯,是 Flutter 的味道。

开发体验上类似 Flutter/Compose 项目,如果硬要说,可能会是像是 SwiftUl 和 Compose 的优点缝合?主要是声明式 UI开发,然后链式写法和组件命名对于客户端开发来说应该会很有熟悉感。

开发构建上,鸿蒙 Next 使用的 ArkTS 类似 Dart 构建模式,都是 AOT ,ArkTS 通过 ArkCompiler 构建并优化成机器码:

ArkCompiler 利用 ArkTS 的静态类型信息,进行类型推导并生成对象描述和内联缓存,加速运行时对字节码的解释执行;AOT(Ahead-of-Time)Compiler 利用静态类型信息直接将字节码编译生成优化机器码......

之所以提一嘴这个编译,是因为有如下图类似的评论,质疑 ArkTS 是一种网页应用的,所以也就当纯做一个回应,虽然叫 TS,但是其实它并不能「直接」开发 Web。

顺带提一句,华为这次还是「明确」指出了,ArkTS 是在 TypeScript(简称TS)的基础上进行自研的开发语言,就是不知道这个到了自媒体宣传上会如何解读了。

接着不得不提一句的就是 「三棵树」,Flutter 开发应该对于这个很熟悉,官方的解释是:

ArkUI3.1 通过编译期生成特定函数的方式将 UI 组件更新和数据变更进行细粒度地绑定,实现 UI 更新 Diff 算法从 COMPONENT 和 ELEMENT 树形结构对比升级为单节点 NODE的函数式更新。

从这里看,如图所示还是熟悉的味道 ,其实 「ArkUI 对 Flutter 开发者确实很友好」

最后,ArkUI 还提供了一些「高级UI组件扩展能力」大概就是:

  • XComponent 组件的 C++ 自绘制引擎接入(比如游戏引擎)能力
  • 基于Web组件的 HTML5/Web 的渲染能

主要是为了满足开发者在游戏、相机、地图、浏览器等复杂应用场景的开发诉求,降低了这类应用移植的门槛。

关于这部分有待后续大家的体验报告了,可以理解此时大概就是「又不是不能用」的情况。

是否会关闭侧载?

其实这个问题我也很好奇,不过我也不确定,Harmony Next 是不是会让自己生态「对齐」 iOS ,因为这个决定很大程度会影响它以后的命运。

我这里不负责任的猜测是很大概率会关闭侧载,先说明这个我没有任何依据,仅仅是一个猜测,因为既然都不兼容 Android ,那么作为一个全新的系统模式下,构建生态可以会因为「安全」和「合规」等考虑,按照目前「大环境」的理解,我更倾向它最终会关闭侧载。

我只是更倾向最终可能会关闭侧载,但是我不希望关闭侧载。

现有 App 如何兼容 Harmony Next ?

纯原生应用(Java/Kotlin + XML)模式直接兼容的可能性,或者说兼容方案目前我是看不到直接兼容的可能性,因为没了 JVM ,没了AOSP ,非响应式布局开发,直接兼容的成本不低于从头再来。

跨平台框架支持上:

  • Cordova/Ionic 等本身只需要 WebView 和 JSBridge 等相关支持,兼容反而不难,就是插件部分需要额外补充,成本相对较低
  • React Native / Weex 部分工作量偏重,前端标签到原生控件映射的适配,还有样式兼容会是一个「体力活」,插件生态也是一个问题
  • Flutter 因为前面提到过的种种原因,纯 Flutter 兼容 Harmony Next 成本不会很高,但是未来可能会产生「分叉」,因为目前 Flutter 官方已经开始逐步采用自研 Impeller 替代 skia 渲染,这后续可能会和 Harmony Next 出现分叉,另外插件生态兼容会是一个特别头痛的问题
  • uni-app/uts ,这个我不负责的猜测后面它自己就会直接适配了,丝毫不慌。

GSYVideoPlayer 有适配鸿蒙计划吗?

没有

最后

好了,目前主要的问题就这些,如果有什么问题欢迎大家「心平气和」地讨论,如果有什么有用的新话题点,到时候会补充上来。

我不是「专业」的,我只是练习时长两年半的「小黑子」。

相关推荐
雯0609~4 分钟前
网页F12:缓存的使用(设值、取值、删除)
前端·缓存
℘团子এ7 分钟前
vue3中如何上传文件到腾讯云的桶(cosbrowser)
前端·javascript·腾讯云
学习前端的小z13 分钟前
【前端】深入理解 JavaScript 逻辑运算符的优先级与短路求值机制
开发语言·前端·javascript
彭世瑜37 分钟前
ts: TypeScript跳过检查/忽略类型检查
前端·javascript·typescript
FØund40437 分钟前
antd form.setFieldsValue问题总结
前端·react.js·typescript·html
Backstroke fish38 分钟前
Token刷新机制
前端·javascript·vue.js·typescript·vue
小五Five39 分钟前
TypeScript项目中Axios的封装
开发语言·前端·javascript
小曲程序39 分钟前
vue3 封装request请求
java·前端·typescript·vue
临枫54140 分钟前
Nuxt3封装网络请求 useFetch & $fetch
前端·javascript·vue.js·typescript
前端每日三省41 分钟前
面试题-TS(八):什么是装饰器(decorators)?如何在 TypeScript 中使用它们?
开发语言·前端·javascript