标签: macbook

本文首发于 EE Times China，因为面包板 blog 很久没更新，所以随便更新一下... 苹果在发布M1版MacBook Air的时候说，M1芯片的CPU相比上一代MacBook Air提速最高3.5倍，GPU图形性能最高提升5倍。这俩数字在现如今半导体行业算十分惊悚吧？这组“对比”得抛开一个事实，那就是苹果对比的上一代低配Macbook，所用处理器不仅与Intel最新的处理器隔了2代，而且对比项目也比较诡异... 当然，我们需要承认M1芯片在超薄笔记本领域的确很彪悍。但与同代CPU（11代Intel酷睿/AMD Ryzen 4000系列）相较（而不是“上一代MacBook”），3.5倍、5倍这种数字就显得相当离谱了。 有关M1是如何彪悍的，此前我们已经 撰文详细探讨过 。M1的一大杀器也在于芯片之上的GPU图形算力。从硬件堆料情况来看，M1的GPU在同功耗的处理器中的确很亮眼。即便我们不清楚苹果GPU的微架构细节，从die size却也是可以管中一窥的。 只不过苹果GPU的堆料，是否带来对等的实际表现，其实是个挺值得探究的话题。这其实也连带相关于前一阵苹果发布的M1 Pro/Max——作为规模化扩展，这两颗更大的芯片延续M1的表现，并探索更高的性能上限也是必然。M1 Pro/Max的一大升级点就在GPU上，GPU也应该是很多人关注的话题。 我们手头有一台2021款华为Matebook X Pro（酷睿i7-1165G7 2.8GHz，16GB RAM，512GB SSD），和一台M1版MacBook Air（7核GPU的M1，16GB RAM，256GB SSD）。这两者的价格也比较接近。以此来分析、探讨苹果GPU也是个不错的契机。 值得一提的是，近3年Intel酷睿处理器的核显性能也是实现了两级跳的。主要是8代→10代，以及10代→11代这两次升级，大约也是市场竞争加剧的体现。尤其是11代酷睿，Xe-LP新架构核显在满载情况下可实现相比10代酷睿核显近2.5倍性能提升。这在Intel隔代产品中的变化还是相当之大的。 如果要看GPU堆料可达成的绝对性能，3DMark Wild Life Extreme是个不错的选择，毕竟也这是目前为数不多能跨平台、尽可能发挥双方效率、单纯考察图形算力的测试。只不过macOS原生不支持3DMark，好在新版macOS可以直接用iOS之下的生态（毕竟目前两个系统的底层堆栈是几乎一致的），所以这里的3DMark Wild Life Extreme来自于iOS。 需要指出的是，前不久我们 评测过Matebook X Pro 2021 。评测文章曾提到过，受制于这款轻薄本保守的功耗与散热策略，以及这台轻薄本在系统设计层面，散热设计做得不够到位。 所以Matebook X Pro大约只发挥了酷睿i7-1165G7七成不到的性能。不过这里对比的Macbook Air也不是M1满血版（满血版有8个GPU核心），算是两者都跛脚情况下来做对比。 从图形绝对算力来看，M1 GPU的确能够显现出很大的优势——这组对比基本在我们的意料中。但这个数字在日常负载中真的有意义吗？这是本文要探讨的重点。 被神化的苹果生态 这些年，苹果生态似乎是被吹爆了的存在。比如说苹果全家桶的协同工作；还有苹果从做芯片到操作系统，以及到做终端，这种生态是行业内大部分玩家都艳羡不已的吧。就连设计芯片可以很大程度上不顾及成本，都是生态掌握在手的优势。 但“生态”在不同维度，探讨的东西是不同的。如果我们将“生态”的范围收缩到macOS操作系统之下的生态，在面向具体应用场景时，苹果最擅长的大概就是多媒体内容、艺术创作了。尤其是对于影像和某些领域的设计工作者。其中摄影师、vlogger们大概是最适配苹果平台的。 所以最初为M1、M1 Pro/Max摇旗呐喊的都是一众up主、vlogger们，甚至有人说8000块钱的MacBook Air可以让售价几万块的Intel处理器版16寸MacBook Pro下班——这话虽然夸张，但反映的其实是苹果以及macOS生态对于这类人的十分适配性。 君不见前不久M1 Max的评测，有人甚至提到其性能比加装了Afterburner加速卡的Mac Pro还要好吗？（Afterburner加速卡主要是用来加速ProRes编解码的，一张售价就1.5万）这表明M1 Max芯片内部对ProRes的编解码加速有专门的硬件单元。这种硬件方案也算是时代主流，就是对特定应用做特定硬件加速，效率比通用处理器高很多。 不过这种程度的针对性也需要付出代价，它对某些特定的负载固然有帮助，但也仅限于特定场景。举个例子，我们这次的其中一项测试是将一段AVC格式（H.264）的10分钟4K 60fps视频，用Handbrake 1.4.2转为HEVC（H.265）。 比较令人惊讶的是，我们这台MacBook Air在此测试场景下用了17分13秒，而Matebook X Pro用时6分52秒。我们一度还认为是否测试参数和变量控制有误，反复检查，并对不同片源做了尝试——毕竟M1的多媒体编解码引擎是出了名的厉害。并且还确认了Handbrake 1.4.2已经支持M1的硬件加速（似乎叫做VideoToolBox）。最终结果差别都不大。感兴趣的同学也可以去试一试，看看我们是否有设置参数上的错误（视频可 点这里下载 ，提取码：83me）。若非我们参数设置有误，或许和Handbrake软件本身对M1的支持程度也有关，这个结果可能是有待商榷的。 这个测试可能是反映了11代酷睿的长板的，即处理器内部对于AVC解码和HEVC编码硬件加速都比较到位。此前Intel在发布11代酷睿的时候也谈到过媒体引擎的加强包括对于10bit AV1、12bit HEVC、E2E压缩（最高4K60 12bit 4:4:4 HEVC，或最高4K60 10bit 4:2:0 AV1）的硬件级支持。 虽然不能就这个例子便说11代酷睿的媒体编解码强于M1，但从这一例可看出的是，在处理器中增加专用硬件单元的收益有多高。10代酷睿及更早的处理器都不曾享受这种待遇，在多媒体视频编解码方面多为通用单元软件方案，效率自然有所不及——所以我们看到更早的MacBook在这样的测试里会显著落败于M1版MacBook。 因为时间关系，我们的测试无法尝试覆盖所有不同格式的编解码，有可能M1会在很多项目胜出，但我们依然能够找到其一个方面的短板。而11代酷睿笔记本事实上对于绝大部分vlogger们的视频编辑工作也是完全能够胜任的。 另外对于严肃工业化流程的视频创作来说，M1的短板也十分明显。大部分vlogger将M1吹得神乎其神，是因为M1有针对性地覆盖了他们的大部分工作场景需求。但一旦视频剪辑变得复杂，情况就没那么简单了。在不做剪辑代理的情况下，M1对于大部分4K H.265视频都能做到流畅预览回放，甚至佳能EOS R5的8K IPB帧间压缩视频流畅回放都没问题。 但还有一些场景就没那么讨好了。比如说佳能的8K All-Intra帧内压缩格式回放（Premiere Pro）相当卡；在Davinci Resolve中也很难做到对佳能的4K/8K H.265格式视频做流畅回放——但搭载独显的Intel版MacBook Pro 16"就没问题。再比如，视频转中间码（Apple ProRes 422）操作，M1也会比采用独显的本子慢很多；还有大部分4K RAW格式文件剪辑和输出，更不要说Ursa 12K ProRes这种超重型负载.... 当然了说这些是在欺负M1作为一颗低压处理器的事实了。但某些媒体宣称M1比10万块的台式机性能还彪悍，本身就有严重的误导性。说这些只是为了表明，不要过度神化M1的视频编辑能力，乃至Arm生态。即便在苹果最擅长的这个生态里，苹果也依然受制于物理定律，和存在短板。 有同学可能会说，规模化扩展的M1 Pro/Max可覆盖的场景大了非常多。对于视频剪辑来说，或许的确如此，但这就涉及到下面要谈的话题了。GPU（和媒体引擎）作为加速器的价值，如果仅限于视频创作，是否意味着它的受众面过窄；以及它在其他场景中效率又如何？ 一个如此偏科的生态，究竟是好还是不好呢？ 你的GPU到底能用来做什么？ 如果苹果单纯将M1系列芯片的肌肉定位于视频创作，这样的生态必然是小众的。事实上，我们原本尝试做Blender测试，却发现Blender Benchmark项目正式版到目前都仍然不支持M1 GPU的硬件加速。（Blender 3.1 Alpha已经开始支持Metal，今年10月苹果加入了Blender基金会，算是Metal生态发展的重要一步） 苹果宣称M1 Max的GPU算力快赶上英伟达Geforce RTX 3080的水平，这一点还得到了很多视频up主的支持和欢呼。事实真的如此吗？或许在视频编解码、后期效果的加速上的确如此，但这一题的考点不应该这么简单。x86生态内的GPU可以做的事情可远不止是视频创作。 要考察GPU的通用计算能力，我们选择的测试工具是Geekbench 5（v5.4.3）的Compute Benchmark测试，以及LuxMark（v3.1，这是个完全基于OpenCL的测试）。得到的结果如下： 注意这两个测试并非对比CPU性能或GPU图形算力，而是基于OpenCL/Vulkan/Metal的GPU通用计算能力（比如Geekbench 5 Compute benchmark明确提到会做图像处理之类的负载）。 从结果来看，虽然M1应用苹果自己的Metal API以后，得分是略高的。但高出来的这部分成绩，和文首3DMark Wild Life Extreme测试的图形性能领先可完全不匹配。此处华为Matebook X Pro 2021的酷睿i7-1165G7，得分就显得相当不错。要知道i7-1165G7的核显GPU堆料可没有M1那么多。 这两项测试或许一定程度可表明，M1 GPU的彪悍在除视频创作之外的应用中，根本就难以体现。这是否可说明苹果macOS生态的偏科，以及在更多通用计算加速场景上的低效呢？ 来源：Linus Tech Tips 同样的情况其实也出现在M1 Pro/Max。我们手上虽然没有新版MacBook Pro 14”/16”，但前不久Linus Tech Tips做了测试，包括Geekbench 5 Compute Benchmark，以及Blender 3.1 Alpha的BMW场景渲染。M1 Max的成绩的确不错，但在加入华硕ROG Zephyrus M16笔记本之后，苹果的M1 Max就完全不够看了。 要知道Zephyrus M16搭载的GPU是GeForce RTX 3060——说好的M1 Max堪比3080呢？3060和3080的算力差别可是相当大的。所以是只有在做视频的时候才堪比吗？（但需要指出，在对存储带宽和容量有高要求的测试场景里，苹果还是有显著优势，此处未列出；另外Blender的测试结果可能与该软件的优化也有很大关系） 从游戏这个应用场景来说 从这个维度来说，苹果的生态究竟是好还是不好？x86阵营这些年的生态积累，并不是M1亮一亮肌肉就可轻易抹除的——即便Rosetta 2的质量和效率是真的非常高。不过因为我们也不做工业生产，到头来无法穷举在更具体的场景里，苹果GPU究竟如何发挥作用。（有人列举过M1目前对工业设计类应用的支持情况，有兴趣的同学可以去搜搜看） 但对寻常用户而言，有一个场景一定是可以说明问题的——游戏。Intel在11代酷睿之上应用最高96EU的Xe核显之后，即便用核显，以前在轻薄本上想都不敢想的游戏作品，现在也能玩了。虽然和高特效、满帧还是无缘，但在降低渲染分辨率、特效之后，能玩终于成为可能了——这一点我们在Matebook X Pro 2021的文章里已经谈到了。 其实从3DMark Wild Life Extreme的测试结果来看，用M1玩游戏，性能应该也很不错才对，但事实情况却没那么简单。先抛开macOS平台的游戏实在少得可怜这一点，我们测试了跨平台（而且目前得到新系统支持，主要是Rosetta 2转译支持）的《全面战争：三国》《古墓丽影：暗影》和《中土世界：暗影魔多》。这几款游戏都可以在蒸汽平台下载到。（要找到内置了benchmark，而且还同时支持Windows和macOS的游戏还真是不那么容易） 结果和3DMark测试成绩也大相径庭。或许测试的样本量还不够大，毕竟macOS平台也有优化非常好的游戏（《古墓丽影：暗影》应该是macOS之上优化不错的3A大作了）。 但这还是能够说明M1高分低能的现状，11代酷睿的Xe核显在规模不及M1的情况下，在部分游戏场景下也能表现得比M1更好。（而且如此前文章谈到的，其实Matebook X Pro并不能发挥96EU Xe的全部性能） 来源：Linus Tech Tips Linus Tech Tips也测了Geforce RTX 3060和M1 Max跑古墓丽影的成绩，结果大致类似。说好的堪比3080在游戏场景下也是完全失效的。 这一点理论上不是芯片堆料的锅，而是系统、中间件乃至生态的锅。很多苹果用户一边说苹果生态如何如何优秀，一边又在说macOS并不适合用来玩游戏，仿佛游戏生态就不是生态一样。x86这一侧的游戏支持之多样，原本就是其生态优势之一，却被很多苹果用户认为不值一提，这就是对“生态”一词的双标。（至于说iOS生态下的游戏，在macOS上玩起来大部分都相当灾难） 在M1芯片问世以后，有两个知名的页面上线，一是“ Is Apple Silicon Ready ”，一是“ Mac M1 Games: Native & Rosetta 2 supported games ”。这两个页面应该可以从某个程度体现Apple Silicon生态构建进度。或许对视频创作者而言，其生态构建神速，但对更多领域而言macOS仍然是那个macOS。 其实对游戏和图形计算而言，另一个能够从硬件层面体现生态缺失的是M1版MacBook笔记本不支持外接eGPU。从理论上来说，M1支持Thunderbolt 3，应当可以接外置GPU才对。这也是11代酷睿芯片原生支持Thunderbolt之后，很多笔记本通过外接高性能eGPU，可作为移动工作站的基础——效果甚至还超乎很多人的想象。 但目前macOS似乎还没有做这方面的支持（主要应当是驱动支持方面的问题）。基于M1 Pro/Max芯片的MacBook还需要市场，外接eGPU这方面的支持大概率以后也不会到来。M1的性能也因此受限于芯片本身。 诚然M1及M1 Pro/Max是十分优秀的芯片，在某些特定领域表现出了无与伦比的性能和效率；以及苹果在Mac和对应芯片的策略上，或许只瞄准了现有目标用户群市场；从这个角度来说，其GPU的“高算力”是没什么问题的。但若论GPU生态，或者说GPU究竟能用来做什么、以及通用计算的效率问题，x86这边就强上太多了。华为Matebook X Pro的11代酷睿Xe核显只是一个例子。 其实这次我们也测了不少能够体现日常用户体验的高层级测试。苹果的确在能效方面有着很出色的表现，致MacBook Air续航非常好。但除此之外的日常使用体验，包括办公、作图、剪视频，都无法对11代酷睿超极本构成什么优势。何况在系统层面，Matebook Pro X这款本子还有超窄边框、3:2宽高比屏幕之类的体验优势。这就不是本文要探讨的重点了。 另外谈到生态，不仅华为在自家笔记本、手机上 推分布式软总线生态 ，把笔记本和手机串联起来；微软也在Windows 11中加入了对Android应用的支持。似乎华为和Intel在实现把Android应用带到PC上也进行了合作，即跨端应用呈现。这好像也是现在Android和Windows生态的大趋势，很多生态内的参与者都在做这件事。这也算是对苹果全家桶生态发展的某种应对之策吧。 分工合作的方式仍然可以组建起生态，即便或许效率不及某一家厂商自己构建封闭生态。但单独构建生态不仅需要强大的市场号召力，凭一己之力扮演多个角色，而且生态更容易偏于一隅，难得百花齐放的发展。这本身就在限制苹果作为芯片制造商这一角色的能力边界。 下篇我们来谈谈如果给M1版MacBook Air装上Windows on Arm，情况又会怎么样…

