[间章] 关于重写platform判断平台的一些尝试

在开发shine_image思考的时候,我在空闲时间写下这两段代码。主要是借用rust来对宿主平台进行判断。

由于flutter本身的platform判断不了鸿蒙与各家厂商的系统ui,而我是能不写双端代码就不写的原则,所以简单的尝试了下,倒是没想到成功的如此简单。

首先我们先在rust侧,编写一个enum

pub enum Platform {
    Unknown,
    Android,
    Ios,
    Windows,
    Unix,
    MacIntel,
    MacApple,
    Wasm,
    HarmonyOSVersion2,
    HarmonyOSVersion3,
}

就是各个系统,我判断了HarmonyOS系统,其实如果你想判断miui,emui,flyme,烂橘子之类的,都是可以的,后面会说明。

由于不做处理,HarmonyOS会被默认识别为Android,但它又是个很特别的系统,所以重视一些。

然后我们通过rust的cfg!()宏进行判断宿主环境。由于cfg支持的平台只有图中这些:

所以直接判断HarmonyOS的想法是不现实的。而通过std::env::args获取的系统标识,经过实测emui与HarmonyOS是一致的。也就没法用它来判断。

于是我想到安卓的getprop命令,在rust侧能否拿到它,实际查询了一下,发现用std::process::Command确实是可以拿到prop信息的,这里我编写了一个check_description()方法,并将它输出到flutter侧。

拿我的魅族17pro测试,在页面输出如图:

看到了很多熟悉的prop了吧,这里的ro.build.flyme.version就可以用来判断是否是flyme平台,类似于emui,miui也可以通过ro.build.version.emuiro.miui.ui.version.name之类的进行判断,总之这些第三方厂商ui都会往里面塞一些自己家的信息。

HarmonyOS中会有哪些信息值得我们重视的呢?

打印HarmonyOS的prop我们会发现这两项以hw_sc开头的prop。

前者开发过ets或者ark-ui的大概就很熟悉,它是鸿蒙的api版本,根据我个人的ets开发经历,在api4以上就是HarmonyOS了,而api8以上则是最新的HarmonyOS 3.0

那么剩下的就很简单了,编写一个platform()方法,该方法返回一个Platformenum

pub fn platform() -> Platform {
    if cfg!(windows) {
        Platform::Windows
    } else if cfg!(target_os = "android") {
        let output = Command::new("getprop")
            .arg("hw_sc.build.os.apiversion")
            .output()
            .expect("获取prop失败");
        let android_text = String::from_utf8(output.stdout).expect("u8字符转换为string出现错误");
        let use_text = android_text.trim();
        if use_text.is_empty() {
            return Platform::Android;
        }
        let android_number = use_text.parse::<i32>().expect("字符串转换为整形出现错误");
        if android_number >= 4 && android_number < 8{
            return Platform::HarmonyOSVersion2;
        }else if android_number >= 8 {
            return Platform::HarmonyOSVersion3;
        } else {
            return Platform::Android;
        }
    } else if cfg!(target_os = "ios") {
        Platform::Ios
    } else if cfg!(all(target_os = "macos", target_arch = "aarch64")) {
        Platform::MacApple
    } else if cfg!(target_os = "macos") {
        Platform::MacIntel
    } else if cfg!(target_family = "wasm") {
        Platform::Wasm
    } else if cfg!(unix) {
        Platform::Unix
    } else {
        Platform::Unknown
    }
}

这样我们就成功的实现了编写一个我们自己的platform,事不宜迟,我们赶紧测试一下吧,这里我找了两个拥有HarmonyOS设备的朋友。一个是HarmonyOS 3.0一个是HarmonyOS 2.0

我们编写个简单的text()输出的页面,打印的结果如下:

而使用HarmonyOS 2.0的设备朋友忘了截图设备信息了,直接上输出页面的图:

最后,试试我的flyme会不会误识别:

看来没问题。那么这个自建的platform有什么用呢?

如果你需要针对HarmonyOS,或者某些特定的厂商ui平台调用其特有的api,或是处理特定平台的bug,那么它可能就会帮很大的忙。

