澳门新葡亰平台官网微软发力苹果iOS应用转制Win10 UWP:将全面支持UIKit – Project Islandwood,iOS应用,Win10应用,UWP – IT之家

by admin on 2020年4月28日

上个月,微软更新其Windows Bridge
iOS版,它是一个开源工具来帮助开发者将iOS应用移植到Windows
平台。
更新版本添加了诸多新功能,并且集成了CoreFoundation。现在,该公司已概述了它希望如何改善这个开发工具。

IT之家讯微软推出的苹果iOS应用转制Win10UWP的项目名为Islandwood,目的是能够快速方便的把iOS平台优秀应用移植到Windows10平台,以便丰富Win10应用生态。不过该项目此前在技术上还是存在一定困难的,比如很多开发者都发现迁移到XAML比较费劲。

(原文翻译过来的,原文链接

微软表示,开发者一直要求微软对UIKit的执行可以完整覆
盖API。但是,完全修改UIKit非常困难并且不可行,特别是考虑到Windows已经通过XAML提供相同的功能。但是,微软意识到这个问题,并已决
定制定一个明确的方法,将基于UIKit的UI移植到XAML,这个项目代号Islandwood,它包含以下改进:

现在微软宣布要在该项目上继续发力,公布了多项改进和提升,其中就包括多个新的UIKit支持API,这有助于解决XAML的困难。微软已经提供了一大部分UIKit,将来还会对其全面支持。此外,更新后的Islandwood还将包括改进的触摸输入模式,以便对事件有更高的掌控能力。

这里我带大家深入了解一下Windows bridge for
iOS(以前叫Project
Islandwood)是什么、它如何使iOS开发者在Windows下使用他们现成的代码和功能以及我们决定将这个项目做成开源的原因。

更快速的调出iOS控制,所以可以提供更多的UIKit

总的来说,新版iOS转制项目会有更高的可靠性和本地化改进,各项测试更为自动化,对XAML的整合度也更高,并且会全面支持UIKit。相关开发者可以点此进入微软官网阅读详细改进内容,并依照这些内容来对自己的开发做出下一步规划。

正如Kevin
Gallo所说,我们目前只是发布了一个简单版本,最后版本将会在今年秋天发布。这个开发工作还在进行中,我们在4月份的Build大会上展示的一些元素还没有准备好或者说还在初始阶段。目前的发布版本支持在x86和x64的Windows10和Windows8.1,到秋天的时候我们会将更多的功能发布出来。

改进触摸输入模型,提供更好的性能事件处理

对于那些刚刚加入我们的朋友来说,Windows bridge for
iOS目的是让iOS开发者能够使用现成的OC代码和功能来创建Windows应用。为了实现这个目的,bridge包括4个部分:

可访问性和本地化大大改善

  1. Objective-C编译器:为了承载更多的功能,VS将包括一个懂得如何将OC代码编译成UWP应用的编译器。当前我们在GitHub上提供了这个编译器的早期版本,但是并不提供开源代码。这个编译器最终会在今年秋天更新到VS2015上面。

  2. Objective-C runtime: 除了编译器,我们的OC
    runtime将给开发者提供一些语言特性,比如消息派发、代理授权以及自动引用计数。

  3. iOS API头文件/库:依赖于OC API,我们提供大量的iOS
    API的兼容性。当你开始使用bridge并且发现某个API还不支持或者有提升空间的可能,我们欢迎你的贡献和评论

  4. VS
    IDE集成:
    最后,我们提供工具,让开发者将他们的Xcode项目导入Windows开发者工具(VS2015)和SDK中。

更好的测试自动化,从而导致更稳定和高质量控制

在build大会上,我们操作了一下bridge,让开发者第一次见到bridge的神奇之处。现在,我很愿意向大家展示一下目前GitHub中发布的版本中拥有的新的特征。

提高集成度并利用Windows的用户界面框架

 


外,微软还指出,其实施的UIKit存在一些缺席,导致基本用例和场景不完整的支持。微软已经努力通过彻底的注释iOS桥代码库缓解这个问题。微软表示,
它的Islandwood项目将尽可能保留
UIKit功能,同时引入Windows诸多相同的功能。这种方法提供了许多优点。首先,它大大降低了工作量,它也极大地提高了桥梁在可访问性和本地化方
面的性能。另外,这种方法使微软能够测试自动化设计的XAML,这将有助于提高UI框架的质量。

为什么这个bridge不是一个端口?

稿源:生物360

我们的目标不是简单的让iOS应用运行在Windows平台上。相反,我们的目标是帮助开发者尽可能使用他们现成的代码和知识来创建好的Windows应用。我们当然会继续努力提升iOS的兼容性,但是更重要的是你可以利用bridge做更多的事情。

为了实现这个目的,有三个准则来决定这个bridge的结构和设计:

  1. 所有Windows API的接入:使得在OC代码中使用Windows API更容易

  2. iOS兼容性:驱动开发者尽可能重复利用现成的iOS代码

  3. 没有沙箱:iOS和Windows API在一起工作

我们第一个准则尤其重要,这是因为Windows有很丰富的功能API集合,而且集合持续扩大和完善。如果当前发布的版本不支持你需要的特定的功能,我们不会让你在下次更新时感觉受阻,相反地,我们更愿意让你轻松地使用相应的Windows API并无缝集成到你的代码中。

第三个和第一个准则是相互的——如果API集合各自处于沙箱中,调用所有Windows API的能力会受到严重影响,这也会严重限制开发者使用OC创建好的Windows应用。让我们一起来近距离看看我们如何保证这些没有问题,无论是在代码级别还是UI级别。

 

当Windows和OC API相遇

正如Build大会上介绍的那样,这个bridge使用了一个定制的编译器(clang+cl)来编译OC源代码,生成的目标文件通过微软的链接器链接到一起。这个方法可以很好的让OC以及C++/CX更好的运行在一起。他们可以在一个项目中共存,并且使用C或者C++接口调用另外一种代码函数。

这个方法很有效,但是有点复杂。由于clang不能理解CX的扩展,而后者将被用来调用Windows API,那么为了你可以使用所有的UWP API集,你就需要创建.cpp文件,然后手动将OC和C++/CX连接起来。尽管这个可以很好的实现,但是我们相信我们可以做的更好,于是我们就想出了映射的概念。

对于那些不熟悉映射的开发者们来说,Miguel de
lcaza在他的博客里面详细讲述了相关内容。简而言之,映射就是微软将一个Windows API映射到一个新的编程语言。我们采纳这种方式,并且成功让开发者可以从OC中直接使用Windows的API。目前,bridge已经可以使用一些API,我们的目标是拓展到全部的API。

作为一个例子,我们来测试一下如何在应用中异步使用一个浏览器。使用该bridge,你可以使用两种方法实现它:

 

选项1 (在C++/CX代码中使用)

auto uri = ref new Windows::Foundation::Uri("http://www.example.com");
concurrency::task<bool> launchUriOperation(Windows::System::Launcher::LaunchUriAsync(uri));
launchUriOperation.then([](bool success)
{
      if (success)
      {
         // URI launched
      }
      else
      {
         // URI launch failed
      }
});

选项2 (在OC代码中使用同一个API)

[WSLauncher launchUriAsync:[WFUri createUri:@“http://www.example.com/”] success:nil failure:nil];

`(OC代码有可能提供处理异步调用成功或者失败的情况)“`

在这个例子中,我们不仅使用了多个类,比如
Windows::System(“Launcher”)和Windows::Foundation(“Uri”),而且我们传递了一个NSString类型的值,而映射系统神奇的将它当成HSTRING类型传递给下面的runtime。其他的如IVectors和IVectorViews会被分别当成NSMutableArrays和NSArrays,其他对于iterators,
enumerators, maps的相似匹配会陆续发布。无论在UWP或者OC内,对象的生存时间通过开发者早已习惯的同一个自动引用计数语义来管理。

还有很多内容等待发布,我再重申一遍,还有许多功能正在开发。同时,看看我们在GitHub上提供的一些例子,从实际和细节中了解更多关于bridge的内容。

 

XAML和UIKit:最后还是在一起了

既然你可以在OC中调用Windows API,我们不想限制你使用API集合。对于iOS/UIKit元素来说,整个应用都使用XAML进行排版,而不是分别使用排版器。几乎在iOS应用的每一个View中都使用的CALayers会被绑定到相应的XAML元素。

所以假如你的应用想要播放一些视频,但是目前iOS bridge不支持MPMoviePlayerController。利用这个机制,你可以创建一个XAML
MediaElement,打包进一个CALayer,然后打包这层进到一个视图中,并把这个视图放到你的其他UIView中。非常简单,而且你所有的动画和变化仍然可以对这个元素正常工作,就像对其他元素一样。

// WXCMediaElement is the Objective-C projection of

// Windows::UI::Xaml::MediaElement

WXCMediaElement *mediaElement = [WXCMediaElement create];

mediaElement.autoPlay = YES;

CALayer *mediaElementLayer = [CALayer layer];

[mediaElementLayer setFrame:CGRectMake(10, 10, 320, 240)];

[mediaElementLayer setContentsElement: mediaElement];

mediaElement.source = [WFUri createUri: @"ms-appx:///myvideo.mp4"];



// Now we just add the layer to be part of a UIView

 [[containingView layer] addSublayer: mediaElementLayer];

 我们长期的目标是在SDK中包含大多数常见类。我们欢迎开发者的贡献。同时,我们会让开发者更容易使用XAML控制,尤其在UIKit等效元素目前还不支持或者XAML控制在Windows环境下仍然显示比较“简单”的情况下。

 

展望

Bridge源代码已经放在了http://www.github.com/Microsoft/WinObjC/上。我们的旅程才刚刚开始。我们会和开发者一起提升iOS
bridge,帮助iOS开发者将他们的代码导入UWP上。目前,我们分享了SDK的预览版,该预览版适用于x86和x64架构的Windows
10 和Windows
8.1平台。在这个夏天,我们会添加编译优化和对ARM(也就是对手机)的支持。

我们欢迎所有的反馈、建议、问题以及评论。如果你也想为这个项目出力,我们邀请你提交你的代码到GitHub上。你也可以通过以下多种方式找到我们开发团队:

  • Tweet @WindowsDev 并用#winobjc标记你的问题

  • 在Stack Overflow上发布你的问题并打上winobjc标签

  • 在IRC上访问#winobjc频道

我们期待你的参与,同时我们非常期待看到开发者创建的好的应用。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图