Max Tech 最近做了一期视频，题为 Why Apple's M1X Macs Don't Need 64GB of RAM . 其实一定程度是为了解答，M1 版的 Mac 在内存容量需求上是不是和普通 PC 有什么差异。眼看苹果针对 MacBook 主推的还是 8GB RAM，而且是不是 iMac 24" 也没有 32GB RAM 选项？这问题就感觉很有趣。 此前关注这一问题也挺久了，貌似始终没有看到有说服力的答法：只看到国内某个奇特的自媒体宏论说 M1 版 MacBook 的 8GB 就相当于别家电脑的 16GB RAM 这种没给出论据的说法。 毕竟就直觉来看，存储介质一个萝卜一个坑，同一份数据不会因为处理器的指令集不同或者操作系统差异，就会有大小上的区别。而且即便内存延迟、带宽不同，容量大小依然是客观存在：两个瓶子的出水口口径不同，流量自然有差异，但瓶子的容量并不会因为流量差异而成为某个相对值。不过系统性能层面倒的确可能形成差异，比如内存压缩、操作系统、软件对内存的利用效率等。 事实上 Max Tech 也并不是什么专业和客观的媒体，这家 youtuber 此前的“高端”言论也不少。不过这里总结下他们这期的内容，可作为 M1 版 MacBook 内存容量问题的相关参考，虽然也存在问题就是了。而且有一点必须要说，就是大量 Youtuber 和 up 主判断某电脑好不好用，基本就是看看剪片子流畅与否，这种具有偏向性的应用场景并不代表普罗大众。但这期内容仍然具有一定的参考性，期望给各位抛砖引玉吧（还是第一次说别人的东西是抛砖…）。 1.软件优化相关 Max Tech 这部分的观点是说，糟糕的软件优化对于 4K 视频剪辑绝对是悲剧，内存再大也没用。尤其是将 Premiere Pro 和 Final Cut Pro 做比较，即便 Premiere Pro 用在更大的内存、更快的 SSD 硬件平台上，针对相同片源的输出速度上也可能完全比不上 Final Cut Pro，而且可能差距甚大。这就是软件的威力了。 而且此前 Max Tech 制作过一期“视频编辑最佳容量 RAM”的视频，发现对 Premiere Pro 而言，内存容量到一定程度后，对于视频输出的时间就已经没有帮助了。而到了近代，macOS 和 Windows 操作系统层面本身也有编辑视频上的效率差异。 他们还特别提到 1 年前，用 AMD Threadripper （3970X，32 核）+ Nvidia Geforce RTX 2080 Ti + PCIe Gen 4 SSD 搭了一台 PC；然后拿它跟 Mac Pro （2019 款，15000 美元）作了对比。单纯从通用和图形计算之类的性能跑分来看，前者是碾压后者的。但如果用来做视频的话，包括 4K 视频剪辑、HEVC 转码等，Mac Pro 仍然更快（双方都用 Premiere Pro 的情况下）……此处主要是为了说明 macOS 效率明显更好… Max Tech 对于“日常工作”的定义估计就是剪片子，所以我觉得这部分内容并不具有代表性，更多数据就不给了，大家有兴趣可以去看看。 不过 Final Cut Pro 的针对性优化，以及以此为代表的软件生态，的确可以作为某种内存利用率对比参照。对系统比较懂的同学可以谈谈。 2. Apple Silicon 的内存带宽与延迟优势 M1 平台有个特性叫 UMA，unified memory architecture 统一内存架构。这一点应该也是众所周知的了。M1 这颗芯片把内存直接封装在了计算 die 的旁边。 传统的即便配了核显的处理器（典型的比如 Intel 的酷睿处理器），虽然 GPU 和 CPU 构成同一个 SoC，但 CPU 和 GPU 的内存仍然是两个不同的空间，因为 CPU 和 GPU 对内存的使用方式其实是不同的。两种的数据交换需要在不同空间之间做复制。 而 UMA 针对 CPU、GPU 不再分配专用区域，内存是同时分配给两者的，不需要复制操作。这种提高内存利用率的方法，效率、延迟都提高了。 这可能对内存的延迟、吞吐都提出了更高的要求（因为这两种处理器对内存的需求是不一样的）。至于具体怎么实现的，我不清楚，迟点再去研究一下。 此外，针对 M1 搭配内存延迟和带宽的问题，Max Tech 援引了两个东西。其一是 XDA 上有个用户的发言，如上图所示，具体的各位高人来辨别下真假吧。“They also managed in a cheap platform (mac mini = $700) get 4266MHz memory working with about half the latency of any x86-64 I’ve seen. The mac mini can manage a random cacheline (assuming a relatively TLB friendly pattern) of around 30-33ns.” “Maybe the usual Intel Core i7/i9 or Ryzen 5000 look rather quaint with their 60ns or higher memory latencies.” Max Tech 的评论则提到“Apple’s Unified Memory is so fast, tasks use less RAM and when RAM needs to be used it can clear out much faster as well.” 另一份援引的数据来自 AnandTech，这个是 AnandTech 很早之前做的 M1 的内存延迟测试 。M1 的内存总位宽是 128bit，8 x16bit 通道，LPDDR4X 4266，峰值带宽 68.25GB/s。 带宽部分相关的应用实测，Max Tech 用的是 Lightroom Classic 做 4200 万像素照片输出速度可以秒杀 2020 款 5K iMac，包括 16GB RAM 版。 AnandTech 另外也提到每颗 Firestorm 大核心读取内存带宽就能大约达到 58GB/s，写入则有 33-36GB/s。“最重要的是，取决于是标量还是矢量指令，内存复制带宽大约为 60-62GB/s。单颗 Firestorm 核心能够几乎完整地利用内存控制器，这一点非常惊人，我们以前也从未见过这样的设计。” （参考 AnandTech 针对 Tiger Lake-U 做存储性能测试时提到的 ，More importantly, memory copies between cache lines and memory read-writes within a cache line have respectively improved from 14.8GB/s and 28GB/s to 20GB/s and 34.5GB/s. 仅供参考，对比对象各位可以点开链接去看。这份数据是 Tiger Lake-U 的，好像 Tiger Lake-H45 是另一回事……） 上面这张图，据说是 64GB 版的 16 寸 MacBook Pro，和 8GB 版的 M1 MacBook Air，在 Lightroom Classic 上的输出性能比较。感觉这个数据还是挺有趣。不过仍需考虑今年酷睿处理器 Tiger Lake 其实在内存带宽上相比前代还是有变化。 而上图中的 16 寸 MacBook Pro 用的处理器是第九代酷睿 Coffee Lake，算是比较老的架构了。具体的各位自己去调查吧，总体应该都不及 M1。另这份对比中的变量过多，不只是内存容量的问题了。 3. GPU 工作方式 另外 Max Tech 特别提到了苹果 GPU 的 TBR 特性。前两周正好 写过一篇文章谈桌面和移动 GPU 的 。一般我们说桌面 GPU 常见 IMR（立即渲染），而移动端 GPU 对功耗和带宽都更敏感，所以无法像桌面 GPU 那样大手大脚做内存的存取操作，所以普遍在用 TBR（基于 Tile 的渲染）结构，也叫分块渲染。就是把画面分成一个 tile 一个 tile 地做渲染，GPU 如果能再配上片上 cache 可以存在 tile 数据，那么就能进一步减少内存的存取操作。 其实苹果 GPU 在架构上延续了 Imagination 的设计。所以论立即-延后这件事，苹果的 GPU 都普遍在用相比 Arm、高通之类更延后的 TBDR（tile-based deferred rendering）结构。有兴趣的可以去看看 Imagination 的 blog 对 TBDR 的解释。从介绍来看，M1 上的 GPU 也是这么搞的。这也属于常规嘛。 这种设计实现的应该是图形计算节约系统带宽。说起来感觉好像有一定的道理？（不过基于 tile 的渲染方式，可能在桌面平台也很早就存在了）不过针对这一部分，Max Tech 又拿 M1 和 Intel 十一代酷睿比视频转码输出，真的也是够了！？又不是比编解码器，数据这里就不给了。 后面 Max Tech 也再度提到了，苹果教育开发者如何降低内存和带宽利用的开发方法。不过上面这张 ppt 的出处我没找到，貌似是图形开发？提及 4K 帧 FP32 image 处理，令其实现带宽上 62% 的缩减，以及 270MB 的 buffer 节省。貌似与统一内存架构也有关系？有兴趣的同学可以去找找这张图出自苹果的哪个开发者视频，看看具体是怎么说的。 4. SSD 交换和其他 当然另一个要提的肯定是采用高速 SSD 来做物理内存不够时的 SWAP 交换。据说丐版的 MacBook Air 一样用了比较顶尖的 SSD（和以前不同？），确保 SSD 读写上的高速，即便从交换页载入也有比较快的速度（据说…）。 有关 SSD 损耗率的问题，这一点我之前看过蛮多视频，基本上是一个在 MacBook 生命周期内不值得用户去多虑的参数，之前应该是被人炒过了。另外未来要应用 PCIe Gen4 的 SSD，还能实现速度的进一步跃升，“所以 64GB RAM 就更没必要了”，而且传言中 M1X 要配的高性能 Mac 可能不会有 64GB RAM 版本。 还有一些，包括 Max Tech 对比了，如果做视频输出，则 32GB 和 64GB 版的 Intel 处理器同款 Mac 在视频输出速度上相差无几。这个对比其实也偏科了，不过可能对很多日常轻量级办公的用户有参考价值。 以上数据均为内容转述，加了一点不成熟的点评和背景内容补充，有兴趣的同学欢迎去看原视频。也欢迎各位喷，主要就 Apple Silicon 配合内存容量的问题，发表更多的见解。 我自己感觉，缺一个控制变量的测试，可以考虑 Intel Tiger Lake 平台，以及 M1 两者，尽量保持相同的其他配置，来看看更多对存储容量相对敏感的测试，比如多开网页，看双方在内存交换前分别打开了多少网页之类的；而不要光比媒体输出这种单一场景。 而且实际上，YouTube 上有一些从事严肃工业化摄影/摄像工作的工作流，可以比较明显地发现 M1 的短板。不过毕竟 M1 只是个低压处理器，这种程度做对比也没什么意义就是了。

