喜剧Central iOS App：前沿学习

投资改写

在软件工程领域，没有什么比“重写”更令人恐惧的了。因此，当我们的技术团队提出理由这样做时，您可以想象在管理人员眼中的喜悦。

但是像图片一样，表情符号有时值一千个字…

移动开发发展迅速。 每年秋天，开发人员都会面对其操作系统和新工具的新版本。 加快您的古老代码库的速度变得更具挑战性。 开发团队发现自己正在为过时而战，而不是尝试新功能。

我们支持的一些过时的供应商代码位于Restkit和XML提要之上。 其中一些依赖于NSURLConnection，该类在iOS 7中不推荐使用NSURLSession。如果您提前计划，并且您的应用程序支持良好的抽象水平，则可以缓解此类问题。 但这并非总是如此。

我们设定了一个目标，以构建可满足我们未来需求的可扩展移动应用架构。 我们仔细查看了当前的旧版应用目录。 我们问自己，什么有效，什么无效，什么有效，足以改进和重用。

像许多旧版软件一样，逐个功能也变得复杂。 随之而来的是不断增加的技术债务。 我们的前端软件已接近极限。 我们的Feed架构也在遭受痛苦。

这些主要因素，再加上新的，现代的和灵活的API，巩固了我们的立场。 我们从利益相关者那里获得了绿灯，重新开始。 我们与内部API开发人员和产品经理合作，共同创造了未来的证明。 适合我们自己的技术，生产和业务需求的东西。

迅速还是不迅速？

大约一周前，Swift Evolution邮件列表上一个有趣的话题引起了我的注意。 它在主题行中承诺“认真！ 在3.0版发布后将Swift冻结两年！”

我们从Swift 1.1开始我们的项目。 目前，Swift 2.3和3.0（又名“ The Grand Renaming”）正在测试中。

每次发布都很痛苦。 语言经常在我们下面改变。 调试和重构变得更加困难。 并且由于删除了本机方法curring，因此编译时间增加了。

但从积极的方面来说，Swift减少了项目中的文件数量。 简明扼要。 它的类型系统和泛型使我们无法编写大量代码。 它也是函数式反应式编程的重要合作伙伴。 标准的Swift库已经提供了您需要的很多东西。

而且，我们都可以同意，Swift比其冗长的前身Objective-C容易得多。

尝试现代概念和框架

大多数iOS应用程序使用MVC架构模式。 我们的要求使我们走了一条通往MVVM（模型视图ViewModel）的道路。

我们还将功能性反应式编程引入了我们的代码中。 在大多数情况下，我们在数据层中使用了它。 我们采用了Promises，这是并发编程语言（例如Scala）中使用的概念。

PromiseKit和ReactiveCocoa是必不可少的两个库。

PromiseKit是帮助程序功能的实现和集合。 它将Promises的概念引入了iOS，并阐明了复杂代码的意图。 使用干净的语法，可以轻松管理工作单元的顺序和/或并行执行。 它是线程安全的，并带有用于并发管理的出色实用程序。

ReactiveCocoa是针对iOS的功能性反应式编程的实现。 我们将其用于数据和UI之间的绑定。 同时也简化了底层iOS事件机制的抽象。 我们选择ReactiveCocoa而不是RxSwift，因为团队成员已有使用它的经验。 另外，RxSwift当时还太新。

使用闭包并添加侦听器时，PromiseKit可能会发生内存管理问题。 我们还发现PromiseKit有时会弄乱调试链。

这些概念的学习曲线可能有些陡峭，但从长远来看，值得进行投资。

不要太依赖别人

每次我们下载新版本的Xcode并尝试构建该应用程序时，都会遇到问题。 这些几乎总是我们无法控制的。 Swift Migrator工具运行得很好，但是经常会出现这样的错误：

您将只能像选择集成到自己的代码库中的库一样快速移动。

诸如PromiseKit和ReactiveCocoa之类的图书馆周围都有许多社区。 他们的团队通过快速更新解决了Swift beta中的问题。 但这并不是您选择的每个第三方或您的业务为您选择的每个第三方的情况。 如果决定由您决定，请问自己是否需要

