Tag: 移动应用程序开发

使用Swift自定义iOS中的导航栏

更改导航栏颜色 为了更改所有视图控制器的导航栏颜色,必须在AppDelegate.swift文件中进行设置 将以下代码添加到didFinishLaunchingWithOptions函数中 var navigationBarAppearace = UINavigationBar.appearance() navigationBarAppearace.tintColor = uicolorFromHex(0xffffff) navigationBarAppearace.barTintColor = uicolorFromHex(0x034517) 在这里tintColor属性更改导航栏的背景颜色 barTintColor属性影响颜色 后指示器图像 按钮标题 按钮图片 此代码不会影响导航栏标题的颜色。 它仍然保持黑色 更改导航栏标题的颜色 将以下代码添加到didFinishLaunchingWithOptions函数中 var navigationBarAppearace = UINavigationBar.appearance() navigationBarAppearace.tintColor = uicolorFromHex(0xffffff) navigationBarAppearace.barTintColor = uicolorFromHex(0x034517) // change navigation item title color navigationBarAppearace.titleTextAttributes =[NSForegroundColorAttributeName:UIColor.whiteColor()] titleTextAttributes影响标题文本,在这里我将标题文本设置为白色 以编程方式更改导航栏标题 为了更改导航项的标题(在ViewController中),您必须在ViewController的viewDidLoad函数中设置标题 override func viewDidLoad() { super.viewDidLoad() self.navigationItem.title = “New title” } 以下是此更改后的示例输出 更改状态栏颜色 […]

苹果WatchKit ile ListeOluşturma

Merhaba。 苹果公司的“ Abi iyigüzeldeTürkçebir kaynak yok yaa”苹果手表公司的手表。 她的语言是“你好,世界”,它是世界级的。 Ancak bizbugünbuduvarlarıyıkıp,adete bir devrimyapıp-böylegereksiz bir heyecanla- iOS’danaşinaolduğumuzUITableViewörneğiyapacağız。 Ancak WatchuygulamasıgeliştirirkenUIKit yerine WatchKitkullanacağız👽。 Hemenbaşlayalım。 观看ProjesiOluşturma Bir Apple Watch手表,手表和手表 。 Bizim erimizdehalihazırdabir iOSuygulamasıolduğuvarsayılacak。 Bizimistediğimiziseuygulamamızın观看versiyonunu yapmak。 Adım1: UygulamamızseçiliykenResim 1.0 ‘ 文件>新>目标… adımınlarınıizleyerek yeni bir观看projesioluşturmayabaşlıyoruz。 Daha sonra Resim 1.1’deki gibi WatchKit App应用了 。 Bu noktada projeye bir isim vermen gerekiyor。 Ben WatchTest专用语。 […]

Swift:第一时间获得正确的MVC