实际上，有关 Mac 系列计算机要开始采用 Arm 处理器的传言似乎是从 2010 年就开始的，那会儿苹果也才刚刚开始做 iPhone 的 SoC。这一传言就 10 年过去了，起码今年前不久才更新的 MacBook Air 都还在用 Intel 的处理器。 想起来以苹果的尿性，对自家生态的管控，恨不得从硬件到软件由内到外全部一手包办。这么有洁癖的一家公司，如今有能力自己设计处理器，为何还要受制于 Intel？况且 Mac 设备本身的开发周期，还面临与 Intel 处理器迭代撞期的尴尬，导致 Mac 经常无法用上 Intel 最新的处理器。如果用自家的 A 系列 SoC，岂不是很美的一件事情吗？ 这次的传言看起来格外靠谱，彭博社报道称，2021 年采用 Arm 处理器的 Mac 电脑就要问世了。彭博社线人消息称，Mac 要搭载的处理器将比 iPhone 和 iPad 之上的都更快（好像是废话）。“苹果准备在明年，至少推出一款采用自家芯片的 Mac.”“台积电将会负责制造新款的 Mac 芯片，基于 5nm 制造技术。” “首批 Mac 处理器将有 8 个核心，核心代号 Firestorm，其中有 4 个是节能核心——内部代号 Icestorm。苹果针对未来的 Mac 处理器，还计划探索超过 12 个核心的设计。”值得一提的是，传言中的 Mac 处理器也是以 SoC 的形态出现，其上至少包含了 CPU、GPU。 当年的 iBook，采用 PowerPC G3 处理器 这件事情的可行性当然是有的，只是在具体实施上会遇到不少问题。如果说 macOS 转往 Arm 平台真的那么容易，苹果估计早就干这事儿了。而且事实上，微软这两年正在做这件事情，但在具体的方向上有些小差异。在这篇文章里，我们做一些简单的分享，虽然无法得出结论，也可与各位做探讨。 多插一句，一般来说，我首发在面包板的文章筹备周期比较短，而且相对来说内容更加个人化、娱乐化。与电子工程专辑或者其他平台发布的文章相较，会显得没有那么正式和考究。另外，这篇文章主要参照的是维基百科，我不想去翻以前苹果的开发者文档了——基于维基百科的不可靠性，以下内容可能有部分是存在事实错误的；另外，我也不搞软件和系统工程，所以贻笑大方之处还请海涵。 苹果曾有的两次迁徙经历 苹果的 Mac 产品线与 Intel 的合作是从 2005 年开始的。那一年，Intel 的 CEO 还为苹果站了台，与乔布斯一起。次年的 Mac Pro 就开始正式采用 Intel 处理器（Mac OS X 10.4.4 Tiger）。在此之前，Mac 并不是 x86 平台的拥趸，我记得看电子科技相关杂志，包括当年像台灯一样的 iMac，苹果在宣传词中都提到处理器比同时代的 Intel 奔腾快多少倍之类。 在此之前，苹果就有过两次在指令集平台上转舵的经历，看起来已经是个老手了。至于为什么要换用其他平台，这可能和软硬件更具体的技术问题相关，不过从社会上广为流传的资讯来看，都是因为老平台的效率越来越不济（就好像如今主流观点认为 x86 处理器的效率不如 Arm，虽然我不这么看；很多人认定，Mac 转向 Arm 也算是合情合理）。 从这两次转舵，其实可以大致来看一看，这回若从 x86 转往 Arm，可行性几何？或者苹果从前的转舵经验，是否有足够的参考价值。一般来说，从一个硬件平台转往另一个硬件平台，经常意味着抛弃以前的开发者，以及抛弃以前的用户。因为转往新的硬件平台，总是意味着旧有软件将停止更新，且旧的开发生态彻底终结，未来的新软件也无法安装在旧平台上。当然系统制造商总是会采用一些折中的兼容性方案来实现过渡。而“过渡”的平滑与否，真的就要看厂商的水平。 1994-1996 年前后，苹果的 Mac 电脑从更早摩托罗拉的 68k 系列芯片转往 PowerPC 处理器（参与 PowerPC 联合开发的应该有摩托罗拉、苹果和 IBM）。这个转换过程持续了几年，当时苹果的过渡方案是所谓的 Mac OS Classic（Mac OS Classic 也就是经典 Mac OS，指代了 Mac OS X 之前的 Mac 操作系统），可以同时跑在 68k 和 PowerPC 平台下。有个词叫 fat binary，形容某一种应用，占用更多的存储空间（所以才 fat 吧...），但混合了多种指令集的原生代码支持——也就能够在多种类型的处理器上跑。苹果当时搞的这种 fat binary，就是令开发者将 68k 编译版本和 PowerPC 编译版本打包到同一个执行程序中。 另一方面，当时苹果引入了一种较低层级的模拟方案。系统中有一个 Mac OS nanokernal 内核，这个内核建立在 Macintosh ROM 里面（Macintosh ROM 是最早 Macintosh 电脑中的一个固化在主板上的芯片，用于电脑启动时的初始化）。而这个 ROM 内部有个叫做 Macintosh Toolbox 的东西，类似于 BIOS 这种角色。而 Mac OS nanokernal 为 Toolbox 提供 68k 处理器的模拟环境。 Mac OS nanokernal 在电脑启动时加载，内存里开辟一个 PowerPC 内核空间加载模拟器。随后模拟器继续加载 Toolbox 对系统硬件初始化，随后的操作和 68k 时代基本上一样。这时期 PowerPC 设备的内核，实际上就是运行在 68k 模拟器里的 Toolbox。 nanokernal 的主要工作就是让现有 68k 版本的操作系统跑在新的 PowerPC 硬件下，如此系统普通状态就能跑 68k 代码。在必要的情况下可以转回到 PowerPC 模式下，基于中断处理程序（interrupt handler）实现，并将虚拟内存系统映射到 PowerPC 硬件上。不过维基百科说，这个过程，也可能只是由跑在用户态的模拟器去处理的。 iMac G4，采用 PowerPC G4 处理器 无论如何，这都是个看起来十分简单，而且还非常低效的方案（原生的 PowerPC 性能似乎很难发挥） ；不过好像也很有效，Mac OS nanokernal 的 68k 模拟器也就为旧软件提供了这种低层级的兼容性。当时的模拟器提供的运行环境，和 Macintosh Centris 610（处理器具体型号为摩托罗拉 68LC040）最为接近。 早期版本的 68k 模拟器会解码每一条指令，并立即执行一系列对应的 PowerPC 指令，实现这种模拟。后续的 PCI PowerMac（PCI 总线的 PowerPC）中的动态重编译模拟器（dynamic recompilation）则对性能做了提升：将代码常见的部分，“重编译”为更快的、PowerPC 原生序列——且在本地做了缓存（locally cached）。也就是说这种模拟器能够识别一些 680x0 代码序列，并且直接跑已经缓存过的 PowerPC 代码，也就避免了重新转译。对于一般的开发者来说，这种转换也就显得比较无痛，因为模拟器是自动开始和结束的。 最初的 Mac OS nanokernal 是相当简单的，这就是个单任务系统，把大部分工作交给操作系统 68k 版本的模拟器去跑。有兴趣的同学，可以去了解一下当年的 Mac OS Classic，它似乎还称不上一个现代化的操作系统，连内存保护都没有；上层的应用程序直接跑在 Toolbox 上，除了获取系统提供的功能和资源，还能直接操作硬件和内存。这个版本的 nanokernal 似乎是到 Mac OS 8.5 终结的。 第二版 Mac OS nanokernal 也算是越来越像样了，开始支持多任务多处理器、消息传递，可以算是微内核了；内核存在于受保护的内存空间中，并在用户态下执行设备驱动。这是题外话了。 Mac OS Classic 时代的操作系统和个人电脑还是相当的粗放和不讲究，而且层级结构也比今天要简单得多。而另一方面，其实也不难发现，即便是当年苹果电脑用户基数不多的时代，生态搬迁都需要付出这般代价；每一次平台搬迁，实际上都需要付出代价，由上至下。 还有一点值得一提，后来 Mac OS X（PowerPC 版）内部有个名为 Classic 的环境，这是一个抽象层——绝大部分 Mac OS 9 应用都依托于 Classic 环境跑在 Mac OS X 上。从 10.5 美洲豹系统开始，就已经去掉了 Classic 环境（即更晚的 x86 平台也就不再对 Classic 做出支持）。具体来说，Classic 环境包含了一个 Mac OS 9 系统文件夹，以及一个 New World ROM 文件（前文提到的早期 Macintosh ROM 算是 Old World ROM；而 New World ROM 时期，早期 Macintosh ROM 不复存在，原本的 Toolbox 成为一个文件存在硬盘上）。这里的 Classic 可以认为是 Mac OS X 之下的一个模拟子系统。 从 PowerPC 转往 Intel x86 2005 年，乔布斯表示苹果对于 IBM 的 PowerPC 开发进度非常失望（这集我看过！去年的 Intel 基带事件似乎也是这么演的） ，而 Intel 显然可以满足苹果的需求。当年乔布斯大谈每瓦性能，实际上也就是能效比，这似乎也是如今在舆论上，x86 处理器陷入不利的原因。乔布斯在 WWDC 大会上宣称，Mac OS X 的每个版本都“秘密地”针对 Intel 处理器做了开发和编译。所以现在的 macOS 有没有“秘密地”针对 Arm 做开发和编译？ 当年 Intel 为苹果站台的名场面 这次的兼容性解决方案，是一种名为 Rosetta 的指令解释器，这是一个动态二进制转译器（dynamic binary translator）。苹果在宣传中，把 Rosetta 称作是“the most amazing software you'll never see”。苹果说对于旧版 PowerPC 应用来说，那些重交互、但算力需求比较低的应用，非常适用于 Rosetta（比如文字处理）；而算力要求比较高的（比如 AutoCAD、Photoshop）可能就会悲剧（很像 Windows on Arm？？？）；一些“专业级”的媒体应用，比如 Final Cut Pro、Logic Pro，则完全不支持。 Rosetta 所处的层级比 68k 模拟器要高，是个“用户级”的程序，只能监听和模拟用户级代码。这可能和苹果担心安全问题有关，而且毕竟 Rosetta 推出的时间，操作系统也比 68k 模拟器年代要成熟很多了。所以 Rosetta 不支持的环境和状况有很多，也包括了不支持转译 PowerPC G5 指令。 苹果后来发布的 Xcode，有针对 Intel 与 PowerPC 的 Universal Binary，就跟前文提到的 fat binary 类似——这样一来，当时面对平台迁徙的开发者，在面对 Mac 应用开发时，针对基数也算多的 PowerPC 用户，不会不知该选 PowerPC 还是 x86，因为两个都可以要（微软 WinRT 借鉴对象？）。 不过 Resotta 的确在过渡平滑性上要差一些。针对 Mac OS 平台下不同类型的应用，开发者使用 Rosetta 还是需要做一些基本工作的，比如 Cocoa 应用需要重新编译、检查字节顺序问题；Carbon 应用则要求做小幅调整；而使用 Metrowerks Codewarrior 套装开发的应用则需要做较大程度的修改（Codewarrior 是一个 IDE，这个 IDE 的早期版本就针对 68k 和 PowerPC Macintosh，当年苹果转往 PowerPC 时，CodeWarrior 成为 Mac 实际上的标准开发系统，快速取代了苹果自己的 Macintosh Programmer's Workshop）。 就最终的成果来看，Mac 的这第二次转舵还是很成功的。实际上即便到 2009 年，Mac OS X 10.6 雪豹时期，苹果已经完全不再支持 PowerPC，依然有不少开发者通过 Universal Binary 对这一平台做出后续数年的支持——这还是能够从侧标反映苹果在兼容性方案上的不错表现。 但我觉得，这次的成功主要并不来源于苹果在兼容性工作上的成功，而在于 Mac 转向 x86 本身就是一次从冷门到热门，以及低效向高效的转变，因为 x86 平台原本就相当成功。Intel 这些年起码在桌面 CPU 的效率提升上是独占鳌头的。另外要知道 PC 市场的绝对大头：Windows 就一直在用 x86。 而 Mac 转往 x86，则很大程度上意味着 Mac 设备从此以后就可以名正言顺地安装 Windows 系统了。苹果自 2006 年起引入的 Boot Camp 还对 Windows 的安装做出了原生支持。 也是从这个时候开始，大批量的人在星巴克用 MacBook 装逼（以及运行的却是 Windows 系统）才变得可行。或者说至少买一台 Mac，就不用放弃 Windows——而且同一时间还有大量效率较高的虚拟程序可以跑 Windows 及对应的应用。我觉得无论如何，这都是 x86 平台的 Mac 得以大获成功的原因。 PowerPC 的转变相比，这次的转变有着天然的生态优势。当然，在 x86 成为 Mac 的选择以后，Mac 设备自身的设计变迁，为行业树立标杆也是重要原因，如 2008 年推出的 MacBook Air；另外，现在基于 web 的应用越来越多，很多人对浏览器的依赖已经大过操作系统本身，这让平台选择进一步脱耦。 所以， 我觉得 Mac 在转向 x86 平台时的成功，更多的是时势造就，甚至别家生态使然；亦是苹果在电子科技发展史上的一次识时务之举；且以当年 Mac 的体量，更不存在尾大不掉的问题。 从 x86 转向 Arm？Arm 效率真的高于 x86 吗？ 我们近两年听到最多有关 Mac 要从 x86 转向 Arm 的原因，好像并不是苹果要加大生态掌控力（这是我觉得苹果可能决策转向的最主要原因），而是 x86 处理器的效率比 Arm 差很多——这方面的报道也还不少。就相对直观的消费用户体验来看，这一点似乎还是有足够的论据的。这些年智能手机、平板产品的性能提升速度如此之快，感觉跟 PC 是不是已经差不多了？ 苹果前些年发布 iPad Pro，并将其定位于生产力工具的时候，就不忘在发布会上黑现在的 PC，声称 iPad Pro 所用的 Ax 处理器比市面上 90% 的 PC 还要快。虽然也不知道这种对比是如何产生此等量化数据的。加上还有 GeekBench 这种苹果专用跑分工具（误）助阵，像 A13 这种芯片的跑分成绩比 AMD Ryzen 3850X 还要高；单核平均功耗才 7、8W 的 A12X，单核跑分和 TDP 95W 的 Intel Core i7-8700K 差不多，多核成绩则比 8600K 还要高。 这么说来，Arm 和苹果掌握的黑科技，已经达成体积小如此之多、功耗少如此之多的情况下，性能达成与 x86 平台几乎齐头并进的水准啦？ 我前俩月就听有人在社区大谈 RISC 相比 CISC 有多大优势，并以此得出 iPad 性能为何比如今 PC 强那么多的结论，言下之意是你们根本就不懂指令、现代半导体技术的神速发展。Intel 估计应该被钉在历史的耻辱柱上。 有关 GeekBench 娱乐工具跑分相近的问题，其实 我们必须承认一个大前提 ：当代处理器微架构优化，能用上的技术基本上都用上了，前十几年的发展，什么流水线、分支预测、乱序执行、多级缓存、超线程、时间空间并发之类乱七八糟的，及这些技术本身的反复优化，外加制程工艺进化，CPU 性能总能有“质”的飞跃。但如今， CPU 单核性能提升已经十分缓慢，不仅是制程工艺步进缓慢甚而停滞，还在于能用的优化技术都已经用上了。 当然我们不能排除未来还有什么黑科技出现，但至少就这两年的情况来看，新货已经鲜见了，不似当年某种新技术一出立刻造成轰动。 所以虽然 Zen 2 如此神奇，而且还被我们吹得神乎其神，但实际上其单核性能也就那么回事，拼死了也就比同代 Intel 10nm 的十代酷睿强一丢丢——当然其 CCX 架构让 Zen 2 堆核更容易了，台积电的 7nm 也的确给力。 扯远了，上面这两段是为了表明，Arm 即便作为低功耗领域的主力架构，这些年的发展致其单核心性能可与 x86 比肩也并不稀罕。不过那么大的功耗差距，却可达成相似 GeekBench 跑分又是怎么回事呢？这个问题，我在之前探讨 Surface Pro 时就提到过：不考虑散热系统的跑分成绩都是在耍流氓，尤其是 GeekBench 这种短时跑分测试。 我们知道苹果 Ax 系列 SoC 瞬时突发性能还是比较强的，包括 GPU，但一旦考察持续性能，则会有一个较大幅度的折扣，因为毕竟手机这么小的体积，而且就靠那点被动散热面积，很难做到长时间的性能发挥。有关这个问题可参考我之前写的两篇文章 。我们常戏谑说 GeekBench 是 AppleBench，一方面原因在于其中的某些测试项，在 Ax 系列 CPU 中有专门硬件单元做计算，而 x86 很多时候只能依靠通用计算单元来解决，解题效率会略低（这部分内容各位可以去自行研究，早年比较典型的是 AES 加密单元——A 系列处理器就有专用单元，所以这类项目的跑分成绩可以很高，现在可能有差别）；另一方面就在 GeekBench 整个测试周期很短，那么系统真正的综合性能其实是难以体现的。 知乎上有高人给出了 Arm 是否真的比 x86 更省电的理论分析，有兴趣的可以去看一看 。很多人对 x86 留下高功耗印象的原因，其实是平台（以及使用场景）差异造成的，PC 的处理器 TDP 在设定上就很高，而这种相比移动设备高得多的参考功耗，很大程度上就源于前面我说到的 PC 要求在一个较长时间内持续高性能，而不只是简单的瞬时突发性能。另一方面还在于，Arm 指令集的处理器普遍采用大小核设计，小核心是专用于低功耗场景的（而且这种小核心现在看来似乎也越来越有必要）——而直到前一阵，Intel 才表示准备要搞这种大小核设计。 当然这也是因为 PC 的具体使用场景，以往并没有多少需要像手机那样超低功耗状态的应用，或者这种必要性并不大（虽然现在也逐渐开始有这种需求）；而 Arm 平台的移动设备多用电池做电源，本身也需要对功耗做限制。 所以 x86 能效比低于 Arm 的这种印象，大抵上是两者使用场景的常年差别造成的 。能效比怎么样，要对比的应该是同性能下的功耗情况。恰好 AMD 开始使用台积电的 7nm 工艺，这也给这种对比有了一个基于类似制造工艺下，同性能（而不单纯是同频）下的功耗情况对比的依据。不过这种对比需要考虑的问题还有很多，比如 x86 平台的很多 CPU 还有“睿频”的概念，而 Arm 手机和移动平台 CPU 则没有；两者的流水线长度不同等等；而且前面提到，两者使用场景目前还是有差别，这也是芯片内部专用单元有差异的关键。 苹果 A12 的频率功耗曲线，来源：AnandTech 从相对直观的角度来说，随性能的提升，功耗也在提升，但这两者的关系并不呈线性；意即 如今 Arm 低功耗与性能的关系看起来还挺美好，但如果进一步提升性能，所需付出的功耗代价在达到一个拐点以后，就会出现指数级蹿升的状况 ——在高性能领域，Arm 现有的移动处理器也未必会有什么出色的表现：这其中，苹果并未掌握什么黑科技，Intel 也并不存在多大的过错。（服务器领域和 PC 领域在应用场景上又是不一样的，这里不讨论。） 上面这张图来自 AnandTech ，好像被人援引了无数次。这是苹果 A12 的频率功耗相关曲线。AnandTech 认为苹果做得还是比较出色的，而且在后续几百 MHz 区间内也相对保守。如果说苹果期望再把频率抬高，则按照 A12 的现状来看，很快就可以在 3GHz 附近让功耗彻底达到标压笔记本的水平。 这次的转舵可能有所不同，看看微软 上面这个大段落好像说了不少废话，与本文的主旨关系并不算太大。不过我想表达的是，其实 x86 并不像人们想的那样不堪，Arm 也不像人们想的那么美好。在不考虑散热、功耗的情况下，这两者的性能水平可能正在趋同——这也是 AnandTech 之前评价 A12 接近桌面处理器水平的原因。但就系统和具体应用场景的角度，即便 A12 有这种能力，也不可能发挥到桌面处理器的水准，因为它被功耗与散热限制了。 就性能来看，苹果应该是有能力造出 Intel 同等性能的 PC 处理器的，而且 Intel 如今在半导体制程工艺上有落伍的迹象（Intel 前不久才承认到 2021 年之前，工艺技术都将落后于竞争对手 ）。但在 macOS 的软件生态和兼容性层面，就又要多花一番心思了。这个过程可能仍然需要数年，而且这次的转舵还不同于以往。只不过在过去苹果积累的经验，这会儿似乎还是可以派上用场。 彭博社的报道提到，可能会有部分 Mac 产品将采用 Arm 处理器。 就前期来看，合理的推测是，低性能、低功耗产品线的 MacBook（比如说早前 12 寸的 MacBook）可能会率先采用苹果自己的 Arm 处理器。但如果真的是这样，那么也就意味着，Mac 产品系列将有两种架构、两种平台并存，这对开发者来说应该是个灾难。 苹果大概需要重启过去两次转平台时 fat binary 和 Universal Binary 方案——一人开发，俩平台共享... 实际上在早年 fat binary 时期，把两种编译版本封装到一起，造成的文件尺寸大，在当时是比较敏感的——因为那会儿 PC 的硬盘容量真的很可怜，所以那一时期还涌现出了为了节省硬盘空间，可剥离不需要编译版本的工具。现在这已经不算什么大事儿了。 而就当代来看，苹果实际上有一个更好的参照对象，就是微软。不过微软在计划上看，并不是“转舵”，而是“扩展”，这里我们可以稍微提一提：即 Windows 不仅要在 x86 平台上发展，而且要在 Arm 平台上发展。这个计划从 Windows RT 操作系统时期就出现了，那时微软就搞了一个 Windows Runtime，这个运行时之上搭的应用可以同时支持 x86 和 Arm。当时的 Windows Phone 8.1 其实也用上了 Windows Runtime，所以那会儿微软应用商店的很多 app 都同时支持手机、PC、平板，虽然商店里的应用数量也是少的可怜。 这算是实现微软“伟大”生态 Universal Windows Platform（UWP）的重要组成部分。UWP 本质上就是为所有 Windows 设备，包括 PC、IoT、平板设备之类，或者说所有 Arm、x86 平台的 Windows 设备，提供一个通用的 API。UWP 就是一种建立在 Windows Runtime 之上的应用模型。 Windows Runtime 提供的 API 以类库的形式，为开发者提供 Windows 8 的功能。跑在 Windows Runtime 上的应用实际上是跑在一个沙盒里，需要用户批准才能访问一些关键系统特性及下层的硬件。这个东西当时就可以打通 Windows RT、Windows 8，绝大部分应用部署在微软的应用商店里。早期 Windows Runtime 之上跑的应用被称作 Metro app（好像是因为当时微软还热衷于推 Metro UI，后来叫 modern-style app，应该还会改）。 只不过这东西到现在为止都还不能算是成功，微软的营销话术也堪称灾难，没人知道 Windows RT、on Arm、10S、10X 之类究竟是什么鬼。一般人真的很难搞懂微软这两年究竟在做什么——可见当年乔布斯在给 Mac 转平台，在告诉用户和开发者现在正在发生什么的时候，是多么科学（所以比尔盖茨说乔布斯是超级销售员）。不过在实际的决策上，我觉得微软的摇摆不定、瞻前顾后，才真正令 Windows RT 以及后来的 Windows 10S 都很失败。 微软接下来的一个“伟（zuo）大（si）”计划是 Windows 10X。从外显上来看，Windows 10X 是为双屏设备准备的一个操作系统（比如 Surface Neo 之类还没发布的设备），预计今年下半年才会看到实物。不过我觉得 Windows 10X 的意义远不止此， Windows 10X 支持 Windows Runtime API（这个是肯定的），并且“通过一个原生 container 跑 Win32 应用” 。我没怎么研究过如今 Windows 系统架构状况，但就对旧有 Windows 生态来看，Windows 10X 如果是微软接下来意欲统一 PC 市场的操作系统，则这个决心下的还是比较大的；而且貌似双屏 Windows 设备都是基于 Arm 平台。 谁不想要 Surface Pro X 这么性感的笔记本呢？ 听起来 Windows 10X 在这一点上，和 Windows on Arm 很像（Surface Pro X 用的就是 Windows on Arm），所以我在想 Surface Pro X 将来是不是可以升级到 Windows 10X——反正微软改名部门创下那么多的“丰功伟绩”。 在针对开发者的兼容性问题上，Windows on Arm 平台下的 x86 应用是跑在模拟器上的，一个叫 WOW64 的 x86 模拟器。和前文提到苹果的 Rosetta 有点像，模拟过程就是把 x86 指令块编译成 ARM64 指令，加一些优化。会有服务对转译代码块做缓存，减少指令转译开销。貌似到目前为止，x86-64 应用（也就是传统的 Windows 64 位应用）还无法在 Arm 版 Windows 上面跑，而且某些大型应用的模拟运行比较灾难级，比如 Photoshop。WOW64 也跑在用户态 。 其实突然又有点搞不懂微软将来计划怎么发展，从如今微软的动作来看，好像十分偏向 Arm（和高通），只不过大业未成，生态也暂未见起色，x86 也不想抛弃。不知 Intel 看此情此景是什么心情。毕竟 Windows 作为历史用户基数庞大的操作系统，兼容性的历史包袱远大于苹果的 Mac OS：我没法从技术细节上来探讨谁做得更好，但微软一定比苹果更有难度；何况苹果还有 iOS 这颗大棋子。 如果说苹果要在同一时间针对 Mac 系列产品，既保有 x86 平台（典型如 Mac Pro 这种更新没多久的高性能工作站），又开发 Arm 平台（很可能就是 MacBook），那么对两个平台的同时支持，以及对开发者的友好度，不知能否做到比微软如今的方案更好——因为这次似乎并不是彻底抛弃上一个平台这么简单（毕竟彭博社是说部分 Mac 产品采用 Arm 处理器），也就不能以斩断过往、说抛弃就抛弃这种苹果式的任性方法来做决策（但好似当年 PowerPC 与 x86 在 Mac OS 系统上也共存了起码 5 年）。 Mac 转舵可能会遭遇的问题 一气写下来，感觉篇幅有点过长了，本来还想聊聊苹果自己在 Mac 设备里面搞的 T2 芯片，以及可将 iPad app 轻松移植给 macOS 的 Catalyst 项目——毕竟这俩看起来都很像本次转舵的重要缓冲或预备手段。但再写的话，这文章字数就要破万了，实在是太废纸了。在转换平台的问题上，即便有那么多的困难，自主掌握芯片迭代节奏，以及牢固生态发展，采用自研芯片还是有好处。 其实上面这些算是一个资料汇总，也算是我近期的学习过程吧，以简短的形式汇报给各位。这里最后谈一谈 Mac 如果真的要从 x86 转往 Arm（而不是两者并行发展，毕竟苹果很少做这么二的事情），除了兼容性和技术层面，如上述文字中提到的难度，在实际实施中还会有一些非常现实的问题。 第一就是，可能面临抛弃 Windows 用户的问题，Mac 如果彻底抛弃 x86，则未来的 Mac 设备很可能就不能再安装 Windows 系统了：这个问题我觉得十分严重，或许很多 Mac 用户对于在 Mac 设备上使用 Windows 是非常嗤之以鼻的，但这个选择对很多人来说仍然十分重要。毕竟 Windows 的生产力生态仍然十分完备，某些很偏的应用都只支持 Windows。（现在 Windows 也支持 Arm 了，只是两者的平台还是有差异） 第二是，如果低端 MacBook 产品线开始用 Arm 处理器，那么目前的 iPad Pro 产品定位会显得很尴尬。因为后者就是定位于轻度生产力工具，如果要说生产力，iOS 和 macOS 似乎并非同台竞争的对象。 第三，有个比较实际的问题：Intel 毕竟是个造芯片的公司，可以搞出一大堆不同定位的 SKU，比如什么酷睿 i3、i5、i7；超低压、低压、标压、桌面等等，并且应用到不同售价的 Mac 设备上。苹果即便有能力造芯片，是否能在短时间内，按照体质划分不同 SKU，并且应用到将来更多的 Mac 设备上？如果不能的话，难道真的要 x86 和 Arm 并行发展吗？ x86 那样，是转向一个在桌面市场十分受欢迎和健全的平台；而且如今苹果公司的体量远非 2005 年可比，所以这次转舵的困难程度大约不小。另外，前面花了那么多篇幅谈兼容性问题，针对某些十分细节的点，比如小到 Final Cut Pro X 中的一个插件，即便容易想见 Final Cut Pro X 会第一批支持 Arm 版 macOS，但插件未更新就可以彻底埋葬一部分用户。 具体是什么状况，等到今年的 WWDC 或可一见分晓。最后的最后，Intel 哭泣的时间应该会更长：为什么全世界都针对我？ 参考来源： Apple Aims to Sell Macs With Its Own Chips Starting in 2021 - Bloomberg https://www.bloomberg.com/news/articles/2020-04-23/apple-aims-to-sell-macs-with-its-own-chips-starting-in-2021 小议Mac OS Classic的底层架构与Mac的固件沿革 - 老Mac与MacOS收藏 https://zhuanlan.zhihu.com/p/44934452 Mac OS nanokernel - Wikipedia https://en.wikipedia.org/wiki/Mac_OS_nanokernel Mac 68k emulator - Wikipedia https://en.wikipedia.org/wiki/Mac_68k_emulator Fat binary - Wikipedia https://en.wikipedia.org/wiki/Fat_binary List of macOS components - Wikipedia https://en.wikipedia.org/wiki/List_of_macOS_components#Classic Rosetta (software) - Wikipedia https://en.wikipedia.org/wiki/Rosetta_(software) CodeWarrior - Wikipedia https://en.wikipedia.org/wiki/CodeWarrior 聊聊无风扇的Surface Pro：性能比一般笔记本差多少？ - 面包板 https://mbb.eet-china.com/blog/3893689-413612.html 一场硬仗：华为和高通的GPU差距还有多大？ - EE Times China https://www.eet-china.com/news/202001061219.html 为啥 Arm 架构比 x86 x64 省电？ - 木头龙的回答 https://www.zhihu.com/question/387240856/answer/1186307900 The Apple iPhone 11, 11 Pro & 11 Pro Max Review: Performance, Battery, & Camera Elevated - AnandTech https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4 Intel Says Process Tech to Lag Competitors Until Late 2021, Will Regain Lead with 5nm - Intel https://www.tomshardware.com/news/intel-process-tech-lag-competitors-late-2021-leadership-5nm Windows Runtime - Wikipedia https://en.wikipedia.org/wiki/Windows_Runtime How the Universal Windows Platform relates to Windows Runtime APIs - Microsoft https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide#how-the-universal-windows-platform-relates-to-windows-runtime-apis Windows 10X Developer FAQ - Microsoft https://docs.microsoft.com/en-us/windows/apps/10x/faq WOW64 Implementation Details - Microsoft https://docs.microsoft.com/zh-cn/windows/win32/winprog64/wow64-implementation-details

