闲鱼如何解决iOS环境搭建与APP打包速度问题

随着Flutter等跨端框架的出现,业务开发同学经常需要在Android/IOS上跨端进行业务开发,问题定位等。新的不熟悉的环境的搭建总会遇到各种各样的问题,导致搭建失败,特别是IOS开发环境,是最复杂的,不仅环境搭建繁琐,而且切分支后的打包速度很慢,所以我们设计实现了两个工具,用于优化闲鱼IOS开发体验。

IOS开发体验存在的问题

开发环境搭建难

  • 开发环境依赖特定软件版本,配置复杂

闲鱼IOS工程不仅依赖XCode,还依赖了taobaoenv 1.2.0和cocoapods 1.2.0这两个包管理工具。根据大家的经验,这两个工具在ruby2.3.x时,问题较少。特定软件版本,系统自带软件版本冲突,环境变量设置等等一些列的操作步骤导致环境搭建复杂,需要求助IOS开发同学才能搞定。

  • 维护难

Mac系统升级后,cocoapod容易出现问题,不得不重新搭建开发环境。具体原因也是多种多样:系统环境变量变了,导致找不到特定版本ruby;ruby随系统升级导致cocoapod不能用,需要重新安装;Gem版本问题;Ruby源问题等等。这也导致许多开发同学不敢轻易的去升级系统,无法及时体验到新系统的特性。

  • Pod依赖下载量大

由于cocoapod本身的工作原理,pod更新下载工程依赖时,会下载各个版本的文件信息,总量特别大。以闲鱼IOS工程为例,总共需要下载近20G的缓存文件,而且大部分都是几K的小文件,下载时间可能会持续十几个小时,导致新环境搭建到初次体验时间跨度非常久。

切分后APP打包慢

当开发同学在多个分支/版本开发的时候,时常需要切换分支开发调试和bugfix。但是切换分支之后,整个IOS工程打包时间在30-40分钟左右。有时候为了修复一个版本的bug,不得不切换分支,然后重新打包调试。修复和验证bug可能只需要五分钟,打包却用了30多分钟,投入产出不成比例。为了解决这些存在的问题,我们进行了一些列的探索,跟大家一起分享下,也欢迎有更好的解决方案出现。

IOS环境搭建

虚拟化技术的不断发展,为我们统一端侧开发环境提供了新思路,我们设想如果IOS开发环境能够跟Mac解耦,且可以移植,大家可以轻松复用,那么第一二个问题就迎刃而解了。为此我们做了几个尝试:

虚拟机方案

在MacOS本地搭建虚拟机,内装MacOS系统。在虚拟机内搭建IOS开发环境,然后通过虚拟机镜像copy实现IOS开发环境移植,解决环境搭建难题。

这个方案存在以下几个问题:

a. 性能问题,IOS的编译过程是一个IO密集型和CPU密集型操作,虚拟机通过虚拟HOST系统的磁盘和CPU,性能会大打折扣,导致编译时间变长,影响开发体验。
b. 安全问题。在Mac工作机安装虚拟机,需要通过公司安全审核。
c. 黑苹果问题:虚拟机内的Mac系统是没有经过授权的,会带来盗版侵权风险。虚拟机是比较重的虚拟化技术,因此我们转向了更加轻量化的docker技术。

完全Docker化

将IOS开发依赖的软件和环境变量全部docker化。通过docker镜像实现IOS开发环境的移植。对于cocoapod, taobaoenv等ruby类工具,鉴于ruby的跨平台特性,可以很方便的迁移到docker内。但是对于强依赖MacOS的XCode,我们尝试用Facebook出品的xcbuild替代。这是一款兼容xcodebuild的编译工具,网上也确实有网友用这个软件搭建IOS编译环境。

这个方案存在以下几个问题:
a. Xcbuild跟Xcodebuild的兼容性无法评估
b. xcode升级后,xcbuild跟进升级兼容的一段时间内,只能回退到原来的开发方案,来回切换开发环境,体验差。

上面两个方案都没有很好的解决IOS开发环境移植和解耦的问题,但是在完全docker化的尝试中,我们发现最复杂的cocoapod和ruby安装配置部分是能够docker化的,xcode安装后并不需要特殊的配置,因此我们设计实现了一个折中方案:Host内开发(部分docker化)

Host内开发(部分docker化)

本方案中:开发编译调试工作仍然在MacOS本地,使用xcode; 而将cocoapod和taobaoenv相关的软件和环境变量配置等docker化。这样既遵循了开发同学一贯的开发体验,又兼顾了开发环境的可移植问题。

