如何让 Xcode 在读写上提速100倍?

上个月参加了一场西雅图当地的线下 iOS 开发者聚会。Jeff Szuhay 作为一个有20+年开发经验的资深程序员,跟我讲了一套提高 iOS 开发效率的方法。相比于其他程序员在 App 启动时间、架构优化方面的经验,老爷子 Jeff 的优化基于硬件层面,匠心独运,极客风十足。以下是他的经验分享和我个人的实测。

问题来源

我们都知道 Xcode 在运行或编译时,会有大量的读写操作。例如从硬盘中调用图片,我们会这么操作:

let image = UIImage(named: "imageName")

这时候 Xcode 就会去电脑的硬盘中去找到图片,完成读写操作。类似的操作还有存取文件等等。如果这类读取数量比较少,那么无伤大雅,但是一旦多起来,尤其是大项目在后期产生了大量的 DerivedData 存在硬盘上,Xcode 在编译时就会花大量时间去硬盘(Disk)上完成读写这些数据的操作。更不幸的是有时候还会遇到硬盘故障等问题。

解决思路

正所谓“哪里需要优化,哪里就需要程序员”,Jeff 在这个时候作为一名白衣骑士登场了。多年的计算机研究让他对整个计算机架构非常熟悉。下图是他展示的计算机结构简图。

计算机结构简图

此图简洁明了得说明了计算机的基本架构。左上角是计算机的大脑,CPU,负责核心计算和处理工作;右上角是内存(RAM),用来运行程序并与 CPU 进行数据交流;中间的线是总线,负责各个模块之间传递信息和信号;图下侧是基本的 System IO。

再回来看我们的问题:Xcode 现在是在 RAM 中运行,然后到 Storage 中读写数据,数据接着再传回 RAM。这种方式有两个瓶颈:

  • Storage 速度很慢。即使是最先进的 SSD,其速度也比 RAM 慢了400倍。也就是无论你怎么在软件层优化,其速度也无法突破 SSD 的瓶颈;
  • 数据要不停的在各个模块之间传递。传递过程中亦有延时和无谓的时间消耗。

针对以上两个瓶颈,Jeff 认为,如果我们可以让所有的读写操作都在内存(RAM)中完成,那么必然能大幅提高 Xcode 的工作效率。问题是,怎么实现?

实现方法

方法的思路很简单,大概可以分两步:

  1. 配置 RAM。在内存中专门开出一块让 Xcode 使用。
  2. 连接 Xcode。让 Xcode 连接到我们开辟出来的专属内存空间。

下面就是见证奇迹的时刻。

第一步, 创建 .sh 文件。代码如下。

#!/bin/bash
// 设置 ram disk 的名称
RAMDISK=”ramdisk”

// 设置 ram disk 的大小,这里是 1024 MB
SIZE=1024  

// 分配给 ramdisk 相应大小的空间
diskutil erasevolume HFS+ $RAMDISK `hdiutil attach -nomount ram://$[SIZE*2048]` 

// 打开元数据索引,如果你使用 Xcode 内部的调试工具这是必须的。因为调试工具使用元数据索引来查询符号连接
mdutil -i on /Volumes/$RAMDISK

第二步, 运行 .sh 文件。在命令行中敲下。

之后你会发现你会多出一个叫 ramdisk 的内存空间,有大概 1 GB 大小。

第三步,连接 Xcode。Xcode -> Preferences -> Locations -> Locations Tab,配置 DerivedData。

Advanced... 也要配置成下图所示

以上就是全部步骤。这时候你就可以享受飞一般的开发了。现在 Project 中所有文件都在内存中,相比于 SSD,理论上是要快上一个数量级。

注意事项

  • 合理分配内存空间。我这里分配了 1GB 的内存当硬盘使,是因为我电脑本身有 16GB 内存空间。假如你电脑内存只有 4GB,我不建议你使用这个方法,或者建议只分配 256M 空间给 Xcode。总之,注意内存不足或溢出的情况。

  • 只把 DerivedData 放在 Ram Disk 中。为了极限速度,你当然可以把 App 相关所有的文件都放在内存空间中。但是要知道,我们创造的 Ram Disk 本质是内存,当关机或重启的时候,在 Ram Disk 中的数据是会丢失的。而 DerivedData 是可以重新生成的,所以放在 Ram Disk 中可以最大限度的提高 Xcode 开发中的读取速度,且十分安全。

参考

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容