关注苹果 MacBook Air 产品线的同学应该知道，从前两年开始，MacBook Air 已经换上了 retina 显示屏，设计也改头换面了。不过在产品线布局上，MacBook 系列发生了一些变化：12 寸 MacBook 已经退出人们视野（这个产品系列应该已经开始和 iPad Pro 打架了，所以退出也是必然的），MacBook Air 正式接棒了 12 寸 MacBook 的 fanless 无风扇设计。 说是无风扇设计，其实 MacBook Air 还是有风扇的，只不过这个设计相当奇特——后面我们再谈。但有一个核心资讯是 MacBook Air 用户需要在意的：如今的 MacBook Air 全部采用 Intel 超低压酷睿 Y 系列处理器。注意是超低压，而不是低压 U 系列（MacBook Pro 13" 一直在用低压 U 系列）。也就是说，MacBook Air 已经正式成为 Mac 家族中性能最弱的设备，加上其价格——尤其 2020 款 MacBook Air 起价 7999 元，MacBook Air 成为了 Mac 系列中最低端的一个系列。 这也算是产品布局的一个精准调整了，当年乔布斯从信封里拿出 MacBook Air 之时，这个产品的价格可实在是不菲的，定位绝对不亚于 MacBook Pro。 这篇文章面向轻度技术爱好者，并且具备一定的导购价值，各位可酌情阅读。不想看我乱弹的，可以直接拉到本文最后看结论。 无风扇设计？ 国外很多媒体说 MacBook Air 是 fanless 的，当然我们拆机就知道这个说法是不正确的。MacBook Air 还是在内部配了一枚风扇的。不过实际上，在很多人的理解中，Intel 的超低压 Y 系列处理器，的确可以不配风扇，比如当年的 12 寸 MacBook 就没有风扇。 今年 Intel 超低压酷睿 Y 系列处理器由于首次提升到了四核心，所以 TDP 提至 9W，看起来已经和低压 U 系列的 TDP 15W 非常接近了。TDP 功耗上的差异，也让酷睿 Y 系列和 U 系列在起步的基频（base clock）方面就不大一样，Y 系列普遍的基础频率在 1.x GHz 的程度（现在的基频可认为是在 TDP 功耗下，CPU 全核可长时间坚挺的一个频率）。两者的睿频好像差不多。 这两者更具体的差别，我没有具体去研究，但至少包括 cache 大小差异，以及 I/O 方面的区别：比如就第十代酷睿而言，Y 系列的 PCH 高速 I/O 通道是 14 条，而 U 系列是 16 条；Y 系列核心部分支持的 USB-C 接口数量会略少；还有包括 Y 系列不支持 DDR4（而只支持 LPDDR4x）；至于核显，两者都是 Iris Plus（GT2?），在规模上官方标的都是至多 64 EU，不过不知道在频率方面是否有差别之类。 总之，MacBook Air 现在在用的处理器是一种更省电的方案。TDP 9W 听起来好像的确可以不需要风扇了，人隔壁 iPad Pro 的 A12X 大概 7、8W 的平均功耗就没风扇。当然了，这里咱不说，这个 TDP 本身现在所具备的参考价值可能越来越脱离于其原本热设计功耗的意义，毕竟现在大家都把睿频当基频在看，连什么 cTDP up/down 之类的数据看起来都不靠谱。 来源：iFixit 不过 MacBook Air 从改头换面以来的风扇设计就相当之奇特，上面这张图是 2018 款 MacBook Air 拆开后壳以后的内部结构图。内部左上角位置显然就有风扇，不过你知道 CPU 在哪儿吗？CPU 本尊并不在风扇附近，而在中央那块散热片下面，下图用红框将其标出了。 需要注意的是，从各种拆解来看，CPU 之上并没有一根导热管连接至风扇。那么这枚风扇究竟在给谁降温？迷之风扇！针对这个问题，我查了一些资料，发现网上对此的猜测颇多。YouTube 有一些技术向的 up 主提到，这颗孤独的风扇 "just for ventilation"，它负责带走 MacBook Air 内部主板的整体热量，而且在内外造成气压差，这样内部也会主动“吸入”一些冷风。 Reddit 上面也有一张帖子是专门讨论此事的 ：这张帖子是针对 2019 款的 MacBook Air，表明这种设计后续没有变。这张帖子里有人提到，这种设计可能是依赖于内部的密闭结构，空气流向通路上会带到 CPU 上方的散热片。不过无论如何，这种设计针对 CPU 的散热效率都是比较低的，可能与 MacBook Air 追求极致轻薄有关（但实际上我们后面还会提到，MacBook Air 如今真的不能算薄）。 单就 CPU 而言，这还真的算是 fanless，因为虽然有风扇但却不是针对 CPU 的；所以 CPU 真的仍然可以说是被动散热；或许在超低压处理器范畴内，这种设计是合理的，真的是这样吗？ 与 MacBook Pro 的性能差距 网上已经有部分 up 主，包括上周我在参与 web view 的播客节目时，都谈到了，今年的 MacBook Air 真的十分超值；主要是因为 SSD 最低容量升级到 256GB，内存也换用了 LPDDR4x，存储性能会有较大提升（虽然 MacBook Air 的 SSD 速度一直以来都比 MacBook Pro 慢一截）；另外就是处理器更新到了酷睿十代，除了最低配的酷睿 i3，更高 i5 配置都开始改用四核处理器（所以苹果宣称快 1 倍），核显也明显上了一个台阶。而且，价格更便宜。 就纸面数字来看，我之前甚至还提到，2020 MacBook Air 已经比 2019 MacBook Pro 13" 更牛了。不过当时我并没有意识到，2020 MacBook Air 用的虽然是四核处理器，但却是超低压版的酷睿 Y 系列。而 MacBook Pro 用的是低压酷睿 U 系列（2019 款 MacBook Pro 13" 用的八代酷睿低压 U 系列）。那么除了 TDP 功耗数字差异，这两者到底如今是个什么样的关系呢？ 来源：Max Tech 另外，Max Tech 的拆解已经提到，2020 MacBook Air 仍在沿用以前的模具（chassis），所以上述这种加了个风扇，但不吹 CPU 的设计仍然存在，如上图所示。 Intel 酷睿 Y 系列四核处理器，没风扇能镇压吗？其实从理论上来说问题也不大，被动散热中的典范是 Surface Pro。之前我花了很大的篇幅来探讨无风扇的 Surface Pro 性能如何，结论是无风扇的 Surface Pro 相比同配其他有风扇的超级本，持续性能差距大约有 25% 。即便如此，Surface Pro 的表现依然令人满意，可以认为是被动散热设计中的楷模。而且 Surface Pro 用的还是酷睿 U 系列即低压版的处理器，MacBook Air 用的 Y 系列更不成问题了吧？ 就已公开的情报来看，2020 MacBook Air 最低配的酷睿 i3 处理器具体型号为 Core i3-1000NG4，酷睿 i5 处理器具体型号为 Core i5-1030NG7。从这个型号就不难发现，这并非 Intel 公开在售的版本，“N”应该特别指代这是给苹果的特供版，或者合作开发版之类。具体跟公开版本的 Core i3-1000G4、Core i5-1030G7 有何区别，我们就不知道了。 市面上貌似还没有可参照对比的十代酷睿 Y 系处理器实际性能，所以我们就只能看 2020 MacBook Air 自己的实际表现了。严肃技术向的科技媒体还没有十分严谨的测试数据——NBC 的数据库里面也还没有这几款 CPU 的成绩，这里我捡一些不够可靠的分数，都是 CineBench R20 测试： Luke Miani 给 MacBook Air 酷睿 i3 版（Core i3-1000NG4，双核）的测试得分为 640 分，酷睿 i5 版（Core i5-1030NG7，四核）测试得分大约在 1060 分左右 ；但 Max Tech 针对酷睿 i5 版的测试得分一次是 863 分，一次是 1019 分 ——我猜这可能与设备测试前的运行状态有关（真心是不负责任的 up 主啊！），这里的 863 分很有可能是持续性能成绩，而超过 1000 分的成绩则是在设备温度较低时第一第二轮跑分能够获得的成绩。 毕竟不是什么正经测试，那我们就取个中间值吧：960 分——恰好和一家日本测试站点 PC Watch 给的结果差不多 。上一代的酷睿 i5 版（Core i5-8210Y） MacBook Air 的 CineBench R20 得分为 632 分 。所以粗略估算，2020 MacBook Air 酷睿 i5 版相比上一代的 CPU 性能提升幅度大约是 52%-60%，也算是很给力的成绩了（知乎上貌似有数据说是提升 200%，不知这个数据是怎么来的；另 Geekbench 5 多核测试成绩有将近 80% 的性能提升）。当然我们暂时还没有机会了解多轮测试的持续性能表现。 不过这个成绩相较酷睿低压版 U 系列处理器还是有着相当大的差距，比如 MacBook Pro 13"。这里放上 2019 款 MacBook Pro 13"（Core i5-8279U，八代酷睿低压处理器）以及我自己测试的 Surface Laptop 3（Core i5-1035G7，十代酷睿低压处理器）成绩对照，如上图。 GPU 核显部分其实也是这次提升的一个亮点，尤其酷睿 i5 版用上了满血的 64 EU（不过考虑到 Y 系列超低压处理器的 TDP 限制，我猜其图形性能应该还是会低于 U 系列的低压版）。不过那些 up 主的数据感觉都偏离很大，而且也不标测试工具版本和测试环境。PC Watch 给的数据是，Unigine Valley Benchmark 1.0 测试中，2020 MacBook Air 相比上一代平均帧率提升将近 1 倍——这也基本符合我们对于这次 Iris Plus 提升的认知。在 Max Tech 的 Geekbench 5 Metal 测试中，2020 MacBook Air 相比上一代得分大约有 1.2 倍的提升。 其实针对 GPU，也很想加入 Surface Laptop 3 对照（就能看看同样是满血版 G7，低压版和超低压版上的 Iris Plus 核显有什么差别了），不过这些媒体完全不说测试对象，比如测试 API 是否用的 OpenGL，高画质、抗锯齿与否等，所以我也没法测（而且我的测试也一向那么那么不严谨O_o）。不过从早前笔吧的十代酷睿核显测试来看，GPU 性能提升的确很多，但实际使用却没有这么给力，原因应该是当 CPU 也一同跑起来的时候，CPU 和 GPU 会开始争抢主内存资源，造成数据带宽瓶颈——这在一些需要较多调度 CPU 的游戏中就能体现出来。 这里再多插一句，看到有人对比 Unigine Heaven 测试，2020 MacBook Air 最终平均帧率 8.8 帧，2019 MacBook Pro 13" 平均帧率 10.9 帧。这个数据仅供参考，或与 eDRAM，以及后者 28W TDP 有关。 如果我们 只看 CPU 性能的话，即便和 2019 款 MacBook Pro 13"（中配 Core i5-8279U）比，2020 MacBook Air 都有着比较大的差距，两者 CineBench R20 多核性能差距在 58-65% 左右 。而且由于散热设计上的差异，持续性能理论上还会拉开更大的差距。 说白了， 新款 MacBook Air 在性能上仍然是弱鸡，只不过的确比上一版提升很多 。与竞品比较的话，其性能和 Surface Pro 7 甚至都有较大差距，这两者还都是被动散热（MacBook Air 的“被动”散热打个引号）；而价格其实还差不多。 超低压 CPU 的发热很低吗？ 在之前我们探讨过低压 CPU 的实质以后，我愈发觉得，其实超低压和低压 CPU 的区别，可能本质上也还是比较小的——只在于给了一个人为限制的 TDP，便有了更小的基频。如果不考虑功耗墙和温度墙，那么这两者大概就仅剩 I/O 的那点差别了（未深入考察，纯个人 YY，别当真）。 从 Max Tech 的发热测试来看，在 2020 MacBook Air（Core i5 版）跑 CineBench R20 的时候，四核全开，短时睿频可蹿升至 2.4-2.7GHz，此时的功率大约为 13W（在 Max Tech 刚刚更新的测试中，据说功率可以一度达到 26W，全核在极短时间内达到更高频率 。这还是超低压 CPU 的节奏吗？？？或者苹果的确对其间限制做了改动）；但似乎在极短时间内（具体多久不知道）就撞了温度墙，CPU 核心温度很快蹿升到了 100℃，全核心便降到 1.5GHz 左右。 这个时候如果能有主动散热来努力一把，那么睿频还是可以坚持更长时间的。只不过前面也提到了，MacBook Air 如今的散热设计那么奇特，那个独立的小风扇依靠坚强的毅力来为散热片吹风。 另外，MacBook 轻薄本（主要包括 MacBook Air 和 MacBook Pro 13"）在散热设计上还一直有个传统，即宁可降低频率，也要让风扇保持安静。所以 MacBook 用户应该会发现，风扇是几乎不发出声音的，这大概也算保证体验的一种方案吧。有兴趣的同学可以去看看 Linus Tech Tips 做的一个视频 "Macs are SLOWER than PCs. Here’s why." ，里面提到了 MacBook Pro 在 macOS 系统下这种调节机制的特性（不过 Linus Tech 一直是著名果黑）。 似乎苹果更相信，让风扇尽可能保持低转速，而在一定限度内牺牲性能，是一种可达成体验加成的方式（其实我也这么认为...）。实际上 2020 MacBook Air 的情况也很类似，即 CineBench R20 测试期间，所有核心全开，CPU 核心温度到 100℃ 了，风扇转速也才 4000RPM（全速是 8000RPM）——不过由于这风扇离 CPU 这么远，估计就算转更快、效果也就那样了。 而苹果在 Mac 设备散热上的黑历史，也实在是一言难尽；也包括大尺寸的 MacBook Pro 移动工作站。实际上，苹果在寻找散热设计与极致轻薄间的平衡点时，指针始终在向后者偏移。或许在苹果看来，如果你那么在意性能，为什么不买个台式机呢？好像也有点道理。 OEM 厂商的市场定位把戏 看看，MacBook Air 性能和 MacBook Pro 13" 还是存在实质上的差距的（更不用提屏幕亮度和色域覆盖差别）。所以以更低的价格购买一台 MacBook Air，你并不能获得 MacBook Pro 13" 那样的硬件水准。而且实际上，追求轻薄性的各位不妨去苹果官网看一看 MacBook Pro 13" 与 MacBook Air 在重量和厚度上的差别，这两者不仅最厚处是一样厚的，而且 Pro 只比 Air 稍重了一点点（当然 Air 还有楔形设计）... 在市场策略上，以 Intel 酷睿超低压处理器（Y 系列，MacBook Air）与低压处理器（U 系列，MacBook Pro 13"）拉开性能差距，再加上前者散热上的负优化（误），这两条线的产品不会存在性能上打架的情况。另外，如果今年 MacBook Pro 13"（或 14"）开始采用 AMD Ryzen 4000 处理器，则这种差距还能被进一步拉大。于是，MacBook Air 成为名副其实 Mac 系列产品中性能最差的存在，优势就是价格便宜。 从 OEM 厂商的层面做产品定位的明确差别，还有一例其实是微软。Surface Pro 的酷睿 i5 版不带风扇，而酷睿 i7 版带风扇——原本在低压处理器这个层面上，酷睿 i5 和 i7 的性能差距是相当小的（除了这次核显规模上选择的差别），不过微软在这个散热抉择间，硬生生让 i7 比 i5 性能提了一档，这才是让选择了酷睿 i7 的 Surface Pro 用户真正感觉物有所值的一种方法...（至于 i5，那就当时静音体验吧）花样还真是多。 最后，给出本文的一些推论： 1. 2020 MacBook Air 性能比 2019 MacBook Pro 仍然有着很大差距； 2. 2020 MacBook Air 模具没换，仍然用了 2019 款的设计； 3. 如今 MacBook Air 的散热设计是个悲剧，而且非常奇特（虽然有风扇，但 CPU 依然算是被动散热）； 4. 相比上一代 MacBook Air，2020 MacBook Air 的 CPU（多核）性能提升至少 60%，图形算力提升 100%（实际可能没有）； 5. 导购建议 1：如果你在意性能的话，不要考虑 MacBook Air；如果你在意轻薄性的话，也不要考虑 MacBook Air，因为 MacBook Pro 13" 其实和 MacBook Air 的厚度、重量差不多； 6. 导购建议 2：如果你是旧版 MacBook Air 用户，那么十分推荐升级，因为这次的硬件提升十分给力！ 7. 导购建议 3：不建议购买最低配 Core i3 款 MacBook Air，因为 i3 款仍在使用双核，而多加点钱就能用上四核。 参考来源： Intelligent Performance 10th Gen Intel® Core™ Processors Brief - Intel MacBook Air 13" Retina 2018 Teardown - iFixit New macbook air fan cooling system doesn't make sense - Reddit 聊聊无风扇的Surface Pro：性能比一般笔记本差多少？ - 面包板 The CHEAPEST MacBook is better than ever: Base model 2020 MacBook Air - Luke Miani 2020 MacBook Air Benchmarks & Thermal Throttling Tested! - Max Tech 「MacBook Air 2020」を一足早く開封。前モデルと性能を簡単に比較してみた - PC Watch Intel Core i5-8210Y - Benchmark and Specs - cpu-monkey Macs are SLOWER than PCs. Here’s why. - Linus Tech Tips 2019 vs 2020 MacBook Air - Every Difference Tested! - Max Tech