关于platform的探索就到这了,明天还得继续忙活我的shine_image的逻辑呢,不过如果大家喜欢这样的间章的话,之后我也会时不时出一点间章的文章,毕竟我还是蛮喜欢折腾奇奇怪怪的东西。

我建立了一个flutter的初始项目体验小工程,把我文章写的一些东西展示在这边,并且用户可以看到它运作正常,我打算将它打包在apk,在下篇文章的时候,提供给有想要试玩的小伙伴,玩一玩。

作者:琼八万
链接:https://juejin.cn/post/7182638122901962811

最后

如果想要成为架构师或想突破20~30K薪资范畴,那就不要局限在编码,业务,要会选型、扩展,提升编程思维。此外,良好的职业规划也很重要,学习的习惯很重要,但是最重要的还是要能持之以恒,任何不能坚持落实的计划都是空谈。

如果你没有方向,这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》,帮大家将杂乱、零散、碎片化的知识进行体系化的整理,让大家系统而高效地掌握Android开发的各个知识点。

在这里插入图片描述
相对于我们平时看的碎片化内容,这份笔记的知识点更系统化,更容易理解和记忆,是严格按照知识体系编排的。

全套视频资料:

一、面试合集
在这里插入图片描述
二、源码解析合集

在这里插入图片描述
三、开源框架合集

在这里插入图片描述
欢迎大家一键三连支持,若需要文中资料,直接点击文末CSDN官方认证微信卡片免费领取↓↓↓

