.NET适配HarmonyOS进展的方法
1. 前言 这确实是一个非常值得聊的话题。眼下国产化系统的浪潮已经铺开，适配鸿蒙（HarmonyOS Next）几乎成了每一款国产软件必须迈过的门槛。而在前端、后端都能打的.NET，作为最适合开发客户端编程的语言之一，怎么在鸿蒙系统上真正跑起来，成了很多.NET开发者心头最挂念的事。我来说说目前正在
1. 前言
这确实是一个非常值得聊的话题。眼下国产化系统的浪潮已经铺开，适配鸿蒙（HarmonyOS Next）几乎成了每一款国产软件必须迈过的门槛。而在前端、后端都能打的.NET，作为最适合开发客户端编程的语言之一，怎么在鸿蒙系统上真正跑起来，成了很多.NET开发者心头最挂念的事。我来说说目前正在推进的情况——从去年在.NET Conf CN上分享过初步成果之后，利用业余时间一直在移植A valonia到HarmonyOS，如今又有了些实质性的突破，干脆把过程中遇到的所有问题整合起来，和朋友们一起聊聊。
2. 项目状态
当前阶段，.NET已经可以顺利在HarmonyOS Next上运行。而A valonia的移植项目也已经在真机上跑起来，不过这篇文章的重点还是放在.NET适配层面的具体工作上。
3. 运行时
首先要弄清楚的是，从HarmonyOS 5.0.0（12）版本开始，系统禁止匿名内存申请可执行权限。这就意味着，除了系统内置的Ja vaScript引擎外，其他虚拟机想要使用Jit功能根本行不通。所以直接接入CoreCLR这条路是堵死了。最新的Mono虽然能走解释执行的路子，但性能上的牺牲太大，从实践来看也不现实。最后的结果非常明确：只有NativeAOT运行时才是唯一可行的接入方案。
4. NativeAOT
那么，为什么NativeAOT能接进来？关键在于鸿蒙系统兼容libc，是musl那种Linux系统的动态库（.so）。而.NET本身就有针对linux-musl-arm64和linux-musl-x64的RID支持，这意味着理论上我们可以直接把.NET程序编译成原生的Linux动态库（.so），然后在鸿蒙的原生项目里用dlopen和dlsym来调用C#里的入口函数。
反过来说，C#调用鸿蒙的API，则是通过P/Invoke去调用鸿蒙的NDK。至于ArkUI里的TypeScript API，则是通过NDK中提供的napi来实现调用。这番联动逻辑清晰，可以看看我正在进行的A valonia移植项目：https://github.com/OpenHarmony-NET/OpenHarmony.A valonia
5. 已知问题
5.1 syscall限制（已解决）
鸿蒙系统用上了seccomp机制来限制危险的syscall调用。听起来很专业，但它的做法相当“硬核”——不是宽松地返回错误码，而是发现非法调用就直接把进程干掉。.NET运行时初始化时会触发一个叫__NR_get_mempolicy的系统调用来检查numa支持，可惜这个调用不在鸿蒙的seccomp白名单里，所以程序就直接宕了。
鸿蒙的seccomp白名单在这里可以看到：https://gitee.com/openharmony/startup_init/blob/master/services/modules/seccomp/seccomp_policy/app.seccomp.policy
其实安卓里也有类似的限制，但.NET的NativeAOT之所以能在安卓平台下正常跑，是因为.NET针对安卓平台做了特殊处理。而鸿蒙这边，我们直接用了Linux平台的代码，自然没照顾到这些细节。解决办法倒也不复杂——自己动手修改源码，把numa这部分函数全部替换成空函数即可。
5.2 mmap申请虚拟内存过大（已解决）
第一个问题解决完之后，运行时初始化还是崩溃。排查了很久才发现，原来GC初始化时会申请大约256G的虚拟内存，mmap直接返回了Out Of Memory错误。这显然有备而来，但解法也明确：要么设置环境变量DOTNET_GCHeapHardLimit，把虚拟内存申请控制在180G以下；要么直接修改源代码，把USE_REGIONS宏关掉即可。
5.3 ICU、OpenSSL等第三方库缺失（已解决）
鸿蒙本身不会自带ICU和OpenSSL这类库，只能另想办法。有两种路径可以走：方案一——从Alpine上“偷”包，因为Alpine的libc就是musl，所以Alpine的库在鸿蒙上基本都能用。arm64架构的包可以从阿里云镜像拿：https://mirrors.aliyun.com/alpine/edge/main/aarch64/；x64架构的则是：https://mirrors.aliyun.com/alpine/edge/main/x86_64/。方案二——如果那个库本身是cmake项目，直接通过鸿蒙的CMake工具链编译就完事了。
5.4 ICU初始化失败（已解决）
鸿蒙的ICU配置文件路径和默认路径不一样，需要手动调用修改环境变量的API，把ICU_DATA改成/system/usr/ohos_icu。而且鸿蒙使用的libICU大版本是72，必须用这个版本的库才能正常跑起来。
5.5 NativeAOT如何跨平台编译（Windows平台已解决）
NativeAOT有个众所周知的弱点——不支持跨平台编译。我的方案需要发布到linux-musl平台，所以如果只用Windows开发，效率会大打折扣。好消息是，可以直接在项目中引用这个开源项目：https://github.com/OpenHarmony-NET/PublishAotCross，它专门解决了跨平台编译的问题。
5.6 无法调用Marshal.GetDelegateForFunctionPointer相关函数
这个也值得多说两句。Marshal.GetDelegateForFunctionPointer的实现依赖动态生成汇编，但鸿蒙系统不支持动态生成汇编代码执行（即Jit），直接调用肯定会崩。替代方案是用函数指针直接调用，就能绕开这个障碍。
6. 如何修改NativeAOT代码
前面提到好几个问题需要改源码，具体操作可以参考以下步骤。在Linux平台下（需要搭建好编译环境），修改完代码后执行下面的命令进行编译：
./build.sh --subset clr.aot --configuration Release -arch arm64 --cross |
编译成功之后，打开目录 运行时/artifacts/bin/coreclr/linux.arm64.Release/aotsdk，把里面所有内容替换到本机nuget的缓存目录，比如C:\Users\用户名\.nuget\packages\runtime.linux-musl-arm64.microsoft.dotnet.ilcompiler\dotnet版本\sdk。
7. 相关链接
https://github.com/dotnet/runtime/issues/110074
https://github.com/dotnet/runtime/issues/111649
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
AirBuddy 3 是面向 macOS 的蓝牙外设增强工具，可集中查看 AirPods、Beats 与苹果设备电量，提供快速连接、播放控制、电量提醒、桌面小组件和多台 Mac 外设接力等功能。
AirServer macOS版可把 Mac 转换为无线投屏接收端，通过 AirPlay 或 Google Cast 接收手机、平板和电脑画面，并支持多设备同时连接、高清镜像及会话录制，适合家庭娱乐、课堂教学、会议演示和应用展示。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
PixTV 是一款在浏览器中使用的 AI 视觉内容创作平台，提供图片、视频、音频、文字生成、AI 分镜、局部重绘、提示词反推和无限画布等工具，适合短剧、漫剧、广告及社交媒体内容制作。
Autodesk Maya 是面向影视、电视、动画和游戏行业的专业三维制作软件，集多边形与 NURBS 建模、角色绑定、关键帧和动作捕捉动画、Bifrost 特效模拟、材质开发及 Arnold 渲染于一体，