图形学图像处理跨平台【免费下载链接】SkiaSharpSkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Googles Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.项目地址https://gitcode.com/gh_mirrors/sk/SkiaSharp点击查看免费下载SkiaSharp 1.68.1 是一个带有 ⚠️ breaking 标记的发布版本发布索引 将 SkiaSharp.breaking.md 单独拆出专门记录SkiaSharp.dll中会影响调用方的 API 差异。本篇基于该 API diff 文档逐项剖析 4 处破坏性变更——SKColorSpace.CreateRgb方法签名修改、SKObject.OwnsHandle属性移除、SKPath三个内部类型的基类切换以及SKTextBlobBuilder参数重命名——并结合仓库源码给出每处变更的成因、对源码级/二进制兼容性的具体影响与可落地的迁移方案帮助你在升级 NuGet 包时快速定位编译告警与运行时行为差异。变更总览与文档结构1.68.1 的 API 差异文档按惯例分为三层读者可按需查阅文件内容SkiaSharp.breaking.md仅列出破坏性变更Modified/Removed是升级时必须逐条对照的清单SkiaSharp.humanreadable.md人类可读格式的全量差异新增类型、新增方法等不含DisposeNative之类的样板噪音SkiaSharp.md机器生成的完整 API diff粒度最细发布索引 中SkiaSharp — ⚠️ breaking与SkiaSharp.Views.Desktop — ⚠️ breaking两个标记意味着这两个程序集在本次发布中都包含破坏性变更。本篇聚焦SkiaSharp.dll本体共 4 类变更、涉及 6 个方法签名修改、1 个属性移除和 3 个基类切换。SKColorSpace.CreateRgb默认参数与 Obsolete 重载并存diff 原文4 个重载的 flags 参数发生变化breaking 文档中SkiaSharp.SKColorSpace一节记录的是 4 个CreateRgb重载的 Modified methods--- 0---划线部分表示本次新增/变化的默认值public SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKColorSpaceGamut gamut, SKColorSpaceFlags flags--- 0---) public SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKMatrix44 toXyzD50, SKColorSpaceFlags flags--- 0---) public SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKColorSpaceGamut gamut, SKColorSpaceFlags flags--- 0---) public SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKMatrix44 toXyzD50, SKColorSpaceFlags flags--- 0---)这些重载是 1.68.0 引入的可对照 1.68.0 的 API diff 中首次出现SKTextBlobBuilder等新类型时的同一批颜色空间 API。1.68.1 中SKColorSpaceFlags flags参数被赋予了默认值 0调用方可省略该参数。更关键的事实带 flags 的重载同时被标记 Obsolete仅看 breaking 文档会低估这次变更在 完整 diff 中这 4 个带flags参数的重载被标记了[Obsolete]并给出了迁移指引[Obsolete (Use CreateRgb (SKColorSpaceRenderTargetGamma, SKColorSpaceGamut) instead.)] public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKColorSpaceGamut gamut, SKColorSpaceFlags flags); [Obsolete (Use CreateRgb (SKColorSpaceRenderTargetGamma, SKMatrix44) instead.)] public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKMatrix44 toXyzD50, SKColorSpaceFlags flags); // 同理两个 SKColorSpaceTransferFn 版本也分别指向无 flags 的重载同时 1.68.1 新增了一批不带flags参数的重载以及支持SKNamedGamma的重载public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKColorSpaceGamut gamut); public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKMatrix44 toXyzD50); public static SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKColorSpaceGamut gamut); public static SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKMatrix44 toXyzD50); public static SKColorSpace CreateRgb (SKNamedGamma gamma, SKColorSpaceGamut gamut); public static SKColorSpace CreateRgb (SKNamedGamma gamma, SKMatrix44 toXyzD50);对调用方的实际影响与迁移默认位置参数调用如CreateRgb(gamma, gamut, SKColorSpaceFlags.V2)仍可编译但会产生CS0618过时告警若项目启用了TreatWarningsAsErrors则直接变成编译错误——这是“源码层面被 breaking 标记”的主要原因。反射/动态调用按精确签名查找CreateRgb的代码参数默认值变化会体现在方法签名比较中需要复核。迁移方式按[Obsolete]消息把三参调用改写成两参调用flags缺省即为 0语义等价于不设置任何SKColorSpaceFlags位需要指定具名 gamma 的可改用新增的SKNamedGamma重载。从当前主干源码结构看这一方向已被进一步坐实SKColorSpace.cs 中CreateRgb如今只保留CreateRgb (SKColorSpaceTransferFn transferFn, SKColorSpaceXyz toXyzD50)形式且GetNumericalTransferFunction等配套 API 也随 1.68.1 的 diff 一并落地见 SKColorSpace.cs#L204-L223。也就是说1.68.1 的这次 API 整形是后续持续演进的起点升级时以 1.68.1 的 diff 文档为准即可。SKObject.OwnsHandle 移除所有权语义下沉到 SKNativeObjectdiff 原文// Type Changed: SkiaSharp.SKObject —— Removed property: protected bool OwnsHandle { get; }这是本次 4 处变更中对派生类作者影响最大的一处。1.68.0 及以前OwnsHandle表示该托管包装对象是否拥有底层原生句柄、Dispose 时是否释放原生对象定义在SKObject上且只读1.68.1 把它整体下移到基类SKNativeObject并升级为可设置的 virtual 属性。完整 diff 中SKNativeObject一节的 Added properties 与之对应protected bool IgnorePublicDispose { get; set; } protected bool IsDisposed { get; } protected virtual bool OwnsHandle { get; set; }源码印证所有权标志的完整生命周期当前主干的 SKObject.cs 完整保留了这一设计可以逐行印证 1.68.1 的意图属性定义可写、virtualSKObject.cs#L279protected internal virtual bool OwnsHandle { get; protected set; }构造器 L252-L256 直接以ownsHandle初始化。处置决策依赖它Dispose(bool)中if (Handle ! IntPtr.Zero OwnsHandle) DisposeNative();L365-L366即不拥有句柄的包装对象 Dispose 时不会销毁原生对象这正是 SkiaSharp “非拥有包装”从原生返回值中获得的对象由全局字典统一管理内存模型的核心。所有权转移SKObject.RevokeOwnership会在所有权移交新主对象时执行OwnsHandle false;SKObject.cs#L210-L230。若OwnsHandle仍是 1.68.0 时代的只读属性这一“移交所有权、阻止误释放”的机制就无法实现——这就是本次把它改成可写 virtual 的根本原因。配套新增的DisposeInternal绕过IgnorePublicDispose强制处置L433-L442与IgnorePublicDisposeL290、IsDisposedL327一起构成了 1.68.1 diff 中SKNativeObject的全部 Added members。对调用方的影响与迁移只读访问obj.OwnsHandle的下游代码属性随基类继承仍然可见普通访问不受影响。在派生类中自行声明OwnsHandle属性/字段的代码原来隐藏hide的是SKObject的非虚成员现在与SKNativeObject的 virtual 成员冲突会触发CS0108隐藏警告甚至编译错误需要用new显式隐藏或改为重写virtual成员。行为变化由于变成可写 virtual原生对象生命周期管理不再完全静态确定——RevokeOwnership这类内部路径可以在运行期改写所有权。从源码结构看这对使用SKAbstractManagedStream代理回调的对象尤为关键代码注释明确指出“不能直接 Dispose因为原生对象可能通过代理回调托管包装”。SKPath.Iterator / RawIterator / OpBuilder基类由 SKNativeObject 切换为 SKObjectdiff 原文breaking 文档为 3 个SKPath嵌套类型记录了相同的基类变更// Type Changed: SkiaSharp.SKPath.Iterator -SkiaSharp.SKNativeObject SkiaSharp.SKObjectSKPath.RawIterator与SKPath.OpBuilder的 diff 与此完全一致。当前主干 SKPath.cs 中可以看到这些类型的最新形态IteratorL1342、RawIteratorL1430、OpBuilderL1496均声明为: SKObject, ISKSkipObjectRegistration。为什么基类切换算破坏性变更从源码结构看这两个基类承担的职责不同SKNativeObjectSKObject.cs#L235是“纯句柄包装”Handle Dispose 模式 OwnsHandle不参与任何全局追踪。SKObjectSKObject.cs#L12在其上叠加了句柄注册与所有权树Handle的 setter 会RegisterHandle/DeregisterHandle到全局HandleDictionaryL55-L66并维护OwnedObjects/KeepAliveObjects两个字典实现父子生命周期绑定DisposeManaged见 L82-L92。因此基类切换带来两层影响二进制兼容层面类型的方法表vtable布局与基类地址发生变化按旧元数据编译的程序集在虚方法分派、类型校验上可能失败。对SKPath.Iterator这类内部构建类型第三方一般不直接继承主要受影响的是“编译期绑定了该类型虚方法”的旧版本程序集——典型症状是运行时MissingMethodException/InvalidCastException重新编译即可消除。行为层面这些迭代器/操作构建器现在由SKObject的DisposeNative统一处理引用计数ISKReferenceCounted.SafeUnRefL96-L100释放时机与HandleDictionary的注册表保持一致避免“包装器被 GC 前原生迭代器已释放”的悬挂句柄问题。对应用作者的直接建议不要针对SKPath.Iterator等类型写基类假设例如假定其为SKNativeObject而非SKObject升级后重新编译即可源码级 API 用法不变。SKTextBlobBuilder参数名 utf8Text 改为 textdiff 原文SkiaSharp.SKTextBlobBuilder的 6 个文本附加方法参数名被统一重命名utf8Text→text方法体与语义不变-public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] utf8Text, uint[] clusters) public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] text, uint[] clusters) -public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] utf8Text, uint[] clusters, SKRect bounds) public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] text, uint[] clusters, SKRect bounds) -public void AddPositionedRun (SKPaint font, ushort[] glyphs, SKPoint[] positions, byte[] utf8Text, uint[] clusters) public void AddPositionedRun (SKPaint font, ushort[] glyphs, SKPoint[] positions, byte[] text, uint[] clusters) // AddPositionedRun(..., SKRect bounds)、AddRun、AddRun(..., SKRect bounds) 的重命名与此完全相同1.68.0 时这些方法确实以byte[] utf8Text命名可对照 1.68.0 的 API diff 中New Type: SkiaSharp.SKTextBlobBuilder一节参数名均为utf8Text。影响面判定与迁移C# 中参数重命名不影响按位置传参的调用只影响命名参数调用与反射按名取参的代码。因此实际修复范围很小// 升级前1.68.0命名参数 builder.AddRun (font, x, y, glyphs, utf8Text: textBytes, clusters: clusters); // 升级后1.68.1 builder.AddRun (font, x, y, glyphs, text: textBytes, clusters: clusters);若编译报CS1739: no argument given for parameter text或命名参数不匹配的告警全局替换utf8Text:为text:即可。值得注意的是该参数传入的字节序列本就允许任意SKEncoding编码信息随font携带从utf8Text改名为更中性的text正是为了消除“必须 UTF-8”的误导。从当前主干看SKTextBlobBuilder 已进一步演进例如AddRun系列改为SKFont字体参数并全面转向ReadOnlySpan输入说明 1.68.1 之后的版本对这一区域的 API 还在持续重构跨大版本升级时建议以对应 release 的 diff 文档为准。升级操作清单对照 breaking 文档升级前逐条读取 SkiaSharp.breaking.md本次仅 4 类变更其中SKObject.OwnsHandle移除与SKPath基类切换只影响派生类/旧二进制参数重命名只影响命名参数调用。处理 Obsolete 告警CreateRgb的 4 个带flags重载按[Obsolete]消息改写为两参重载或SKNamedGamma重载消除CS0618避免TreatWarningsAsErrors下构建失败。检查派生类搜索继承SKObject/SKNativeObject的自定义类型确认没有自定义OwnsHandle并理解所有权现在可能运行期改变RevokeOwnership语义。重新编译而非热替换SKPath.Iterator等基类切换属于二进制破坏跨版本引用SkiaSharp.dll的下游程序集必须重编译。全量核对如需确认没有遗漏的非破坏性新增如SKDrawable、SKRunBuffer等 New Type查阅 SkiaSharp.humanreadable.md机器级完整清单在 SkiaSharp.md。结语SkiaSharp 1.68.1 的 4 处破坏性变更各有明确动机CreateRgb的默认值与 Obsolete 整形为颜色空间 API 引入SKNamedGamma铺路OwnsHandle下沉并改为可写支撑起所有权转移与公共 Dispose 保护IgnorePublicDispose/DisposeInternal这一套更精细的托管-原生生命周期机制SKPath内部类型并入SKObject以纳入句柄注册表统一治理utf8Text改名则是消除语义误导的规范化。只要按本篇清单对照 1.68.1 发布索引 逐一处理升级路径是平滑且可预测的。赞分享图形学图像处理跨平台【免费下载链接】SkiaSharpSkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Googles Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.项目地址https://gitcode.com/gh_mirrors/sk/SkiaSharp点击查看免费下载相关推荐SkiaSharp 1.56.2 破坏性 API 变更详解SKColorTable、SKBitmap 与 SKPath 的迁移指南SkiaSharp 1.56.2 破坏性 API 变更详解SKColorTable、SKBitmap 与 SKPath 的迁移指南 本文以仓库中 SkiaSh图形学图像处理跨平台SkiaSharp 1.55.0 破坏性变更详解API Diff 与升级迁移指南SkiaSharp 1.55.0 破坏性变更详解API Diff 与升级迁移指南 本文基于 SkiaSharp 官方发布说明中的 1.55.0 SkiaSha图形学图像处理跨平台SkiaSharp 1.68.0 API 变更详解GPU 表面迁移指南与全量破坏性变更清单SkiaSharp 1.68.0 API 变更详解GPU 表面迁移指南与全量破坏性变更清单 SkiaSharp 1.68.0 开启了 1.68 版本线本版的图形学图像处理跨平台创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
图形学图像处理跨平台【免费下载链接】SkiaSharpSkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Googles Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.项目地址https://gitcode.com/gh_mirrors/sk/SkiaSharp点击查看免费下载SkiaSharp 1.68.1 是一个带有 ⚠️ breaking 标记的发布版本发布索引 将 SkiaSharp.breaking.md 单独拆出专门记录SkiaSharp.dll中会影响调用方的 API 差异。本篇基于该 API diff 文档逐项剖析 4 处破坏性变更——SKColorSpace.CreateRgb方法签名修改、SKObject.OwnsHandle属性移除、SKPath三个内部类型的基类切换以及SKTextBlobBuilder参数重命名——并结合仓库源码给出每处变更的成因、对源码级/二进制兼容性的具体影响与可落地的迁移方案帮助你在升级 NuGet 包时快速定位编译告警与运行时行为差异。变更总览与文档结构1.68.1 的 API 差异文档按惯例分为三层读者可按需查阅文件内容SkiaSharp.breaking.md仅列出破坏性变更Modified/Removed是升级时必须逐条对照的清单SkiaSharp.humanreadable.md人类可读格式的全量差异新增类型、新增方法等不含DisposeNative之类的样板噪音SkiaSharp.md机器生成的完整 API diff粒度最细发布索引 中SkiaSharp — ⚠️ breaking与SkiaSharp.Views.Desktop — ⚠️ breaking两个标记意味着这两个程序集在本次发布中都包含破坏性变更。本篇聚焦SkiaSharp.dll本体共 4 类变更、涉及 6 个方法签名修改、1 个属性移除和 3 个基类切换。SKColorSpace.CreateRgb默认参数与 Obsolete 重载并存diff 原文4 个重载的 flags 参数发生变化breaking 文档中SkiaSharp.SKColorSpace一节记录的是 4 个CreateRgb重载的 Modified methods--- 0---划线部分表示本次新增/变化的默认值public SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKColorSpaceGamut gamut, SKColorSpaceFlags flags--- 0---) public SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKMatrix44 toXyzD50, SKColorSpaceFlags flags--- 0---) public SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKColorSpaceGamut gamut, SKColorSpaceFlags flags--- 0---) public SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKMatrix44 toXyzD50, SKColorSpaceFlags flags--- 0---)这些重载是 1.68.0 引入的可对照 1.68.0 的 API diff 中首次出现SKTextBlobBuilder等新类型时的同一批颜色空间 API。1.68.1 中SKColorSpaceFlags flags参数被赋予了默认值 0调用方可省略该参数。更关键的事实带 flags 的重载同时被标记 Obsolete仅看 breaking 文档会低估这次变更在 完整 diff 中这 4 个带flags参数的重载被标记了[Obsolete]并给出了迁移指引[Obsolete (Use CreateRgb (SKColorSpaceRenderTargetGamma, SKColorSpaceGamut) instead.)] public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKColorSpaceGamut gamut, SKColorSpaceFlags flags); [Obsolete (Use CreateRgb (SKColorSpaceRenderTargetGamma, SKMatrix44) instead.)] public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKMatrix44 toXyzD50, SKColorSpaceFlags flags); // 同理两个 SKColorSpaceTransferFn 版本也分别指向无 flags 的重载同时 1.68.1 新增了一批不带flags参数的重载以及支持SKNamedGamma的重载public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKColorSpaceGamut gamut); public static SKColorSpace CreateRgb (SKColorSpaceRenderTargetGamma gamma, SKMatrix44 toXyzD50); public static SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKColorSpaceGamut gamut); public static SKColorSpace CreateRgb (SKColorSpaceTransferFn coeffs, SKMatrix44 toXyzD50); public static SKColorSpace CreateRgb (SKNamedGamma gamma, SKColorSpaceGamut gamut); public static SKColorSpace CreateRgb (SKNamedGamma gamma, SKMatrix44 toXyzD50);对调用方的实际影响与迁移默认位置参数调用如CreateRgb(gamma, gamut, SKColorSpaceFlags.V2)仍可编译但会产生CS0618过时告警若项目启用了TreatWarningsAsErrors则直接变成编译错误——这是“源码层面被 breaking 标记”的主要原因。反射/动态调用按精确签名查找CreateRgb的代码参数默认值变化会体现在方法签名比较中需要复核。迁移方式按[Obsolete]消息把三参调用改写成两参调用flags缺省即为 0语义等价于不设置任何SKColorSpaceFlags位需要指定具名 gamma 的可改用新增的SKNamedGamma重载。从当前主干源码结构看这一方向已被进一步坐实SKColorSpace.cs 中CreateRgb如今只保留CreateRgb (SKColorSpaceTransferFn transferFn, SKColorSpaceXyz toXyzD50)形式且GetNumericalTransferFunction等配套 API 也随 1.68.1 的 diff 一并落地见 SKColorSpace.cs#L204-L223。也就是说1.68.1 的这次 API 整形是后续持续演进的起点升级时以 1.68.1 的 diff 文档为准即可。SKObject.OwnsHandle 移除所有权语义下沉到 SKNativeObjectdiff 原文// Type Changed: SkiaSharp.SKObject —— Removed property: protected bool OwnsHandle { get; }这是本次 4 处变更中对派生类作者影响最大的一处。1.68.0 及以前OwnsHandle表示该托管包装对象是否拥有底层原生句柄、Dispose 时是否释放原生对象定义在SKObject上且只读1.68.1 把它整体下移到基类SKNativeObject并升级为可设置的 virtual 属性。完整 diff 中SKNativeObject一节的 Added properties 与之对应protected bool IgnorePublicDispose { get; set; } protected bool IsDisposed { get; } protected virtual bool OwnsHandle { get; set; }源码印证所有权标志的完整生命周期当前主干的 SKObject.cs 完整保留了这一设计可以逐行印证 1.68.1 的意图属性定义可写、virtualSKObject.cs#L279protected internal virtual bool OwnsHandle { get; protected set; }构造器 L252-L256 直接以ownsHandle初始化。处置决策依赖它Dispose(bool)中if (Handle ! IntPtr.Zero OwnsHandle) DisposeNative();L365-L366即不拥有句柄的包装对象 Dispose 时不会销毁原生对象这正是 SkiaSharp “非拥有包装”从原生返回值中获得的对象由全局字典统一管理内存模型的核心。所有权转移SKObject.RevokeOwnership会在所有权移交新主对象时执行OwnsHandle false;SKObject.cs#L210-L230。若OwnsHandle仍是 1.68.0 时代的只读属性这一“移交所有权、阻止误释放”的机制就无法实现——这就是本次把它改成可写 virtual 的根本原因。配套新增的DisposeInternal绕过IgnorePublicDispose强制处置L433-L442与IgnorePublicDisposeL290、IsDisposedL327一起构成了 1.68.1 diff 中SKNativeObject的全部 Added members。对调用方的影响与迁移只读访问obj.OwnsHandle的下游代码属性随基类继承仍然可见普通访问不受影响。在派生类中自行声明OwnsHandle属性/字段的代码原来隐藏hide的是SKObject的非虚成员现在与SKNativeObject的 virtual 成员冲突会触发CS0108隐藏警告甚至编译错误需要用new显式隐藏或改为重写virtual成员。行为变化由于变成可写 virtual原生对象生命周期管理不再完全静态确定——RevokeOwnership这类内部路径可以在运行期改写所有权。从源码结构看这对使用SKAbstractManagedStream代理回调的对象尤为关键代码注释明确指出“不能直接 Dispose因为原生对象可能通过代理回调托管包装”。SKPath.Iterator / RawIterator / OpBuilder基类由 SKNativeObject 切换为 SKObjectdiff 原文breaking 文档为 3 个SKPath嵌套类型记录了相同的基类变更// Type Changed: SkiaSharp.SKPath.Iterator -SkiaSharp.SKNativeObject SkiaSharp.SKObjectSKPath.RawIterator与SKPath.OpBuilder的 diff 与此完全一致。当前主干 SKPath.cs 中可以看到这些类型的最新形态IteratorL1342、RawIteratorL1430、OpBuilderL1496均声明为: SKObject, ISKSkipObjectRegistration。为什么基类切换算破坏性变更从源码结构看这两个基类承担的职责不同SKNativeObjectSKObject.cs#L235是“纯句柄包装”Handle Dispose 模式 OwnsHandle不参与任何全局追踪。SKObjectSKObject.cs#L12在其上叠加了句柄注册与所有权树Handle的 setter 会RegisterHandle/DeregisterHandle到全局HandleDictionaryL55-L66并维护OwnedObjects/KeepAliveObjects两个字典实现父子生命周期绑定DisposeManaged见 L82-L92。因此基类切换带来两层影响二进制兼容层面类型的方法表vtable布局与基类地址发生变化按旧元数据编译的程序集在虚方法分派、类型校验上可能失败。对SKPath.Iterator这类内部构建类型第三方一般不直接继承主要受影响的是“编译期绑定了该类型虚方法”的旧版本程序集——典型症状是运行时MissingMethodException/InvalidCastException重新编译即可消除。行为层面这些迭代器/操作构建器现在由SKObject的DisposeNative统一处理引用计数ISKReferenceCounted.SafeUnRefL96-L100释放时机与HandleDictionary的注册表保持一致避免“包装器被 GC 前原生迭代器已释放”的悬挂句柄问题。对应用作者的直接建议不要针对SKPath.Iterator等类型写基类假设例如假定其为SKNativeObject而非SKObject升级后重新编译即可源码级 API 用法不变。SKTextBlobBuilder参数名 utf8Text 改为 textdiff 原文SkiaSharp.SKTextBlobBuilder的 6 个文本附加方法参数名被统一重命名utf8Text→text方法体与语义不变-public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] utf8Text, uint[] clusters) public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] text, uint[] clusters) -public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] utf8Text, uint[] clusters, SKRect bounds) public void AddHorizontalRun (SKPaint font, float y, ushort[] glyphs, float[] positions, byte[] text, uint[] clusters, SKRect bounds) -public void AddPositionedRun (SKPaint font, ushort[] glyphs, SKPoint[] positions, byte[] utf8Text, uint[] clusters) public void AddPositionedRun (SKPaint font, ushort[] glyphs, SKPoint[] positions, byte[] text, uint[] clusters) // AddPositionedRun(..., SKRect bounds)、AddRun、AddRun(..., SKRect bounds) 的重命名与此完全相同1.68.0 时这些方法确实以byte[] utf8Text命名可对照 1.68.0 的 API diff 中New Type: SkiaSharp.SKTextBlobBuilder一节参数名均为utf8Text。影响面判定与迁移C# 中参数重命名不影响按位置传参的调用只影响命名参数调用与反射按名取参的代码。因此实际修复范围很小// 升级前1.68.0命名参数 builder.AddRun (font, x, y, glyphs, utf8Text: textBytes, clusters: clusters); // 升级后1.68.1 builder.AddRun (font, x, y, glyphs, text: textBytes, clusters: clusters);若编译报CS1739: no argument given for parameter text或命名参数不匹配的告警全局替换utf8Text:为text:即可。值得注意的是该参数传入的字节序列本就允许任意SKEncoding编码信息随font携带从utf8Text改名为更中性的text正是为了消除“必须 UTF-8”的误导。从当前主干看SKTextBlobBuilder 已进一步演进例如AddRun系列改为SKFont字体参数并全面转向ReadOnlySpan输入说明 1.68.1 之后的版本对这一区域的 API 还在持续重构跨大版本升级时建议以对应 release 的 diff 文档为准。升级操作清单对照 breaking 文档升级前逐条读取 SkiaSharp.breaking.md本次仅 4 类变更其中SKObject.OwnsHandle移除与SKPath基类切换只影响派生类/旧二进制参数重命名只影响命名参数调用。处理 Obsolete 告警CreateRgb的 4 个带flags重载按[Obsolete]消息改写为两参重载或SKNamedGamma重载消除CS0618避免TreatWarningsAsErrors下构建失败。检查派生类搜索继承SKObject/SKNativeObject的自定义类型确认没有自定义OwnsHandle并理解所有权现在可能运行期改变RevokeOwnership语义。重新编译而非热替换SKPath.Iterator等基类切换属于二进制破坏跨版本引用SkiaSharp.dll的下游程序集必须重编译。全量核对如需确认没有遗漏的非破坏性新增如SKDrawable、SKRunBuffer等 New Type查阅 SkiaSharp.humanreadable.md机器级完整清单在 SkiaSharp.md。结语SkiaSharp 1.68.1 的 4 处破坏性变更各有明确动机CreateRgb的默认值与 Obsolete 整形为颜色空间 API 引入SKNamedGamma铺路OwnsHandle下沉并改为可写支撑起所有权转移与公共 Dispose 保护IgnorePublicDispose/DisposeInternal这一套更精细的托管-原生生命周期机制SKPath内部类型并入SKObject以纳入句柄注册表统一治理utf8Text改名则是消除语义误导的规范化。只要按本篇清单对照 1.68.1 发布索引 逐一处理升级路径是平滑且可预测的。赞分享图形学图像处理跨平台【免费下载链接】SkiaSharpSkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Googles Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.项目地址https://gitcode.com/gh_mirrors/sk/SkiaSharp点击查看免费下载相关推荐SkiaSharp 1.56.2 破坏性 API 变更详解SKColorTable、SKBitmap 与 SKPath 的迁移指南SkiaSharp 1.56.2 破坏性 API 变更详解SKColorTable、SKBitmap 与 SKPath 的迁移指南 本文以仓库中 SkiaSh图形学图像处理跨平台SkiaSharp 1.55.0 破坏性变更详解API Diff 与升级迁移指南SkiaSharp 1.55.0 破坏性变更详解API Diff 与升级迁移指南 本文基于 SkiaSharp 官方发布说明中的 1.55.0 SkiaSha图形学图像处理跨平台SkiaSharp 1.68.0 API 变更详解GPU 表面迁移指南与全量破坏性变更清单SkiaSharp 1.68.0 API 变更详解GPU 表面迁移指南与全量破坏性变更清单 SkiaSharp 1.68.0 开启了 1.68 版本线本版的图形学图像处理跨平台创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