为了能够让Docker内cocoapod拉取的依赖文件和生成的pod工程能被本地的XCode识别,我们将本地pod缓存目录挂载到docker,这样Pod拉取的依赖既能在docker内更新,也能在MacOS中被XCode访问,具体如下图(统一编程平面端+Faas软件架构图):

这样既做到了简化开发环境搭建的复杂度,方便了想尝试IOS开发的同学快速搭建环境,还能给开发同学无差别体验。而且通过这个方案,我们的IOS开发环境可以方便的在各个同学的开发环境中迁移,而且也可以统一进行升级改造。

本方案将Pod相关的依赖迁移到了Docker中,与MacOS解耦,因此IOS开发同学可以自由升级Mac系统,不用担心开发环境被破坏,解决了维护难的问题。

为了解决新搭建的环境需要大量拉取pod依赖的问题,我们将pod的本地中间文件上传到OSS云盘(上图蓝色OSS云盘),开发同学只需要一次性下载压缩包并解压到本地,然后增量更新就可以了。

切分支后APP打包速度问题

客户端开发同学经常需要在多个分支(版本)上面开发业务,且时常需要来回切换进行业务开发和问题定位。这带来的一个问题是:当开发同学从A分支切换到B分支的时候,需要重新打包APP,整个过程大概需要30-40分钟左右。

在分析了闲鱼IOS工程打包过程后,我们将耗时锁定在两个阶段:Pod操作和XCode编译。打包速度优化也将分为两个阶段进行:

Pod操作加速

Pod install/update主要的工作是读取Podfile,进行依赖版本控制和冲突解决,并生成Pod工程。生成的相关文件存储在Pods目录和Pods.xcodeproj中。当切换回之前分支时,Podfile经常是不会发生变化的,因此重新生成pod工程实属浪费。

经过测试,如果我们将这些中间文件保存起来,多次切换分支后,这些中间文件仍然能够还原之前的Pod工程,从而避免切分支后重新生成Pod工程的步骤,省去10分钟左右的开销。

XCode编译速度优化

对于XCode编译速度优化,网上有很多方案,大致可以分为三类:

  • Cocopods依赖编译加速:

比如cocoapods-packager,它可以将pod依赖打包成static library,IOS工程以静态库的形式引入pod依赖,省去重复编译的时间。但是这个方案也存在一些问题;私有库和第三方库更新很麻烦,每次都需要重新打包静态库,并上传到代码仓库;且很难调试源码

  • 分布式编译:比如distcc

分布式编译的原理是将需要编译的文件分散到编译集群的其他机器上编译,然后将编译好的二进制文件传回。本地编译器再将这些二进制文件链接在一起。分布式编译对于大工程提速明显,但是对于小工程,反而会拖累编译速度。

  • 缓存编译的中间结果:CCache,BUCK

更为广泛的加速方案是缓存编译的中间结果,比如CCache,Buck等,这些方案,网上有详细的资料,不再一一赘述。但是引入这些方案,都需要对目前的IOS工程进行改造,甚至需要改变用户的开发习惯,因此不符合我们的要求。但是缓存中间编译结果的方案给我们提供了一些启发:

我们知道XCode是具有增量编译能力的,这其实也是利用了上一次编译的中间产物,本地再次编译的时候,如果发现文件没有变化,则忽略这个文件,如果源码文件时间戳更新了,那么就重新编译这个文件,因为每次变化的源码都是少量的,这样就可以达到加快编译速度的目的。对于闲鱼IOS工程,如果我们在切分支之前保存当前IOS分支编译的中间产物,然后在切换回当前分支的时候,恢复之前保存的中间产物,那么是不是就可以触发XCode增量编译了呢?事实确实如此。

具体方案:

  1. 在切分之前缓存当前分支的Pods Project, Flutter Project以及编译的中间产物,Podfile.lock, linkmap等等相关文件。
  2. 切换分支
  3. 恢复新分支之前缓存的中间产物
  4. 重新打包IOS APP。
    通过这两步优化,我们将闲鱼IOS工程切分支后的打包时间由原来的30-40分钟降低到五分钟以内,效率提升近六倍。

总结

IOS环境搭建中复杂和耗时的步骤,通过docker镜像和缓存优化后,搭建的难度大大降低,IOS新手也基本可以在三小时内搞定
同时,通过缓存和复用打包过程产生的中间产物,切换分支后的打包耗时控制在五分钟内,降低为原来的六分之一,提升了开发效率。


https://mp.weixin.qq.com/s/R2XYOczL4-qftewWM7VKNg

iOS 性能优化:优化 App 启动速度

苹果是一家特别注重用户体验的公司,过去几年一直在优化 App 的启动时间,特别是去年的 WWDC 2019 keynote[1] 上提到,在过去一年苹果开发团队对启动时间提升了 200%

发布于:2天以前  |  23次阅读  |  详细内容 »