另外，您应该限制所包含的库总数。 我们发现，在旧设备上，大量依赖是导致应用程序启动时间的罪魁祸首。 Apple建议您最多只包含六个外部依赖项。

使用适合您的工具

Xcode的Interface Builder和Storyboard中的视觉布局在不断改善。 新手程序员可以轻松创建简单但令人印象深刻的应用程序和自适应布局。 但是，这并不意味着它是适合所有人的正确解决方案。

故事板可能会减慢iOS的开发速度。 他们对Xcode造成了损失，并且容易合并冲突。 他们还可以将您的流程，视图和业务逻辑纠缠在一个位置。 这不能很好地扩展。

我们着手创建一个应用程序，其中尽可能多的UI是数据驱动的和动态的。 情节提要不是实现此目的的正确解决方案。 我们使用了一个称为PureLayout的库。 我们将视图和模块构建为可重用的，动态的难题代码段。

了解苹果的最佳做法

业务要求和其他限制有时会妨碍您正确地做事。 但是您应该了解Apple的最佳做法，并尽可能经常遵循。

限制向后兼容性。 苹果的经验法则是采用当前的发行版本，并采用最新的版本。 目前，这是9.3到8.4，在秋天发布iOS 10时，您应该只回到9.3。

将警告视为错误，并在发货前修复所有警告。 Xcode for Objective-C已提供此功能，而Xcode 8以后将可用于Swift。

尽早剖析，然后经常剖析。 发现问题的时间越早，解决问题所需的时间就越少。 始终使用设备而不是模拟器上的发行版进行概要分析。 并在您的应用支持的最旧和最慢的设备上进行配置。

迁移到资产目录。 确保包括要支持的所有分辨率的图像尺寸。 在较旧的设备上缩小3倍的图像可能会导致内存峰值。 您仍然必须加载大图像以将其缩小。 苹果公司今年在WWDC上提出了使用资产目录的令人信服的建议。 （观看“使用现代最佳实践改进现有应用程序”会议）。

移至TLS。 到目前为止，Apple已为开发人员提供了关闭App Transport Security的选项。 他们开始强制执行此操作。 到2016年底，他们将要求开发人员针对其应用中的任何例外情况提供解释。

遵循自己的最佳实践

我们构建了一个我们认为是迄今为止最好的应用程序。 我们也从中汲取了很多自己的最佳实践，我们将继续遵循这些最佳实践。

使用可用的最高级别的抽象。 使用诸如Promises之类的抽象来管理异步。 使用类似ReactiveCocoa的抽象来管理事件，绑定和流。 突破核心功能，例如数据层。 建立功能和职责的分离。 保持尽可能少的状态，并使每个视图都变为无状态。

充满活力。 数据供稿驱动了我们大多数应用。 这使我们的生产者比以往拥有更大的灵活性和控制力。

关注Gitflow。 标记您的发布，并在发布之前将pod版本锁定在pod文件中。 在开始重要任务之前，请参加建筑设计会议。 之后进行有针对性的代码审查。

采用扎实的部署策略。 观看Crashlytics就像鹰一样，仔细考虑潜在的问题。 质量检查周期中的任何崩溃都有可能在应用程序投放市场后爆炸。 验证是否过度安装了该应用程序，以确保在需要时保存用户首选项。

当然，要测试。

测试和自动化，以便您进行创新

MVVM非常适合可测试的体系结构。 模拟和存根对象很容易。 您可以在自动UI测试中表示视图。 而且ViewModels的各种操作和表示方法也很容易测试。

我们的数据和网络层目前处于大量测试范围内。 这样可以确保数据检索和解析稳定且安全。

我们创建了一套Python集成测试，用于后端服务架构验证。 我们还创建了一个基本的自动化套件，可以捕获要回放的服务。 接下来，我们将包括当前版本和最后一个知名版本的屏幕快照比较。 然后使用DVR重播从等式中删除实时数据。

在提取应用程序的各个部分以制作可重用的库和pod时，我们正在创建更多的单元测试。 目标是实现这些组件的高覆盖率。

最后，我们正在努力以一种CTO到DevOps友好的方式来显示我们的测试结果。 然后，我们可以放心，一切都很好，并开始使用iMessage扩展。 其他有趣的事情来自iOS渠道。

立即在Apple App Store上查看全新的CC iOS App！