开发人员为什么倾向于在其视图控制器中填充视图? 在Swift中使用MVC的更好方法呢? 我遇到的大多数开发人员都倾向于做真正奇怪的事情。 他们中有些人避免洗衣服和发臭,像地狱一样。 其他人则喝加盐和胡椒粉的咖啡。 但是我看到的最常见的行为是,开发人员不使用视图,而是喜欢在视图控制器中执行所有与视图相关的操作,例如填充,创建动画等。 首先,假设我们有一些描述用户的结构: 其次,我们的任务是用该用户的数据填充一些演示文稿。 许多开发人员的代码,甚至是Apple在其教程中提供的代码,看起来都像下面的怪兽: 罪人,听我说,谁会说:“哦。 嘿。 那就是我通常写的代码。 实际上,这没有什么错。”实际上在几个层面上确实是错的: 视图的内容取决于您何时设置模型。 它不可扩展且不可维护; 这是不可重用的。 而且,我们不应该忘记使@IBOutlets变弱,因为视图控制器的view属性可能会更改,并且我们将对视图持有强大的引用,对此我们不承担任何责任。 如果模型是在视图出现后设置的(例如,它是从Internet下载的),则不会在屏幕上显示,除非进一步进入导航层次结构然后返回。 有很多人在野外用viewDidLoad做到这一点,但更糟糕的是,更新内容的唯一方法是用新模型创建新的视图控制器。 即使这样,如果在将控制器推入导航控制器后设置模型,也不会显示该模型,因为在推入过程中已经调用了viewDidLoad 。 可扩展性和可维护性在这里也确实很痛苦。 您的视图控制器负责填充整个视图层次并为其设置动画。 目前,只有2个子视图,但是想象一下,您有20个甚至更多。 此外,您必须为它们设置动画或根据模型数据更改它们的外观。 viewWillAppear很快就会变成一团糟。 至于重用,请设想一下这种情况,当您希望在不同的视图控制器上呈现相同的视图和模型关系时,具有何时以及如何获取和处理模型的逻辑不同。 例如,在表格视图中将其显示为单元格,或者将其呈现给来自不同API端点的另一种用户。 在我看来,确实很奇怪,网络上没有那么多声音,他们提出了一种更好,更简单的选择。 在大多数情况下,开发人员不会反对编写任何东西: 让我们考虑一下。 UILabel具有一些复杂的绘制逻辑和字符串处理功能。 它的作用是显示字符串。 但是视图的字符串是什么? 这不是很明显吗? 这是模特!!! 那么,为什么我们的代码在使用自己的视图时却归结为我之前模拟的代码? 有些人会开始争论,那是做MVC的正确方法。 MVC是一种设计模式。 苹果公司在其代码中做到了这一点,我们应该承担义务。 你知道,这使我想起什么? 使用20个类和协议编写具有hello world的企业Java项目。 当然,Java开发人员可以简化事情,但是他们严格遵守GoF和其他主流设计模式,忘记了它们是建议,而不是严格遵循的规则。 让我们从我坚持的观点出发,对我们的代码和演示进行推理。 我们的每种观点都与某种模型紧密相关。 它的设计和呈现方式仅适用于一种模型。 证明? 您将无法使用用户展示屏幕展示考试数学问题。 它的设计不同,子视图也不同。 例如,同样适用于UITableView,但是在这种情况下,我们应该将其模型视为模型数组。 在那种情况下,它适合于1模型与1视图关系的相同方案。 同样适用于动画和其他内容。 View Controller不应在实现细节的底层上处理这些事情。 […]

询问专家:一劳永逸地揭穿iPhone应用开发的7个神话