<think>好的,用户之前问过Mac是否能用于深度学习和大模型,现在他问的是GitHub上很多需要Windows和CUDA的代码能否在Mac上运行。首先,我需要确认用户的使用场景。可能他正在尝试复现或使用一些现有的项目,但发现很多代码依赖CUDA和Windows,而他现在用的是Mac,担心兼容性问题。 接下来,我需要分析问题。用户提到的代码通常依赖CUDA,而Mac使用的是Metal,生态不同。需要解释CUDA代码在Mac上的兼容性,可能的解决方案,比如转换框架、使用替代库或者云服务。还要提到工具链的差异,比如PyTorch的MPS后端,TensorFlow-Metal插件,或者苹果的MLX框架。 同时,用户可能对技术细节不太熟悉,需要避免使用过于专业的术语,用易懂的例子说明。比如,解释如何修改代码中的CUDA部分为MPS,或者使用Docker容器来模拟环境。还要考虑用户可能遇到的常见问题,比如环境配置、依赖安装,给出具体的步骤和建议。 另外,用户可能想知道是否需要换到Windows系统或者购买NVIDIA显卡,但Mac用户可能更倾向于继续使用现有设备,所以需要提供在Mac上可行的替代方案,以及何时需要考虑使用云GPU服务。比如,当项目严重依赖CUDA特定库时,本地转换困难,建议使用云服务。 还要注意用户可能的实际需求,比如开发、学习还是生产环境。如果是学习和中小型项目,Mac可能足够,但大规模训练可能需要云资源。需要强调虽然Mac可以处理很多任务,但生态差异需要一些调整,提供具体的代码示例和工具链配置方法会更有帮助。 最后,总结关键点,给出明确的建议步骤,帮助用户逐步解决问题,并鼓励尝试和提供进一步的问题。确保回答结构清晰,分点说明,便于用户理解和操作。</think>这是一个非常实际的开发兼容性问题。以下是针对CUDA/Windows代码在Mac上运行的详细技术方案和可行性分析: **一、CUDA代码兼容性处理** 1. **硬件指令差异** - CUDA基于NVIDIA GPU的SIMT架构 - Mac的Metal API采用TBDR渲染架构 - 直接二进制兼容性:❌ 不可行 2. **代码层转换方案** ```python # 原始CUDA代码 device = torch.device("cuda:0") # Mac适配方案 device = torch.device("mps") if torch.backends.mps.is_available() else torch.device("cpu") ``` 3. **生态替代工具链** - **Metal Performance Shaders (MPS)**:PyTorch 1.12+原生支持 - **TensorFlow-Metal**:通过`tensorflow-macos`和`tensorflow-metal`包实现加速 - **MLCompute**:苹果官方低级计算框架 **二、Windows环境依赖处理** 1. **跨平台开发方案** ```bash # 使用conda统一环境管理 conda create -n mac_env python=3.9 conda install numpy matplotlib pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cpu ``` 2. **常见兼容问题解决** - **动态链接库问题**:用`dylib`替代`.dll` - **路径格式转换**: ```python path = path.replace("C:\\Users", "/Users") # Windows路径转Unix格式 ``` - **系统API差异**:用`platform`模块处理 ```python import platform if platform.system() == 'Darwin': # Mac特定代码 ``` **三、典型场景应对策略** | 原项目依赖 | Mac解决方案 | 性能损失 | |-------------------|-----------------------------------|-------| | CUDA扩展(.cu文件) | 使用Metal Shading Language重写 | 15-30% | | DirectX相关组件 | 通过MoltenVK转译Vulkan API | ~20% | | Windows特定GUI | 改用PyQt5/Tkinter跨平台框架 | 无 | | MSVC编译的二进制文件 | 使用Xcode工具链重新编译 | 需源码 | **四、实战调试技巧** 1. **CUDA核函数移植**: ```metal // 原CUDA核函数 __global__ void add_kernel(float* a, float* b, float* c) { int i = blockIdx.x * blockDim.x + threadIdx.x; c[i] = a[i] + b[i]; } // Metal等效实现 kernel void add_kernel(device float* a [[buffer(0)]], device float* b [[buffer(1)]], device float* c [[buffer(2)]], uint id [[thread_position_in_grid]]) { c[id] = a[id] + b[id]; } ``` 2. **性能优化关键**: - 利用Metal的`MTLHeap`实现统一内存管理 - 设置合适的`threadsPerThreadgroup`(建议256-1024) - 使用`MPSCNN`加速卷积运算 **五、推荐开发工具链** 1. **跨平台框架**: - **PyTorch Lightning**:自动处理设备差异 - **JAX**:通过`jax-metal`后端支持Apple Silicon 2. **虚拟化方案**: ```bash # 使用UTM虚拟化运行Windows brew install --cask utm # 配置GPU直通(需macOS 13+) ``` 3. **云开发衔接**: ```python # 使用fabric库实现本地Mac与云GPU混合编程 from fabric import Connection conn = Connection("gpu-server.com") conn.run("nvidia-smi") # 远程执行CUDA命令 ``` **六、可行性评估矩阵** | 项目类型 | 移植难度 | 建议方案 | |-----------------|-------|--------------------------| | 纯Python实现 | ★☆☆ | 直接运行+修改设备指定代码 | | 含CUDA扩展 | ★★☆ | 使用Metal重写核心计算部分 | | 依赖Windows SDK | ★★★ | 虚拟机/容器化方案 | | 使用特殊硬件加速库 | ★★★★ | 考虑云GPU服务或更换开发环境 | **最新进展**:2023年Apple推出的MLX框架已实现: - 自动设备内存管理 - 动态图计算模式 - 与NumPy兼容的API设计 ```python import mlx.core as mx a = mx.array([1.0, 2.0, 3.0], dtype=mx.float32) b = mx.ones_like(a) c = a + b # 自动使用GPU加速 ``` 建议开发流程: 1. 使用`torch.backends.mps.is_available()`检测环境 2. 通过`os.uname().machine`判断芯片架构(arm64 vs x86) 3. 优先选择跨平台框架(PyTorch/JAX) 4. 复杂CUDA代码考虑使用Metal Performance Shaders重写 对于无法避免的Windows依赖,推荐使用: ```bash # 通过Docker实现跨平台兼容 docker run --platform linux/amd64 -it --gpus all nvidia/cuda:11.8.0-base ``` 最终建议:日常开发可坚持使用Mac,但需接受约20%的移植成本。对CUDA生态重度依赖时,建议配置云端GPU开发环境(如AWS G5实例)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值