鸿蒙剥离 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 有适配鸿蒙计划吗?

没有

最后

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

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

相关推荐
帅得不敢出门1 分钟前
Gradle命令编译Android Studio工程项目并签名
android·ide·android studio·gradlew
我要洋人死8 分钟前
导航栏及下拉菜单的实现
前端·css·css3
科技探秘人20 分钟前
Chrome与火狐哪个浏览器的隐私追踪功能更好
前端·chrome
科技探秘人20 分钟前
Chrome与傲游浏览器性能与功能的深度对比
前端·chrome
JerryXZR26 分钟前
前端开发中ES6的技术细节二
前端·javascript·es6
七星静香28 分钟前
laravel chunkById 分块查询 使用时的问题
java·前端·laravel
q24985969330 分钟前
前端预览word、excel、ppt
前端·word·excel
小华同学ai36 分钟前
wflow-web:开源啦 ,高仿钉钉、飞书、企业微信的审批流程设计器,轻松打造属于你的工作流设计器
前端·钉钉·飞书
problc40 分钟前
Flutter中文字体设置指南:打造个性化的应用体验
android·javascript·flutter
Gavin_9151 小时前
【JavaScript】模块化开发
前端·javascript·vue.js