这是2018年iOS应用程序开发的现实情况: 有很多假新闻。 在开发和设计iOS应用程序时,似乎每个角落都有一个崭新的神话。 无论您是阅读博客文章,观看视频,还是只是滚动浏览Facebook提要,您都必定会至少怀有一种陈词滥调的信念,即如何构建iPhone应用程序。 也许这是您用来构建它的语言。 也许这是您应该或不 应该使用的Apple工具。 也许这是您通常必须进行应用程序构建过程的方式。 底线是:我们正处于数字时代,无论您到哪里都可以找到关于应用程序开发过程的神话。 这给我们提出了一个非常重要的问题…… 我们向一些才华横溢的iOS专家提出了这个问题,以获取有关iPhone应用程序的BS知识,并征询他们在构建iOS应用程序时应真正关注的方面的建议。 根据我们的专家的说法,以下是有关构建iOS应用程序的7个最大误解,以及在创建自己的应用程序时可以依靠的主要知识: 当我们要求Unsplash的本机应用程序构建者Olivier Collet列举最大的iOS应用程序开发神话时,他说: “我认为许多开发人员低估了Apple提供的工具和框架,浪费了太多时间来思考应用程序体系结构和新概念。 我看到了太多过度设计的应用程序,并且阅读了太多文章,这些文章带来的复杂性比简单性还要大。” 这是关键要点: 您不需要重新发明轮子。 在构建iOS应用时,不要害怕使用Apple提供的框架。 它们是由经验丰富的iOS开发人员创建和微调的,它们对有效的方法和无效的方法有大量的了解。 iPhone应用程序开发人员经常将苹果的框架标记为过于简单,而是尝试从头开始构建某些框架。 典型的结果是,一个应用程序的构建时间要长得多,并且比实际需要的复杂得多。 拥抱简单。 阅读:了解移动应用程序用户体验设计的终极指南 这是汗学院的早期产品开发负责人安迪·马图沙克(Andy Matuschak)所说的最著名的应用程序构建神话: “关于应用程序的最重要的神话是,应用程序创建过程中重要的,具有挑战性的部分是技术。 它在上下文中了解真实的人类需求,并追踪这些需求与技术可能会促进的重叠。 编程是容易的部分。” 对于有经验的开发人员而言,编写代码和对应用程序本身进行编程不太可能成为主要挑战。 真正的挑战是: 您需要了解用户的需求,以及如何提供与他们的需求相匹配的应用程序体验。 在开始构建iPhone应用程序时,用户必须排在第一位。 问问自己您要解决的问题是什么,什么会促使某人下载您的应用程序,以及如何确保自己构建的东西是人们会感兴趣的东西。 objc.io的联合创始人兼作家Chris Eidhof告诉我们: “我们刚刚写完了App Architecture一书。 我编写该书的最大收获就是,只要您了解局限性,就可以在任何体系结构(也包括MVC)中编写简洁的代码。” 人们普遍认为,您只能使用某些类型的应用程序体系结构来创建某些类型的iOS应用程序,并且尝试使用其他体系结构来构建应用程序会导致代码混乱和糟糕的用户体验。 事实是,只要您知道它的局限性,就可以使用任何体系结构构建一个干净的iPhone应用程序。 在深入研究适用于iOS应用程序的其他应用程序体系结构之前,请先研究该体系结构的局限性,以确保代码始终干净。 如果您事先不知道局限性,则可能会发现自己在回溯工作以修补并修复过去的工作,从而造成不必要的麻烦和不理想的用户体验。 我们已经揭开了开发人员必须在Apple框架之外思考的神话。 但是,根据Artsy的设计师兼工程师Orta Therox所说,太多的开发人员只在盒子里思考: “大多数人只是假设苹果在制作应用程序时最了解,并选择始终复制苹果的策略并在自己的约束范围内生存。 考虑到构建应用程序的问题,这并非总是正确的方法-因为Apple与您的需求截然不同。” 不要害怕拥抱您的内在创意,并将Apple先前存在的框架提升到新的高度。 尽管Apple的框架是一个很好的起点,但您的iPhone应用程序(希望)正在解决一个独特的问题,无论谁构建Apple的框架都可能没有考虑过。 无论苹果提供了什么框架,都可以利用您对上述问题的专业知识,构建最适合提供解决方案的iOS应用。 当我们向PSPDFKit的创始人兼首席执行官Peter Steinberger询问他对应用程序开发神话的看法时,他简短而贴切: “您需要使用Swift才能拥有成功的应用程序。” Swift是Apple创建的一种编程语言,用于在所有iOS设备上构建iOS应用程序。 […]

编写健壮的无字符串Swift代码

