标题上的Native库是指:Native分为静态库(
作者:nscript
链接:https://www.zhihu.com/question/536903224/answer/2522626086
(1)开发 NDK 库有人进行尝试:NativeAOT-AndroidHelloJniLib (https://github.com/josephmoresena/NativeAOT-AndroidHelloJniLib) 通过修改 .Net Runtime 来生成 Android 下的 NDK Native 库。希望后续官方能直接支持。
(2)Remobjects Elements (https://www.remobjects.com/elements/) 收费工具。可以采用 C# 语言开发 NDK Native 库,限制是不能自由使用 Core CLR,而是使用 Remobjects 的平台相关库 island 和跨平台库 RTL,RTL 库和 Core CLR 的相关类型接口相似。
Remobjects Elements 也可以用 C# 开发 wasm 模块,试用了下,满小巧的,gzip 下可以做到低于 1M,性能测试大约是 .net 6 的1/4-1/5。同上面一样,库这块会受到限制。
Remobjects Elements 的思路蛮有意思的,可以用 C#[或 Oxygene(Object Pascal), Swift, Java, Go or Mercury (VB)] 来写各种库或应用程序。Swift 语言的免费,其他的收费。可以用这些语言写native 程序、 .net 程序、 jvm 程序 ……
----
补充一下,这是个很值得探讨的问题,我一直在尝试用 csharp 代替 cpp。很多地方可以直接替代掉,但也遇到了一些问题:
(1)写底层算法或库的话,而调用者各种语言都有,csharp的,vb的,java 的,delphi 的都碰到过。那时的工作流程是,csharp 写算法,验证之后,再根据对方需求,改成 cpp。有 AOT 之后,这种情况可以避免掉。
(2)移动开发:安卓开发底层的库,参考资料太少。比如,开发个 sdk,给 java 调用,xamarin 资料太少,解决方案也不通用。
AOT 工具链完善后,对我来说,可以解决很多问题:
(1)写底层库:可以完全放心大胆的用 csharp 写底层库了,jit 模式下快速开发,aot 模式发布。csharp 的生产力比 cpp 高太多,构建系统也比 cmake 好使的多。我现在正在尝试优化 csharp 脚本开发 aot dll 的开发流程,目前还没完全完成,但也挺舒服的,以一个最简单的例子来说明,
lib.csx:
using System.Runtime.InteropServices;
[UnmanagedCallersOnly(EntryPoint = "add")]
public static int Add(int a, int b)
{
return a + b;
}
[DllImport("pack/out/lib.dll")]
private static extern int add(int a, int b);
int result = add(2,4);
Console.WriteLine(result);
一行命令就编译成 dll 了,win10下是964 k。
nscript pack --aot --lib lib.csx
再用下面指令调用脚本:
nscript .\lib.csx
输出:
6
这种开发模式可比写 cpp 舒服太多了。目前 aot 工具链还不够完善,但是开发起来难度不大,就是工作量的问题。比如,根据代码,直接生成各个语言的调用封装,生成文档 ......
这样一来,就可以用 csharp 快速开发出底层库,生成动态链接库、静态链接库给桌面用,给服务器用,给移动设备用。底层库一般不牵扯到ui,其通用性极强。做 android 的 ndk 开发太折腾,cpp 开发,jni 调用,调试麻烦得很。
这也可以解决 csharp 这块防止反编译的问题,发布时也可以 UI 层用 jit 跑,底层用 aot 跑来保护代码。
(2)开发小工具
我造过一个轮子,把 avalonia 的控件库的核心给拆出来,用 direct2d 来绘制,弄了一些基本的控件,写简单的桌面程序,aot 之后尺寸可以控制在 4M,如果写一些小工具还是可以的。
再比如说,如果想发布一些 server 端小工具,以 http 方式提供服务,jit 模式下,用 asp.net 来做,单个文件发布压缩之后可以做到20-30M, 用 EmbedIO 来写的话,单个文件发布,win下11M,linux 下 13M。EmbedIO用了反射,aot 我没配好,没跑出来,根据经验的话,aot 应该可以做到 2-4 M。不过,11M 也够用了,来看看用脚本写的代码:
#r "nuget: EmbedIO, 3.4.3"
using EmbedIO;
using EmbedIO.WebApi;
using EmbedIO.Actions;
using EmbedIO.Files;
WebServer CreateWebServer(string url)
{
var server = new WebServer(o => o
.WithUrlPrefix(url)
.WithMode(HttpListenerMode.EmbedIO))
.WithLocalSessionManager()
.WithStaticFolder("/static/", "./webroot", true, m => m.WithContentCaching(true)) // Add static files after other modules to avoid conflicts
.WithModule(new ActionModule("/api", HttpVerbs.Get, HandleApi))
.WithModule(new ActionModule("/", HttpVerbs.Any, ctx => ctx.SendDataAsync(new { Message = "Hello!" })))
;
return server;
}
Task HandleApi(IHttpContext ctx)
{
return ctx.SendDataAsync("api");
}
//@main
var url = "http://*:5000/";
var server = CreateWebServer(url);
server.RunAsync();
Console.ReadKey();
所以,工具链完善后,用 csharp 写东西很爽的:
(1)写完之后,AOT一下,给各个语言用 <--> 对标 cpp;
(2)写完之后,打包个几M 的小东西,扔服务器跑 <--> 是不是很像 golang?
(3)不建项目,像我上面那样用脚本写 <--> python;
(4)正常使用 <--> java;
(5)上 blazor <--> js。
除此之外,还有很新东西可以玩的 ......
----
一些场景替代不了:
(1)带 gc 的 .net aot,最小尺寸差不多1M,对于有的场景这个尺寸过大。比如说,对于插件系统,每个插件1M,100个就100M,过大,并且全部加载的话,有100个gc在跑,浪费。不知有没技术让100个插件共享一个 gc。虽然可以不开gc,但这样,就只是个大号的C了。
(2)对实时性要求高的场景,因为有gc存在会受到限制。
其他场景可以当有 gc 的 cpp 用,应该可以达到 cpp 80%+的性能。
其实现在jit,aot以及源生cpp性能都差不了太多,我做过密集计算的测试,细节忘记了,只记得是个 float 密集计算,java 的性能大于csharp和cpp。后来分析,jvm 做了向量化并行处理,csharp和cpp没有做。改csharp代码手动用simd,最后性能略高于Java。
aot的除了启动快,还有其他好处:(1)代码很难反编译;(2)尺寸小。
假设你要写个东西,给java调用或python调用,用 jit 的话,得几十M,aot 的话,可以做到 1M。这样的话,很多用cpp写的sdk,可以用csharp来写,aot编译成动态链接库,提供给上层用。
而不开gc的话,你可以就当他是个C语言的方言。
Windows以lib后缀名,Linux以a后缀 名)和动态库(Windows以dll为后缀名,Linux以so后缀名。 本文顺序先从生成Native程序.然后是动态库,最后是静态库。