我认为如果 Xamarin.Forms 团队在 Github 或 MS 文档中写下更多关于 Xamarin.Forms 架构、设计原则及其工作流程的文档，这对社区人是有帮助的。
从我的角度来看，我使用 Xamarin.Forms 来创建我的产品，当我遇到 bug 时我有两种选择，一种是将问题提交到 github 并等待有一天它会被修复，另一种是将问题提交到 github 和我自己修好了。
克隆源代码并调试后，很难理解这些功能是如何工作的。 例如https://github.com/xamarin/Xamarin.Forms/issues/8521
另一个例子是 Android 端的 Xamarin.Forms 页面导航功能。 很容易理解原生 Android 上活动之间的导航功能。 但是在 Xamarin.Forms 上，它似乎使用一个主要活动来处理所有页面（可能）（本机表单和本机视图除外）。

我认为这很棒。

将画廊和展示规格/问题等拆分为更小的项目，可以更轻松地进行工作和展示，这是开发周期中的一大优势。

要做的最有问题的事情之一是拥有几个不同的版本，其中修复了错误或引入了功能，然后继续改进。
拥有几个较小的实例对此有很大帮助。

我正在考虑的另一件事是使用代码空间，在未来的 github-codespaces 中，可以为问题附加点文件（包括正确的 xamarin 版本等），然后我们可以只使用代码空间或检出该版本。

最好的情况是，较小的控制库部分可以作为单独可用的项目提供，并且可以在代码空间中打开。 我可以从较小的控制应用程序和代码空间的组合中看到很多好处。

我想我想说的是：

• 多部分控制库
• 代码空间支持
• 有问题的点文件

编辑：添加了第三点。

我同意我有几个问题一次打开几个月。 我已经克隆了 XF，但只是迷失在其中。
因此，仅展示解决方案如何工作的视频文档会很棒。

.Netty 越多越好。

1. 从核心中删除魔法字符串和无类型绑定。 不要要求任何为 repo 做出贡献的人编写无类型绑定或非类型检查字符串。 这将大大减少错误，使修复错误变得更加容易，并使重构更容易，从而不会出现新的错误。
2. 不需要贡献者处理任何标记层。 一些开发人员会想要使用 XAML 或 CSS，但修复错误的贡献者不需要关心这些事情。 只有从事标记语言工作的人，应该是真正的 .Net 类之上的一层，才需要关心这一层。
3. 渲染器方法应该以这样一种方式构建，即未能实现属性更改（或执行上述操作时的类型错误）是类型错误。
4. 在适当的情况下，对于实现某些完全没有特定于平台的绑定的功能，应该有一个容忍度，例如使用 SkiaSharp 或 Shapes 或复合 MAUI 对象，以获得显示相同且不引入新错误的可靠跨平台实现。

有一次，我们正在测试一个方向，让简化的 SLN 用户可以像这样做出贡献

https://github.com/PureWeen/Xamarin.Forms.Sandbox

只需提供一个非常有针对性的“Contributor.sln”，贡献者可以在其中演示修复程序或 API

删除所有当前画廊，并将其重点放在平台和 MainPage 上

解决方案过滤器会更好吗？ 您不必维护两个解决方案。

我们将看到使用解决方案过滤器开发的所有内容

AFAIK 目前它们在 vsmac 上不起作用，当你有多个目标项目时它们有点奇怪。 一旦我们可以为多目标提供一流的支持，并且头部项目可以只是 sdk 样式，那么我认为对解决方案过滤器的需求就没有那么高了。

另一个烦人的事情是，当您有多个目标时，VS for Windows 当前会构建所有目标，而 vsmac 只是为您正在运行的平台头构建一个。

另一个烦人的事情是，当您有多个目标时，VS for Windows 当前会构建所有目标，而 vsmac 只是为您正在运行的平台头构建一个。

在 VS for Windows 中获得对此的支持会很棒！ 我可以摆脱所有这些额外的配置，我只构建我目前正在使用的平台。

同意当前 VS for mac 上的多目标故事令人非常沮丧。 不幸的是，多目标是一个很好的选择，我仍然选择它作为我的方法，并且只是为团队中遇到问题的其他人提供技术支持。 它是一种永无止境的挫败感。