iOS开发的十条准则

322 阅读9分钟

如果您想成为一名iOS架构师,必须熟悉最佳实践并遵循一系列iOS开发的核心原则。为了使学习iOS开发的最佳实践更容易,我将它们归结为现在称为“ iOS开发的十诫”。指导您根据最佳实践进行iOS开发的关键原则,而不是应100%地盲目遵循的严格规则。

这个想法是受iOS因素启发的,简单且专注于基本原理。

1:模块化应用程序

“在编译应用程序时,我会想去喝杯咖啡。”这样的短语是一个危险信号。您的架构体系可能非常单一。如果您不希望代码库中的任何更改触发整个应用程序的重新编译,那么能够独立地创建,运行和测试部件至关重要,尤其是在大型项目中。

维持快速编译时间的常见解决方案是对应用程序进行模块化。模块化对于随着时间的推移实现可扩展和可维护的应用至关重要。您可以通过多种方式将您的应用拆分为多个模块。一种常见的方法是按功能拆分应用程序,这意味着不同的功能团队可以独立地重新编译,测试和运行其功能模块。您可以用不同的方式创建模块。您可以在Xcode或依赖管理器中使用框架,例如Cocoapods,Carthage或SPM等。

模块化架构会增加额外的复杂性,因此请谨慎考虑此决定是否适合您的应用程序需求。但是随着代码库的增长,这将导致编译时间减少以及对区域/职责的强制性和明确分离。

2:始终保持应用性能

即使最引人注目的应用程序如果不执行,也会很难挽留用户。为确保在开发应用程序时优化性能,请遵循以下一些原则。

  • 测量,测量和再次测量。使用那些工具(分配,Timeprofiler,泄漏和活动监视器)来分析性能问题,内存泄漏,阻塞主线程的功能等,以提高测量的性能。
  • 延迟不需要立即启动的任何初始化,以加快启动时间。使您的应用快速响应命令可为用户提供更好的体验。
  • 了解并使用Apple编写的高性能Swift代码中建议的优化技巧。
  • 拥抱感知的性能。使用本书中的所有技巧,使您的应用看起来运行得更快,更好。做类似的事情:
    • 显示一个类似于初始屏幕的启动屏幕。
    • 在等待HTTP请求完成时显示微光效果(而不是显示微调器)。看看Facebook的Shimmer。
  • 避免进行微优化,直到以后。他们通常不是真正的罪魁祸首。优先关注整体的性能。

3:您应该偏爱继承而不是继承

为什么我们应该主张组成而不是继承?复合设计重用原则是软件设计中众所周知的设计原则,其中指出:

类可以通过包含实现所需功能而不是使用继承的其他类来实现多态行为和代码重用。

在诸如Swift之类的语言中,不可能从多个类继承。这就限制了我们使用继承/子类化功能将我们的微型单一用途组件组成应用程序的能力。相反,我们有协议来组合,因为您的类可以从多个协议继承(甚至协议也可以从多个协议继承)。然后,我们可以使用协议扩展将功能添加到协议中,因为这使我们能够提供协议实现,从而实现可重用的组件。

4:应该偏爱本地而不是远程

有多种原因可以委托更多的业务逻辑在设备上本地执行,而不是从远程后端获取计算的结果。以下是一些为什么您应该针对本地运行的任务进行优化的原因:

  • 由于某些用户每月有数据限制,因此可以减少数据使用量
  • 连接可能并不总是可靠的,这可能会损害应用程序的体验
  • 取决于所发送的数据类型,可能会担心隐私问题

此外,您将从改善本地经验中受益。您的应用程序不需要所有内容都可以连接互联网-有时根本没有连接。例如,社交媒体应用程序应该能够以读取模式显示历史数据,而不是在没有互联网连接的情况下变得完全无法使用。最后,将请求数限制到后端将通过提高响应速度和减少加载时间来简单地增强用户的体验。

5:尊重远程配置功能

尽可能将配置排除在代码库之外,即API密钥,URL,功能切换等。我们有几个原因希望远程控制它们。API密钥可能会过期,URL可能会更改。远程功能切换(由Pete Hudgson定义为操作切换-请参阅Martin Fowler的博客中的这篇文章)是一个强大的概念。以下是具有远程可配置功能切换的一些原因:

  • 远程禁用生产中的功能
  • A / B测试,仅对部分活动用户启用某些功能
  • Canary发布通过将更改发布给一小部分用户,以降低风险,然后将其提供给所有人。

