Tag: Build Time
iOS上的模块化架构以及我如何将构建时间减少了50％。
最近，我被Freelancer聘为iOS工程师，负责他们的核心iOS应用程序。 作为一个年轻，新鲜，进取，积极进取（感谢YouTube激励视频）的大佬，我喜欢编码，我建议我们对该项目进行大约6项改进，以改进它。 更大的问题之一是关于应用程序的编译时间。 当我开始时，清洁后大约花了15分钟。 在这篇文章中，我将描述如何解决如何提高编译时间以及将项目从仅依赖CocoaPods的项目转换为一个分为独立框架组件的项目所经历的过程，我们从中获得的收益以及整个过程过程进行了。 本文部分涉及CocoaPods和迦太基。 对于那些不知道他们是什么的人，我将在这里做一个简短的介绍。 如果您已经熟悉两者，请随时跳过本节。 – CocoaPods https://cocoapods.org/ –迦太基https://github.com/Carthage/Carthage CocoaPods和Carthage都是第三方依赖工具。 它们之间的主要区别是编译以及如何将库附加到项目。 Cocoapods中的Pod是与您的应用程序代码绑定在一起并一起编译的库。 每次您对项目进行清理时，都必须编译所有第三方库。 如果您的项目使用很多库，则编译库会花费大量时间。 迦太基的做法有所不同：它获取库并将其构建到框架中。 然后必须手动集成构建的库。 使用Carthage构建库还需要花费更长的时间，因为它们是针对所有不同处理器架构进行编译的。 但是，无需在项目中进行清理后对其进行重建； 仅当要将库更新到新版本时，才应再次构建库。 应该注意的是，一个库可以被更新而不接触其他所有库。 内置库链接到项目，并在编译后附加到应用程序。 与CocoaPods设置相比，设置Carthage并将所有库链接到项目可能很耗时。 两种工具各有利弊。 通常，CocoaPods库更易于添加，删除和维护，但必须在清理后再次编译。 迦太基的添加，删除和维护更加困难，但是节省了时间，因为在清理项目后不会再次编译所有库。 该项目自2012年以来一直在开发中。我不得不处理大量旧代码，并一路将某些Objective-C类重写为Swift等。但是总的来说，最大的问题是CocoaPods库。 我们大约有80个与该应用程序捆绑在一起的库，这当然花费了大量时间。 不幸的是，由于某些库具有依赖性，尤其是内部开发的库，要摆脱CocoaPods库并不像用Carthage替换库那样容易。 内部开发了80个CocoaPods库中的18个。 例如，Core库处理API和持久性，Components库具有UI组件，而Feature1库当然具有feature1，依此类推。 我对CocoaPods依赖关系图非常不满意，即Core库将Moya，RxSwift，RxMoya，SwiftyJSON等作为依赖关系，而Core库是Feature1库的依赖关系，Feature1库具有自己的依赖关系，如RxCocoa，RxDataSources等。 …下图描述了我们拥有的CocoaPods库的简化依赖关系图。 请从上图中的18个内部CocoaPods库和62个第三方中想象这个概念……那么，仅安装CocoaPods库需要花费一些时间。 您可以通过在内部podspec中添加其他一些依赖关系来轻松地打破树形结构，因为每个内部库都有其自己的podspec，因此很难组织特定第三方库的来源。 这个主意 清洁后编译第三方Pod大约需要6分钟，这是无法接受的。 但是我不能随便用框架版本替换例如Alamofire，因为Moya将Alamofire作为依赖项，因此RxCocoa具有RxSwift等等。 因此，如果我要用其框架版本替换Alamofire，则Moya库将始终下载Alamofire，因为它依赖于它。 最后，我将获得两个与该项目链接的Alamofire库，一个是手动库，另一个是与CocoaPods一起使用。 这只是问题的一个例子，不用说我在其他62个库中也遇到了类似的问题。 我不想这样做。 我们决定摆脱内部Pod，而是创建框架。 我们不想放弃CocoaPods，因为我们的某些CocoaPods库与Carthage不兼容，说实话，用CocoaPods测试新库比使用Carthage容易得多。 我们的目的是同时拥有这两个功能-包括由Carthage与CocoaPods共同构建的第三方库，以及我们的内部框架和项目。 好主意…这就是真正的工作开始的地方。 在对如何将Pod与框架结合在一起进行研究之后，我创建了一个有效的概念证明，但我对此并不十分确定，也不知道它在大型项目中将如何工作。 关于框架 框架是什么？ 我们可以将框架看作是独立的并可以链接到项目的捆绑包。 库和框架之间的主要区别在于控制反转（IoC）。 当您使用库中的内容时，就可以对其进行控制。 另一方面，当您使用框架中的某些内容时，您会将其责任转移给框架。 […]
iOS @ Over：成立平台团队
所有扩展团队都面临的挑战是处理越来越多的技术债务和性能问题。 团队中只有几个人，在重构和知识共享上进行协调就更容易了。 随着团队的扩大，协作和沟通变得越来越复杂。 一旦这些团队开始更快地行动，放慢速度并处理越来越多的技术债务就变得更加困难。 在本文中，我们将说明Over团队内部发生的情况以及导致iOS平台团队创建的原因🚀 a扩展团队的裂缝 随着我们团队的扩展，我们的代码库也是如此。 我们主要在Swift中进行开发，这对我们的总体构建时间有很大的影响（希望这可以改善WWDC🤞）。 Buddybuild上的构建服务器大约需要20分钟的时间来构建并运行我们对Pull Request的所有测试。 干净构建Over可能最多需要3分钟的时间。 这些时间每天都会加起来，当我们开始注意到如何切换到Slack或等待时浏览网页时，情况会变得更糟。 等待构建时进行的所有上下文切换确实损害了我们的生产力。 我们经历的另一个痛苦点是不断增加的技术债务。 一个这样的例子就是我们用团队替换了圈子功能。 这是一个很大的重构，也已实现为功能标志。 这意味着Circles和Teams并存。 一旦我们最终发货，团队就继续为团队提供支持，并且无法真正证明删除旧代码所花费的时间是合理的。 毕竟，将有意义的功能交付给我们的用户是我们的首要任务。 以上问题只是众所周知的冰山一角。 一旦我们退后一步，很明显，我们需要一支专门的团队来完成产品工作，并且可以专注于帮助我们的iOS团队更加成功。 我们确定了我们团队中的一个人Jamie Raad，他愿意潜入创建平台团队并定义工作量和优先级工作。 让我们看看它是如何下降的……😃 ✍️定义我们的平台团队 平台团队的存在是为了确保面向用户的功能团队的持续成功。 由于平台团队不受功能工作和产品截止日期的束缚，因此可以自由地关注更广泛的挑战，这些挑战会阻止团队更顺畅地进行运输或提高生产力。 这是我们作为团队优先考虑的任务列表，我们应该从以下几项开始： 缩短构建时间（在本地和在Buddybuild上）。 研究新的崩溃报告工具。 从应用程序中删除领域。 来自各个部门的临时请求。 平台团队还负责倾听团队的技术需求，并研究新的和改进的API，以协助软件交付。 拥有一支专门的团队还意味着我们有资源来调查诸如难以复制的模糊错误，图像预加载机制以及可重复使用的通用提要的方法。 这些只是平台团队可以改善我们工作方式的一些现成示例。 👀第一组结果 随着平台团队的建立和准备就绪，我们开始了第一个挑战： 构建时间 。 此处的目标是尝试确定构建哪个框架花费的时间最长，以便我们可以准确地确定优化的地方。 最终，能够将构建时间减少至少50％将是一项巨大的成就。 为了获得结果，我们遵循将不同的诊断选项传递到编译器的这些准则。 我们通过了-driver-time-compilation和-Xfrontend -debug-time-compilation 。 这里有更多关于他们的信息。 xcodebuild -destination ‘platform=iOS Simulator,name=iPhone 8’ \ -sdk iphonesimulator -workspace […]