让你的应用远离越狱:iOS 14 App Attest 防护功能

当越狱在 iOS 设备第一次流行起来时,iOS 开发人员会尝试各种方法来保护自己的应用程序,以让应用免受盗版等不确定因素的困扰。有许多方法可以做到这一点,包括检查 Cydia 是否存在、检测应用程序是否可读取自身沙箱之外的文件、在检测到调试器时让应用程序崩溃等等。

发布于:9天以前  |  50次阅读  |  详细内容 »

探秘 iOS 14 的 WidgetKit

Widget Extension 提供了 small, medium, large 三个尺寸,不同尺寸可以展示不同的数据、不同的界面,开发者也可以锁定自己APP的 Widget 只有某类尺寸,相同的widget也能重复添加。作为添加在主屏幕上的控件,苹果用了 “At a glance” 来形容 widget ,所以 widget extension 是无法交互的,它能做的只有展示一些信息与点击两个作用,点击后就会引导至app,同时为了性能与耗电量的考虑,Widget extension 也不能展示视频和动态图像。

发布于:11天以前  |  75次阅读  |  详细内容 »

iOS14 Widget 万字指北,先人一步获得顶级流量

2020 年 6 月 22 日,苹果召开了第一次线上的开发者大会 - WWDC20。这次发布会上宣布了ARM架构Mac芯片(拳打Intel)、iOS 14 ATT(脚踢Facebook),可谓是一次载入史册(我是爸爸)的发布会了,当然还发布了被称为下一个顶级流量入口的Widget。踩着八月的尾巴,本次我们就来探究一下Widget。本文会从Widget初窥和Widget开发两个维度和章节来探究一下Widget, 其中初窥章节会带您简单的了解一下Widget,适合应用决策者阅读; 开发章节会带着您一步一步的完成设计开发Widget,适合程序员阅读。

发布于:11天以前  |  80次阅读  |  详细内容 »

OCRunner:完全体的iOS热修复方案

为了能够实现一篇文章的思路:Objective-C源码 -> 二进制补丁文件 ->热更新(具体是哪篇我忘了)。当时刚好开始了oc2mango翻译器的漫漫长路(顺带为了学习编译原理,嘻嘻),等基本完成以后,就开始肝OCRunner:完全兼容struct,enum,系统C函数调用,魔改libffi,生成补丁文件等,尽可能兼容Objective-C,为了做一个直接运行OC的快乐人。

发布于:11天以前  |  74次阅读  |  详细内容 »

iOS APP图标版本化

在我们的项目开发过程中,需要频繁打包给测试人员去测试,有时候我们都不知道测试机上安装的版本是否是最新的,这样会造成很多不必要的麻烦和成本。因此我们需要将buildNumber以水印的方式打在APPIcon上,可以很直观的知道当前是哪一个版本。

发布于:11天以前  |  71次阅读  |  详细内容 »

百度App iOS工程化实践: EasyBox破冰之旅

百度App从单一的搜索工具发展到今天以搜索和Feed流为双引擎的综合性内容消费服务平台,其复杂程度已然不可同日而语矣。 作为一个日活过亿的超级App,业务规模庞大,相关技术人员超过千人,客户端支持主流的移动技术,涉及近百业务方,技术形态复杂,各种组件近三百个,代码百万量级,由此带来的工程化问题是技术团队的一个极大挑战。

发布于:11天以前  |  80次阅读  |  详细内容 »

百度APP iOS暗黑模式适配的完美解决方案

在2019WWDC的开场演讲中,苹果公布了即将推出的iOS13 DarkMode的新特性。此新特性不仅可以在夜晚保护视力,而且对于使用OLED的最新一代设备而言,也可以帮助用户节省电量消耗。不过此特性只支持iOS13以上的系统,为了给全系统所有用户最好的体验,研发出了一套皮肤主题框架,不仅可以全系统支持DarkMode,还可以扩展多套皮肤主题;

发布于:11天以前  |  75次阅读  |  详细内容 »

iOS 14 - 使用 PHPicker 选择照片和视频

绝大多数的 App 都要和相册打交道,选择照片或者视频,要么用来发个朋友圈,要么是放到什么地方做个背景。从 AssertLibrary 到 Photos 框架,苹果已经在多年之前就给相册相关的 API 做过一次大升级了。

发布于:13天以前  |  97次阅读  |  详细内容 »

iOS开发体验优化方案

随着Flutter等跨端框架的出现,业务开发同学经常需要在Android/iOS上跨端进行业务开发,问题定位等。新的不熟悉的环境的搭建总会遇到各种各样的问题,导致搭建失败,特别是iOS开发环境,是最复杂的,不仅环境搭建繁琐,而且切分支后的打包速度很慢,所以我们设计实现了两个工具,用于优化闲鱼iOS开发体验。