经过在华强北电子市场排队一个小时，笔者顺利买到了期待已久的乐1，结合之前的NOKIA平板电脑N1，苹果全新MACBOOK，终于集齐了手机、平板、笔记本电脑三种TYPE-C接口设备(能兑换极品装备吗？^_^)。迷你小巧、正反相同、双向可接；可集电源、音频、视频、数据传输于一“口”，这传说中的极品接口，在三款设备上究竟给我们消费者带来了什么呢？笔者对照 USB IF组织发布的USB TYPE-C 标准1.1对三种设备进行了初步测试。   在测试之前，先普及一个基本知识，与USB TYPE-C物理接口相关的标准一共有三个：USB Type-C 1.1, USB PD 2.0, Battery Charging 1.2，如果3个协议全部支持，则可以实现Type-C的所有优势特性。Type-C把设备的角色在供电和数据传输上进行了分离。电能传输上分为SRC（即供电方，例如适配器），SNK（即受电方，例如U盘）。对于既能够承担SRC角色，又能够承担SNK角色的设备，则称为DRP设备(例如笔记本电脑和手机)。在DRP设备中，有一类特别倾向于成为SRC设备的Device，称为Try.SRC设备（例如移动电源）。数据传输角色上，分为DFP(即传统的HOST)和UFP（即传统的Device或者Slave）默认情况下，SRC即为DFP，SNK即为UFP，如果要改变这种默认的搭配，则要使用USB PD 2.0通信协议进行ROLE_SWAP。所有这些角色定义及角色切换，都是通过USB TYPE-C协议中的CC逻辑芯片来实现的。 一、MACBOOK 第一项测试，TYPE-C口CC逻辑测试，通过一根特殊的TYPE-C线，我们把MACBOOK的CC逻辑引脚引了出来，经过示波器测试，上面有50ms的方波存在，证明是TYPE-C标准的DRP设备，即Dual Role Port，既可以用适配器通过这个口给MAC BOOK充电，也可以通过这个口给手机充电。通过苹果原装适配器给MAC BOOK充电时，可以明显的在CC引脚上观测到USB PD的通信波形，通信成功后，供电电压从5V升高到14.5V。 第二项测试，充放电测试。第一步，用任意5V适配器，接上基于乐得瑞LDR6013 TYPE-C接口芯片的充电转接线(同时处理了Type-C协议和BC1.2协议)，都可以顺利的给MACBOOK充电，在电源稳定的情况下，最大充电电流为2.8安培。第二步，用一个C口转A母座转接头，利用MACBOOK给IPHONE6 PLUS充电，非常正常。至此已经说明了MAC BOOK属于DRP设备。第三部，判断MACBOOK是否属于DRP设备中的Try.SRC设备。用基于乐得瑞LDR6013芯片设计的Try.SRC移动电源给MACBOOK充电，100%成功。证明了MACBOOK属于非Try.SRC的DRP设备（如果是Try.SCR遇上Try.SRC则充电方向具有随机性）。 第三项测试，数据传输，用自制的TYPE-C口转A母座转化器，接上IPHONE，数据传输正常，经过查看说明书及网上资料，MACBOOK支持USB3.1 gen1 host，向下兼容USB 3.0及USB2.0. 花絮：测试过程中，C口出现损坏，幸好在7天内，进行了免费的换货，苹果的售后还是相当不错的，可以当天就换到全新的机器。   二、乐1 第一项测试，TYPE-C口CC逻辑测试，经过测试乐1的CC为一个上拉电阻或者一个上拉电流源，无扫描波形。因此，基本确认它属于DFP设备，也即是说，在C协议上，它把自己定义为一个适配器。 第二项测试，充放电测试。第一项测试已经提示我们，乐1是个DFP，为了验证这问题，我们用MACBOOK的原装数据线把乐1和MACBOOK的TYPE-C口相连，神奇的事情发生了，乐1在给MACBOOK充电，好吧，我承认了，乐1确实把自己定义成了一个适配器。它能够给C口的SNK或者DRP设备充电。第二步，我们用MACBOOK原装适配器和原装线给乐1充电，结果是，没反应。那是预料之中的，这相当于把两个适配器连在一起，当然是没有反应了。第三步，用乐得瑞A口转C口的线给乐1充电，接上任意5V适配器，都能够顺利达到1.4A充电电流。说明乐1只能够通过A口转C进行充电，不能够接入到标准的C口适配器。 第三项测试，数据传输测试。第一步，把乐1接上windows电脑，可以顺利的认到一个U盘，与普通的安卓手机没有区别。这表明他可以作为一个USB2.0 Device。 第二步，用一个C口转A母座转接器，把一个U盘接到乐1，可以顺利的读到U盘，并且播放里面的音视频文件，表明乐1可以作为一个USB 2.0 HOST。 花絮：测试过程中发现乐1屏幕上方边缘会偏亮，漏光明显。这个...无力吐槽。 三、NOKIA N1 第一项测试，TYPE-C口CC逻辑测试，经过测试N1的CC口为悬空！也就是说，它完全不是一个TYPE-C设备，仅仅是外观采用TYPE-C接口，因此能够支持正反插而已。 第二项，不用测了。 第三项，不用测了。 以下是测试结果，请各位专家多多指正，也算是抛文引砖了。 产品 TYPE-C设备类型 数据接口 接口标准 备注 Macbook DRP USB3.1 HOST 充放兼容TYPE-C 1.1、USB PD 2.0、Battery charging 1.2 可通过USB-IF认证 乐1 DFP USB2.0 HOST and Device 放电兼容TYPE-C、充电为非TYPE-C设备、不支持PD DFP部分可通过USB-IF认证 NOKIA N1 IS NOT TYPE-C Device USB2.0 Device 充放都不兼容TYPE-C 纯粹的TYPE-C当Micro USB使用 值得称赞的是苹果，对USB TYPE-C 1.1, USB PD 2.0, Battery Charging 1.2三项标准的严格遵守，为业界的TYPE-C接口设备提供了典范。乐视的选择属于无奈之举，因为不像苹果这样的老大，可以从芯片级玩到成品级。乐1设计阶段，市面上的TYPE-C接口芯片没有任何一家量产的，只能够退其次而求之了。如果能够用上乐得瑞的LDR6013,同时支持DFP，DRP，Try,SRC，UFP四种角色的Type-C芯片，则可以有更多的创意空间可以发挥了。 这次测试其实也带来了另外一个问题，TYPE-C标准的本意，是要统一接口，避免社会资源的浪费。但是，目前这个阶段，能够给苹果充电的适配器以及连接线，无法给乐1充，而乐1的充电线，则无法给MACBOOK充(实测结果，充电电流是500mA，无法满足MACBOOK供电)，那么是否有两全其美的方案呢？答案是肯定的，乐得瑞已经针对这个问题设计了同时支持TYPE-C和BC 1.2的A口转C口连接线方案，能够同时满足给MACBOOK和乐1，N1充电，并兼容数据传输，目前已经导入到了移动电源业界，号称“无所不能充”的龙头老大进行生产，很快大家就会见到这个品牌的无所不能充的A口转C口充电线上市了。