At present, under the wave of localization system, adaptation to Hongmeng is the general trend of Chinese software. As one of the most suitable client languages for development, .NET adapts to HarmonyOS Next. The most important thing for .NET developers. I'm currently porting Avalonia to HarmonyOS in my spare time, and last year I was working on it. NET Conf CN, and a little progress has been made, so this article will integrate all the issues and share them with you.
2. Project status
For now. .NET can run successfully on HarmonyOS Next.
The Avalonia porting project can initially be run on some large memory real machines, which is mainly discussed in this article. .NET adaptation related work.
3. Runtime
Since HarmonyOS 5.0.0(12), anonymous memory is prohibited from applying for executable permissions, except for the built-in JavaScript engine of the system, other virtual machines cannot use Jit functions, so CoreCLR cannot be connected to the HarmonyOS system, and although the latest version of Mono supports interpretation and execution, it will not be connected to the Mono system due to performance problems. In the end, you can only choose to connect to the NativeAOT runtime.
4. NativeAOT
The principle that supports HarmonyOS to access NativeAOT is that the HarmonyOS system is compatible with libc, which is a dynamic library (.so) of the Linux system of musl. And the .NET RID supports linux-musl-arm64/linux-musl-x64, so theoretically you can use . The .NET program is compiled into a native Linux dynamic library (.so), and then in the native project of HarmonyOS, the entrance function in C# is called through functions such as dlopen and dlsym.
C# calls the HarmonyOS API through P/Invoke to call the HarmonyOS NDK, while ArkUI's TypeScript API calls through the NAPI in the NDK.
The HarmonyOS system uses seccomp to limit dangerous syscall calls. Under the standard POSIX, if the system does not support a certain syscall, an error code is returned, while SecComp is very aggressive, if an illegal sycall is called, the process is directly killed. When the runtime of .NET is initialized, a __NR_get_mempolicy system call will be called to check the numa support, and this system call is not in the HarmonyOS seccomp whitelist, so it will cause direct downtime.
In fact, there are similar restrictions in Android. The reason why .NET's NativeAOT can run on the Android platform is because .NET has special processing for Android, while on the HarmonyOS platform, we use the code of the Linux platform, so these system calls are not handled.
The solution is to modify the code yourself to change all the functions of numa to null
5.2 mmap request for excessive virtual memory (solved)
After solving the previous problem, . After investigation, it was found that the GC would apply for about 256G virtual memory during initialization, resulting in an Out Of Memory error returned by mmap.
Solution 1: Set the environment variable "DOTNET_GCHeapHardLimit" to control the virtual memory request to about 180 GB or less.
Solution 2: Modify the source code and turn off USE_REGIONS macros.
5.3 ICU, OpenSSL and other third-party libraries are missing (solved)
Solution 1: Steal packages from Alpine, because Alpine's libc is musl, so theoretically Alpine's libraries can be used mostly on HarmonyOS.
Solution 2: If the library has a cmake project, it can be compiled through HarmonyOS's CMake toolchain.
5.4 ICU Initialization Failure (Resolved)
The ICU configuration file path of HarmonyOS is different from the default path, and you need to call the Modify Environment Variable API to modify the ICU_DATA to /system/usr/ohos_icu And the major version of libICU on the HarmonyOS platform is 72, so you need to use this version of the library.
5.5 How NativeAOT Compiles Cross-Platform (Windows Platform Resolved)
NativeAOT is known to not support cross-platform compilation, and my solution needs to be released to the linux-musl platform, so it cannot be released on Windows, which affects development efficiency.
The solution to some of the problems mentioned above is to modify the source code, and the specific steps are as follows: After modifying the code, run the following command to compile (under the Linux platform, a compilation environment is required):
After compiling successfully, open the directory and replace everything here with the cache directory of your computer's nuget, for example(of a computer) run hour/artifacts/bin/coreclr/linux.arm64.Release/aotsdkC:\Users\user ID\.nuget\packages\runtime.linux-musl-arm64.microsoft.dotnet.ilcompiler\dotnetreleases\sdk