发布于:25天以前  |  126次阅读  |  详细内容 »

iOS14:再见了,“流氓”APP!

最近和苹果有关的重大消息可能就是从8月1日开始,AppStore中国区火速下架未获版号的游戏APP,数量超过30000款,之前小智就和大家说过,这未必不是一件好事,众多低质和“流氓”APP将被最大限度隔绝在iOS系统之外。

发布于:28天以前  |  175次阅读  |  详细内容 »

iOS 14 苹果对 Objective-C Runtime 的优化

Objective-C 是一门古老的语言,诞生于 1984 年,跟随 Apple 一路浮沉,见证了乔布斯创建了 NeXT,也见证了乔布斯重回 Apple 重创辉煌,它用它特立独行的语法,堆砌了 UIKit,AppKit, Foundation 等一个个基石,时间来到 2020 年,面对汹涌的"后浪" Swift,"老前辈" Objective-C 也在发挥着自己的余热,即使面对越来越多阵地失守,唯有“老兵不死,只会慢慢凋亡"才能体现的悲壮。今年,Apple 给 Objective-C Runtime 带来了新的优化,接下来,让我们深入理解这些变化。

发布于:1月以前  |  275次阅读  |  详细内容 »

iOS14 隐私适配及部分解决方案

在刚刚结束的线上 WWDC 2020 发布会上苹果向我们展示了新的 iOS14 系统。iOS14 的适配,很重要的一环就集中在用户隐私和安全方面。 在 iOS13 及以前,当用户首次访问应用程序时,会被要求开放大量权限,比如相册、定位、联系人,实际上该应用可能仅仅需要一个选择图片功能,却被要求开放整个照片库的权限,这确实是不合理的。对于相册,在 iOS14 中引入了 “LimitedPhotos Library” 的概念,用户可以授予应用访问其一部分的照片,对于应用来说,仅能读取到用户选择让应用来读取的照片,让我们看到了 Apple 对于用户隐私的尊重。这仅仅是一部分,在iOS14 中,可以看到诸多类似的保护用户隐私的措施,也需要我们升级适配。 最近在调研 iOS14的适配方案,本文主要分享一下 iOS14 上对于隐私授权的变更和部分适配方案,欢迎补充指正。

发布于:2月以前  |  323次阅读  |  详细内容 »

Metal新特性:大幅度提升iOS端性能

Metal 是一个和 OpenGL ES 类似的面向底层的图形编程接口,通过使用相关的 api 可以直接操作 GPU ,最早在 2014 年的 WWDC 的时候发布。Metal 是 iOS 平台独有的,意味着它不能像 OpenGL ES 那样支持跨平台,但是它能最大的挖掘苹果移动设备的 GPU 能力,进行复杂的运算,像 Unity 等游戏引擎都通过 Metal 对 3D 能力进行了优化, App Store 还有相应的运用 Metal 技术的游戏专题。 闲鱼团队是比较早在客户端侧选择Flutter方案的技术团队,当前的闲鱼工程里也是一个较为复杂的Native-Flutter混合工程。作为一个2C的应用,性能和用户体验一直是闲鱼技术团队在开发中比较关注的点。而Metal这样的直接操作GPU的底层接口无疑会给闲鱼技术团队突破性能瓶颈提供一些新的思路。 下面会详细阐述一下这次大会Metal相关的新特性,以及对于闲鱼技术和整个淘系技术来说,这些新特性带来了哪些技术启发与思考。

发布于:2月以前  |  284次阅读  |  详细内容 »

最多阅读

快速配置 Sign In with Apple 1年以前  |  3176次阅读
给数组NSMutableArray排序 1年以前  |  2325次阅读
开篇 关于iOS越狱开发 1年以前  |  2322次阅读
APP适配iOS11 1年以前  |  2245次阅读
在越狱的iPhone设置上使用lldb调试 1年以前  |  2227次阅读
UITableViewCell高亮效果实现 1年以前  |  2159次阅读
App Store 审核指南[2017年最新版本] 1年以前  |  2075次阅读
使用 GPUImage 实现一个简单相机 1年以前  |  2040次阅读
所有iPhone设备尺寸汇总 1年以前  |  2011次阅读
关于Xcode不能打印崩溃日志 1年以前  |  1930次阅读
使用ssh访问越狱iPhone的两种方式 1年以前  |  1926次阅读
使用ssh 访问越狱iPhone的两种方式 1年以前  |  1794次阅读
UIDevice的简单使用 1年以前  |  1657次阅读
为对象添加一个释放时触发的block 1年以前  |  1620次阅读
使用最高权限操作iPhone手机 1年以前  |  1561次阅读