在不使用字符串的情况下使用情节提要,Xib和ViewController 您如何避免错误? 显然是因为没有编写任何代码。 但是,还有另一个神秘而又不那么幽默的答案。 通过不进行硬编码。 iOS最糟糕的功能之一是对字符串的过度依赖。 难怪如此轻视键值观察(KVO),是的,甚至包括使用故事板和视图控制器实例化。 随着Swift的发展,Apple试图减少字符串的使用,例如在选择器中。 例如,在Swift 2.2选择器使用之前,如下所示: button.addTarget(self, action: Selector(“buttonTapped”), for: .touchUpInside) 。 然后,他们改进为: button.addTarget(self, action: #selector(buttonTapped(_:)), for: .touchUpInside) 。 但是仍然非常依赖,这带来了很大的潜在错误。 考虑以下iOS开发人员可以编写的完美代码: 使用字符串和强制转换实例化ViewController。 容易出错的做法。 注意使用字符串引用情节提要和实例化viewControllers。 在命名情节提要或viewController时犯错误的可能性非常大,这会导致错误代码。 随着代码中使用硬编码字符串的次数增加,在代码中产生逻辑(和致命)错误的机会也随之增加 。 我希望与tableview单元格标识符相关的崩溃能够引起一定的注意。 现在,让我们看看如何避免在代码中使用字符串。 首先,让我们添加一个UIViewController扩展,它不仅在编写代码时使用最少的字符串非常方便,而且在您的应用程序使用各种独立模块(还需要使用自己的故事板)的实例中增加便利性您的主要应用程序。 UIViewController扩展可从任何模块实例化ViewController 在这里, “(\self)” 在storyboardID类属性中,只需返回ViewController的名称。 为此,您要做的就是将ViewController的Storyboard ID命名为与ViewController类相同。 简单。 方法instantiateViewController(viewControllerClass: T.Type, inStoryboard: String, ofModule: Bundle?) -> T实例化任何viewController,只要它是类UIViewController,则此控制器在位于某些模块,无论您当前模块之内还是之外。 接下来,我们为故事板名称添加一个枚举 。 Swift之所以漂亮,是因为枚举可以具有属性,甚至可以具有方法。 请参阅下面的代码片段,以了解如何添加便捷方法。 在这里,我添加了方便的方法来实例化viewControllers,navigationControllers和tabBarControllers。 一个Storyboards […]

如何提出出色的应用创意

就像作家有时会受到作家的阻碍一样,应用程序开发人员有时也会得到类似的东西。 您正在尝试为一个应用程序提出一个好主意,但是每次您想到某个东西时,事实就已经存在了。 这个过程可能非常令人沮丧,那么您应该怎么做才能避免呢? 寻找下一代天才革命性应用程序时,它始终取决于视角,您的研究可能性可能会受到限制,但它总是有助于查看您或您的朋友和同事每天面临的问题。 我该怎么做才能改善我或他人的生活? 出色的应用程序使使用它的人的生活更轻松。 这可能是您在寻找下一个想法时必须记住的一句话。 金钱方面不是主要动机,因为提出创意确实需要一定水平的创造力,而且正如大多数艺术家可能会告诉您的那样,创造力并不总是会花钱。 当然,您必须有一个长期的获利策略,但是它绝不应该限制您的创意寻找过程。 我还建议您不要靠近竞争对手,例如,当前的iTunes图表。 因为为什么要看已经存在的东西? 您需要找到您热爱的东西,并且其他人可以与之联系。 无论是猫还是保持生活井井有条。 根据个人经验,我可以告诉您,除非您对所从事的工作充满热情,否则它将永远无法达到最高质量。 不要被少数几家卖了几百万美元的初创公司所迷惑,它们是例外,您永远不要试图模仿它们的成功。 他们都没有想到,当他们开始时会以那么多的钱出售他们的应用程序。 他们之所以这样做,是因为他们相信自己的想法。 因此,总结一下:与您的朋友,家人和同事交谈,以了解他们在生活中的价值。 向他们询问最喜欢的应用程序,缺少什么或如何改进它们。 列出您一周内要做的事情,并考虑这些事情在哪些方面为应用程序带来改进的潜力。 一旦您提出了一个好主意,就该开始编码了,并且如果您不是专业的应用程序开发人员,我建议您参加与我的同事Johannes Ruof一起在Udemy上教授的课程。 使用此链接获取 “学习如何编码-iOS的专业Swift开发”可享受90%以上的折扣。 或点击此链接并使用代码:MEDIUM15

我在iOSCon 2017上的演讲经验

我很幸运参加了在伦敦举行的iOSCon 2017,并谈到了Swift中带有协议缓冲区的类型安全Web API 。 这是我第一次在国际会议上发言,但我真的很享受! iOSCon — iOS和Swift开发人员会议这是一年一度的iOS会议,每年都有很棒的演讲者! 因此,我很荣幸在如此出色的会议上担任演讲嘉宾! iOSCon 2017 – iOS和Swift开发人员会议| 2017年3月30日至31日| 伦敦 在英国伦敦举行的为期2天的会议。 iOSCon庆祝iOS的最新发展和最敏锐的头脑。 做… skillmatter.com 如果您对明年的iOSCon感兴趣,那么您绝对应该检查一下! iOSCon 2018 – iOS和Swift开发者大会| 2018年3月22日– 23日| 伦敦 在英国伦敦举行的为期2天的会议。 iOSCon庆祝iOS的最新发展和最敏锐的头脑。 做… skillmatter.com 我的话 我的目标是向许多人介绍协议缓冲区(也称为protobuf)。 因此,我分享了有关protobuf为何如此重要以及我如何在Swift中使用protobuf的经验和知识。 这是protobuf的快速回顾。 类型安全-您可以为HTTP请求/响应定义自己的类型 跨平台一致-您可以通过代码生成器共享模态数据 可扩展-protobuf是一种序列化格式,可以在任何地方使用。 我相信protobuf最适合Swift! 像我上面提到的那样,它有很多好处,所以绝对值得! 如果您对更多细节感兴趣,可以在这里找到我的幻灯片,示例应用程序和视频。 kitasuke / SwiftProtobufSample SwiftProtobufSample –使用协议缓冲区的Swift中客户端/服务器的示例项目 github.com Swift中带有协议缓冲区的类型安全的Web API 技能专区| 2017年3月30日 iOSCon 2017 – iOS会议和Swift […]

委派指南-Swift 4

现实世界中的代表团 一个很好的起点是通过解释现实世界中的授权。 在现实世界中,委托封装了某人(委托人)将任务(委托人)交给其他人(委托人)。 有两个名词和一个动词组成委派: 委托(动词):“将任务或责任委托给另一个人”。 委托人(名词):“委托他人的人”。 代表(名词):“被选择或当选代表他人的人”。 为了澄清-委托人(名词)会将责任(动词)委托给委托人(名词)。 现在我们有了组成委派的组件的字典定义,接下来让我们实际展示一个真实的委派示例: 在仓库中,将有一名物流经理( 代理人 ),他们将知道卡车何时到达以及何时到达。 物流经理很忙,虽然他们很擅长管理物流,但在装卸和搬运箱子时却不那么擅长。 因此,他们将这项工作( 代表–动词 )交给仓库操作员( 代表–名词 )。 后勤经理告诉仓库操作员,一辆卡车将在09.00到达,当到达09.00时,他们告诉仓库操作员该卡车已经到达。 然后,仓库操作员卸下货车并将箱子运到需要的地方。 iOS世界中的代表团 数字世界中的委派与现实世界中的委派非常相似,不同之处在于,我们拥有的不是对象而不是人,而对象在Swift中将是类,结构或枚举的实例。 让我们以对现实世界相同的方式来分解软件开发中的委托: 委托(动词):将任务或责任委托给另一个对象。 委托人(名词):将职责“移交给”另一种类型的实例(对象)的类或结构实例(对象)。 委托(名词):保证处理已委派职责的对象,即提供委派的功能。 需要澄清的是,委托是指一个对象(代理)代表另一个对象(代理)提供功能时的行为。 现在,让我们通过从参与对象的角度来考虑委派来进一步深入研究: 您创建一个待办事项列表应用程序。 您可以将UIViewController子类化,以创建名为“ ToDoListViewController ”( 委托–名词 )的视图控制器对象。 您将一个UITableView实例( 委托人 )放在ToDoListViewController 。 UITableView会显示要执行的项目并检测与之交互的时间,但会将处理这些交互( 委托–动词 )的责任移交给另一个对象。 UITableView实例( delegator )将向事件的委托对象通知其将要处理或刚刚处理的事件。 ToDoListViewController ( 委托人–名词 )声明它将提供响应UITableView处理的事件而发生的功能。 假设UITableView实例( delegator )可以讲话,该对象可能会说:“ 我是一个表视图对象,并且选择了第3行 ”。 “ ToDoListViewController […]

Swift:常见错误无人问津-宏和指令

您好,我亲爱的开发人员, 我有个故事要告诉你。 从前我很无聊。 那时我像往常一样在课堂上玩耍,用猕猴桃为他们编写测试。 我偶然发现了一个有趣的问题,我真的很想为块模拟,以删除不必要的样板。 可悲的是,没有人开源。 所以我想,为什么不写呢? 具有一些非常有趣的功能的请求不会伤害我或整个社区。 因此,我开始实施代码,并在重构和挖掘运行时库的过程中发现了很多奇怪的事情。 可悲的是,故事并没有很好地结束,因为当我提交请求请求时,维护人员决定停止添加任何具有大型功能的新功能。 而且我就像FFFFFFUUUUUUUUUUUUUUUUUUUU…。因为在接受请求请求之前,我开始在项目中使用该Kiwi功能,这意味着我必须维护并行分支。 我的故事。 那好吧… 尽管如此,在这段旅程中,我发现代码中散布着一件有趣的事情: #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG @尝试{ #endif // #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG … #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG } @catch(NSException * exception){ KWSetExceptionFromAcrossInvocationBoundary(exception); } #endif // #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG 如果看一看,您会发现它分散在整个代码中,但是它具有清晰的模式。 对我们来说,这意味着应该删除重复数据。 为什么,因为从表面上看,这种黑客不再存在,但是将其从代码库中删除真的很困难,因为代码绝不是孤立的。 而且,从我收集到的信息来看,不再需要这种hack(我不知道它的引入原因,但是在禁用它的情况下测试不会失败,至少看起来像这样,因为我没有进行深入研究) 。 您不应该认为这是针对猕猴桃的怨言,因为事实并非如此。 Kiwi令人敬畏,它的开发人员和维护人员构建了我多年来使用的工具,并且在编写ObjC代码时仍在使用。 阅读完代码后,我决定不想自己碰到此类问题,因此我添加了一条准则,使所有特定于宏的代码隔离。 如果我们将该准则应用于我专门为您编写的错误代码: 这不是唯一迅速解决的具体问题。 它们有很多,甚至没有用#标记。 因此,对于此类代码,更好的措施是至少将其隔离为单独的功能。 但是,这也不是最好的主意。 为什么? 我们在整个代码中具有不同的特定操作,这导致我们遇到#if os(iOS)的相同问题,该问题既重复又难以重构。 因此,更好的方法是使用与注入闭包和隔离此类代码相同的方式进行操作: 您可以在以前的演讲中读到更多有关注射的信息: 没人管的常见错误– Swift扩展 最糟糕的编码方式。 […]

iOS中的通用链接

免责声明 :要撰写这篇文章,我必须在互联网上阅读很多东西。 另外,我还复制了其他文章中易于理解的示例和句子,以使本文有意义。 🤓 Apple文档链接提供通用链接。 什么是深层链接? 深层链接是任何将用户引导通过网站或应用程序首页到其内部内容的链接。 例如,直接链接到产品而不是首页。 例如,URL fb://可以打开Facebook应用程序,但是fb://profile/33138223345可以在Facebook应用程序中打开Wikipedia的个人资料。 如果您想与朋友分享来自amazon.com的鞋子,则可以发送一个深层链接,将您的朋友直接带到应用程序中的那些鞋子。 如果没有深层链接,您的朋友将不得不在App Store或Play Store上找到Amazon应用程序,将其打开到首页,找到“搜索”功能,然后尝试找到与您所穿的同一双鞋。 自定义URI方案是移动应用程序深层链接的原始形式。 它们就像为您的应用程序创建一个“专用互联网”,其链接类似于myapp:// path / to / content 。 自定义URI方案的优点是易于设置,并且大多数应用程序已经拥有一个。 缺点是,如果已经安装了相应的应用程序,则用户的设备仅知道此“专用互联网”,并且默认情况下没有优雅的后备选项。 与URI方案进行深度链接的变通办法是使用传统的http://链接来启动Web浏览器。 此链接包含JavaScript重定向到自定义URI方案,该重定向由网络浏览器执行以启动应用程序。 如果由于未安装应用而导致重定向尝试失败,则JavaScript会将用户带到App Store或Play商店。 这仍然是在Android上进行深度链接的主要方法,但是Apple于2015年通过发布Universal Links开始在iOS上阻止了这种方法 。 什么是Apple iOS通用链接? 苹果在iOS 9中引入了Universal Links,以解决自定义URI方案深层链接中缺少优美的后备功能的问题。 通用链接是指向网站和应用程序内的一部分内容的标准Web链接(http://mydomain.com)。 打开通用链接后,iOS会检查该域是否已注册任何已安装的应用程序。 如果是这样,该应用程序将立即启动,而无需加载网页。 如果不是,则将Web URL(可以是到App Store的简单重定向)加载到Safari中。 通用链接在iOS中如何工作? 资料来源:Branch.io 在Universal Links之前,在安装应用程序时打开应用程序的主要机制是尝试在Safari中重定向到应用程序的URI方案(像这样在应用程序的PLIST中注册)。 这将路由逻辑放入了Safari,但是无法检查是否已安装该应用程序。 这意味着开发人员将尝试在无法安装应用程序的情况下100%地调用URI方案,然后在不使用计时器的情况下优雅地回退到App Store。 iOS 9通用链接旨在解决此问题。 iOS将检查是否已注册通用链接( 而不是在包含该应用程序包ID的域中存在一个AASA(苹果应用程序站点关联)文件) ,而不是先单击该链接便打开Safari。 应用程式应开启的路径( […]