6:自动化部署

不要让您的部署到TestFlight / App Store的过程需要办公室里的一个人参与。您应该旨在自动化该过程,以便能够从任何计算机上进行发布,只需触发您的CI系统并使其为您工作即可。

首先让您熟悉 Fastlane 。它是用于测试,构建,代码签名,部署到TestFlight / App Store的一组工具。查看有关如何使用Travis CI和Fastlane建立完整的连续部署管道的文章。

如果您在大型组织中,则有很多原因可以使用Docker和Kubernetes虚拟化和编排构建机器。主要优点是能够在负载增加时轻松快速地扩展构建基础结构。幸运的是,我们去年获得了MacStadium 称为Orka的云解决方案,它允许您使用Kubernetes和Docker在云环境中协调macOS并实现这一目标。

7:如果没有自动整理/格式化,您将无法提交

使用SwiftLint和/或SwiftFormat自动执行代码样式和格式设置,并使用Gi​​t hooks和Danger将其挂钩到开发流程中。不要通过在拉取请求中一再讨论样式规则来浪费时间。只需使其自动化并专注于基本要素即可-提供最佳的用户体验。

做: 使用SwiftLint和/或SwiftFormat自动执行代码样式和格式 使用Git挂钩自动将格式和样式整合为工作流程的一部分 使用“危险”检查更改文件的整理并在拉取请求中发出警告(可选) 别: 在拉取请求中讨论代码样式和格式规则–拉取请求中的很多挑剔可能会散发出一种不规范或(甚至更好)自动化的气味

8:记住向后兼容性

是的,我知道,SwiftUI,Combine,Property-Wrappers(以及我们上次获得WWDC的所有其他东西)是新颖而令人兴奋的。但是,请紧紧抓住,我们暂时还不想破坏我们的向后兼容性。仍然有大量设备无法运行iOS13。当然,这取决于您的用户群。但是在大型组织中,可能需要几年的时间才能开始将对iOS版本的支持降到iOS 13以下。更不用说通过引入尚未经过严格测试的全新工具而损害应用程序稳定性的风险。

您可以在应用程序的某些部分中使用带有@available(iOS 13.0, *)属性的SwiftUI 来注释可用性信息,同时保持向后兼容性。有了这些信息,编译器可以确保这样注释的API可用于当前目标所支持的所有平台。

9:不应以崩溃报告来做无用功

没有什么比最终用户手中的应用程序崩溃更糟糕的了,而且不幸的是,即使所有测试都通过了,也经常会出现无法预料的问题。您应该积极监视用户是否遇到崩溃。因此,在Xcode(Xcode ➞ Organizer ➞ Crashes)中使用崩溃报告是一个不错的起点。

在较大的项目中,这可能还不够。某些工具可让您将分析与崩溃报告相结合,从而通过深入了解复制路径来最大程度地减少故障排除。我建议您为此目的检查Firebase Crashlytics。

最后,一种强大的方法是从应用内用户收集诊断报告。请查看WeTransfer的Diagnostics,以轻松进行设置。

10:在人机界面准则之前,你别无选择

请遵循Apple的人机界面指南,因为它们是设计iOS应用程序时的最佳实践。

苹果公司向设计人员和开发人员提供了《人机接口指南》作为一组建议,以产生美观,可用和一致的用户界面。通过遵循这些准则,我们将站在巨人的肩膀上,并且通过使我们的应用程序更加一致并因此更加直观和易学,更有可能改善用户体验。我们最终还会设计出与其他iOS平台无缝集成的应用程序。

有时,您会遇到一些极端情况,需要您弯曲规则。在这种情况下,我通常建议开发人员与一位高级开发人员进行讨论,然后再迈出务实的一步。

结束语

这是我所经历过的开发中的经验总结,对我参与的项目有帮助。你的情况可能有所不同,因此你可能需要针对你的开发指南调整某些准则。尽管如此,以简单明了的格式定义这些准则对于实现更一致,更有效的iOS开发将大有帮助。

就个人而言,实施这些准则的结果是更快的iOS开发,并且请求请求中的注释更少。总体而言,由于这些准则涵盖了最常见的情),因此代码质量更高。

翻译地址