重磅 Windows 10内部版本及核心源代码泄露，一共32TB

雷锋网 6 月 24 日消息，据外媒 TheRegister 报导，多个微软内部 Windows 操作系统版本及大量内核源代码被泄露到网上。

据悉，这32TB的非公开官方安装映像和软件蓝图设计被压缩到了8TB，然后被上传至betaarchive.com，而最新一批文件是本周早些时候上传的。TheRegister怀疑，这些秘密数据很可能是今年3月份前后从微软内部系统中泄露出来的。

见到过泄漏代码内容的消息人士表示，被泄露的代码是微软共享代码工具包(Shared Source Kit)，包括Windows 10硬件驱动程序的源码，PnP（Plug-and-Play）代码，USB和WiFi协议，存储驱动程序，以及支持ARM架构的OneCore内核代码。

由于这些数据是Windows操作系统的核心代码，而且部分代码具有最高权限。TheRegister称，任何获取这些数据的个人或组织，都可以查找Windows系统中安全漏铜，并利用它来开发恶意软件，对全球Windows设备发动攻击。

除此之外，尚未公布的绝密Windows 10和Windows Server 2016版本，也随着一些公开发布的版本的副本，一起出现在泄露的数据中。

而且，泄露的数据中还包括多个版本的Windows 10 Mobile Adaptation Kit：这是一款秘密的软件工具包，能够让Windows操作系统能在多种便携和移动设备上运行。

据雷锋网了解，能够访问Beta Archive私人资料库的网民，可以免费获得这些被泄露的数据。目前，微软还未就此事置评。Beta Archive则发表声明称，他们已经从FTP服务器和列表中删除了这些数据。

有外界人士认为，这次泄露比发生在2004年的Windows 2000源代码泄露事故更为严重。

Via. TheRegister，雷锋网编译

macOS平台虚拟机软件Parallels Desktop 19推出

IT之家 8 月 22 日消息，macOS 平台 Parallels Desktop 19 for Mac 目前已经发布，官方表示“Parallels Desktop 软件可让 Mac 用户能够在虚拟环境中运行 Windows、Linux 和 macOS，无需作出妥协即可同时享有多个操作系统的优势。”

据官网介绍，“Parallels Desktop 19 for Mac 可在 Mac 上运行超过 200000 个 Windows 应用程序，包括 Microsoft Office for Windows。在 Intel 或 Apple M 系列 Mac 计算机上下载并安装 Windows 操作系统。在 Mac 与 Windows 之间无缝复制和粘贴文本或拖放对象。在 Mac 虚拟机中跨多个操作系统开发和测试。毫不费力地运行 Windows 应用程序，不会减慢 Mac 的运行速度”。

Parallels Desktop 19 for Mac 新许可证售价 618 元起，升级选项售价 498 元起。此前最新订阅版可免费升级和下载。

IT之家归纳汇总官方更新日志如下：

与 macOS Sonoma 的兼容性

“融合视图”模式更新

官方表示，在 macOS Sonoma 14 中，用于窗口管理的 AppKit 有了重大改变：所有用户界面窗口变动现在都与显示器同步 （v-sync）而这大幅减慢了融合视图模式下 Windows 应用程序的动画速度（例如，调整窗口大小、重新定位窗口或使用 Stage Manager）。

考虑到用户钟爱融合视图模式，同时运行 Windows 应用程序和 Mac 应用程序，Parallels 的工程师重新设计了融合模式下使用 Windows 应用程序的方法，以确保升级到 macOS Sonoma 14 后提供流畅愉悦的用户体验。

设计方面的改进

换了个图标

官方表示“开发人员不想简单地把旧图标放进一个熟悉的圆角白色图块上，而要重新思考如何通过视觉语言在 macOS 中传播开发人员的应用程序”。因此他们引入了新的应用程序图标，并介绍了图标的设计细节：

考虑到开发人员的大多数用户都在使用 MacBook 电脑，于是开发人员将长期使用的与 iMac 一体机类似的“后台”功能用到了笔记本电脑上。

对于同时运行多个操作系统这一并行性的隐喻已经从“置于 Mac 桌面前”转变为“后台”运行，因为后台正是开发人员所在 — 启动虚拟化引擎并在后台运行，使用户能够运行第三方操作系统和软件。

最后，左上角神秘小洞的问题已妥善解决。角落处带圆点的矩形代表一个容器：一个容纳“您的工具”的窗口，无论您从哪个平台访问都能看到。此外，这也体现了全新的 Parallels 品牌，其将所有 Parallels 产品合并到组织的单一钥匙串中。

使用 Touch ID 登录 Windows

功能如其名，虚拟机层面的密码管理器，验证 TouchID 后自动输入账号密码

官方表示“开发团队将 Apple Touch ID 的神奇魔力带入 Windows 登录和 Parallels Desktop 安装中”

如果您的 Windows 10 或 11 受到 PIN 码或密码保护，当您在升级到 Parallels Desktop 19 后，下次登录 Windows 时，系统将提示 Windows 使用所提供的新的 Parallels 凭证。您的 Windows 密码将保存到 Mac 钥匙串中，并附带特殊的 Touch ID 绑定记录类型（该记录仅供 Touch ID 使用），且仅限此 Mac 上使用您的指纹方可获取。

下次登录 Windows 时，Parallels Desktop 将提示您使用 Touch ID 登录您的用户账户。这样既简单又安全。用户可以通过一个简单但实用的界面管理所保存的密码，根据用户的意愿，也可以恢复使用旧的登录方法。

OpenGL 改进

官方表示，“世界各地的基础架构、工程和设计领域专业人士都在使用 Parallels Desktop 在其 Mac 上启动工作所需的 Windows 应用程序，开发人员为此感到非常激动。今年，改进版 OpenGL 最高可以支持 4.1 版本，开发人员可以在 Mac 上运行更多的 Windows 专用 CAD 软件，包括 VariCAD、Deswik.CAD、Vectorworks Vision 2023 等”。

“信赖 Parallels Desktop 的专业人士，可以在 Mac 上运行热门的地理信息系统软件 AcrGIS Pro 也是一大喜讯。开发人员听取反馈意见并作出改进，在此很高兴地宣布，该版本中 ArcGIS Pro 的性能有了重大改进。”

更易安装、更多操作功能

在搭载 Apple 硅芯片（Apple Silicon）的 Mac 上，macOS 虚拟机由一个相对较新的 macOS 框架所驱动，与用于（在所有 Mac 上）启动 Windows 和 Linux 以及在搭载 Intel 芯片的 Mac 上启动 macOS 的 Hypervisor 框架相比，Parallels Desktop 对虚拟机操作的控制要少得多。正因如此，搭载 Apple 硅芯片的 Mac 上的 macOS 虚拟机功能更少且采用不同的打包格式“.macvm”，较为熟悉的“.pvm”格式则用于其他虚拟机类型。

这次升级针对搭载 Apple 硅芯片的 Mac 上的 macOS 虚拟机进行了改进：

虚拟机安装：通过 Installation Assistant 用户界面使用 IPSW 映像安装新的 macOS 虚拟机，或者使用 CLI （$ prlctl create "macOS13" -o macos --restore-image "/path/ to / image.ipsw） 进行安装。

基本的虚拟机操作：从用户界面菜单或使用 Parallels CLI prlctl 重启、关闭和暂停恢复虚拟机。

输入：在虚拟机中使用 Trackpad 双指手势进行滚动和缩放。

大规模部署：将带有 macOS 虚拟机的 Parallels Desktop 部署到搭载 Apple 硅芯片的 Mac 计算机上。

macOS Sonoma 14 同时在主存容量和虚拟容量下运行，体验更好：

显示：调整虚拟机窗口大小时自动更新显示分辨率。

网络：如果使用 Pro Edition，在诸如将虚拟机托管在 Amazon EC2 Mac 实例上等情况下，可利用端口转发，通过 SSH 或 RDP 远程访问 macOS 虚拟机。

更加轻松

结合 Parallels 虚拟机使用 Packer 更加轻松，并且支持搭载 Apple 硅芯片的 Mac 上的 macOS 虚拟机。

开发人员在开发 Parallels Desktop 时，一直在尝试将手动操作尽可能地自动化。使用 Parallels Desktop 来开发和测试自身软件的许多客户也是如此。为了回应客户的宝贵反馈意见，开发人员携手 HashiCorp 为 Parallels 提供商提供了期待已久的针对 Packer 和 Vagrant 的改进。

使用 Parallels Desktop 19，则不再需要使用 Parallels SDK 和 Python，从而可以更加轻松地使用这些基本工具进行工作。开发人员很高兴地宣布，这次升级让用户也能够在搭载 Apple 硅芯片的 Mac 上创建和配置 macOS 虚拟机。

开发人员一直致力于开源，由此开发了各种针对 Packer 的范例模板，简化了新客户的入门学习过程。这些模板适用于 Windows、Linux 和 MacOS，可在开发人员的 GitHub 资源库中免费获取 （https://github.com/ Parallels / packer-examples）。

此外，开发人员还修改了文档，提供关于结合 Parallels 提供商产品无缝使用此等工具的综合指南。

运行 CentOS 9 Stream 等

搭载 Apple 硅芯片的 Mac 上的 Linux：运行 x86 Docker 容器以及 Microsoft SQL 和 CentOS 9 Stream。

对于需要在搭载 Apple 硅芯片的 Mac 上运行 x86 Docker 容器或 Microsoft SQL Server 的开发人员而言，Parallels Desktop for Mac Pro Edition 可以提供一个新版现成的 Ubuntu Linux Arm 虚拟机，其可运行 x86 Docker 容器，由 Apple 的 Rosetta 2 技术提供支持。新版虚拟机可以从 Installation Assistant 的 Free Systems 部分下载。

对于开发人员和高级用户来说

在搭载 Apple 硅芯片的 Mac 上的 Linux Arm 虚拟机中引入运行 x86 二进制文件和容器的功能，开发人员对此也感到非常激动。通过整合一个现成且可下载的 Ubuntu Linux 虚拟机，开发人员简化了运行 x86 容器映像（包括 Microsoft SQL Server 等热门的容器映像）的过程。

这一突破使得用户能够轻松使用和调试容器，并构建用于 x86 平台的容器。

未来，开发人员将致力于在以后的更新中持续改进此等二进制文件的兼容性。请持续关注这一方面激动人心的进展。

Parallels Desktop 19 for Mac 也支持在搭载 Apple 硅芯片的 Mac 上运行 CentOS 9 Stream。无论您是学习、开发还是测试 CentOS / RHEL，开发人员的解决方案都能提供灵活性和通用性。

组织内部设备管理

在 Microsoft Intune 中注册 Windows

开发人员了解设备管理对于企业组织而言的重要性，并看到越来越多的客户采用 Microsoft Intune。

以前，为了确保组织内最终用户使用的虚拟 Windows 设备可以在 Microsoft Intune 中进行注册，IT 管理员只能使用大规模部署场景，这对于某些类型的组织来说并不方便。

在通过 Parallels My Account 网页应用程序向员工提供 Windows 11，以及只是通过云存储共享 Windows 映像的情况下，Parallels Desktop 19 for Mac Business Edition 支持在 Intune 中注册 Windows 11。

此功能让组织内的 Windows 设备管理变得更加容易和高效。

抖音 iOS 工程架构演进

前言介绍

2016.09.26，抖音版本 1.0.0 上线，随后不断迭代优化和丰富产品，截止目前，抖音日活跃用户突破 6 亿，短短 4 年间，抖音从零爆发性增长。

快速的业务发展也对技术支撑提出了更高的要求，为了保障敏捷的业务开发，提升跨团队的协同合作效率，提高本地研发和 CI/CD 效率，抖音 iOS App 工程架构在不同的阶段进行了不同的技术方案的改进，满足合理的架构演化，同时又不影响正常的业务迭代速度。

抖音工程架构演进

架构演进的本质是为了提高研发效率，提高代码稳定性和保证代码质量。架构要解决的问题是如何组织代码。

合理的架构设计可以解决大型项目跨团队协作分工和多业务线并行开发的效率问题。抖音工程代码从一开始就采用了组件化思路，依赖管理工具是定制版的 Cocoapods。

以下动画介绍了抖音工程架构经历的四个阶段的演进过程：

图1：抖音项目工程架构演进

组件化

在大型项目快速发展的过程中，要保证敏捷开发迭代的最大障碍就是快速膨胀的代码体积导致的编译效率问题，依赖关系复杂化问题，以及业务线代码冲突问题。

移动端项目可以类比后端项目中采用的微服务架构，要解决多业务线并行开发、并行测试问题，采用流水线式迭代开发，提高发版、集成、交付、提审、发布效率，结合分治思想技术选型上可以采用组件化的方案。

大部分小型项目，组件化仅仅做到代码分仓，使用 Cocoapods 的来管理组件依赖，就像抖音项目最初的工程形态。

但是对于几百号人、几十个业务线规模的大型项目，需要设计一套合理的组件分层架构，理清组件间依赖关系，需要 CI/CD 工具链支撑组件发版与集成，需要本地研发工具支撑本地代码同步、工程配置、依赖管理和效率优化。

流水线式迭代开发

流水线（pipeline）技术是指在程序执行时多条指令重叠进行操作的一种准并行实现技术，该技术可以充分提高资源的利用率，同时缩短产品的研发周期。对于客户端项目，流水线技术能很大程度满足敏捷开发迭代的节奏。

图2：抖音流水线式迭代发版

抖音工程架构演进

阶段一：抖音原始工程架构（Original architecture of project）

图3：抖音项目原始工程架构图

抖音项目一开始是单体架构+Cocoapods，业务代码、工程配置、资源文件全部放在一个大业务仓库。由 Podfile 文件描述第三方仓库的依赖版本。

图4：抖音项目原始工程架目录结构

阶段二：分离壳工程后的工程架构（After splitting of host shell pod）

图5：拆分壳工程后的工程架构

分离壳工程后，工程配置、部分系统资源、工程主入口被拆分到主宿主壳工程。

Podfile 拆分出版本依赖管理文件 Podfile.seer，由依赖管理平台进行各个版本的容器化管理，业务仓跟随宿主集成发版，打平依赖，解决版本依赖决议耗时问题。

大业务仓中的代码和资源被拆分到各个业务线的仓库下，由 podspec 文件描述内外依赖。业务线仓库增加 ModuleInterface subspec，存放对外接口，采用依赖注入方式实现接口隔离，初步建立接口层。

业务仓库之间规定只能依赖其他业务仓库的 ModuleInterface subspec，通过 lint 进行编译检查。

部分基础能力代码被拆分成基础仓库，跟第三方仓库一样独立发版。本地研发工具支持单仓开发和多仓开发，不参与代码修改的仓库通过二进制的方式进行链接。同时 CI 流程上也支持通过二进制打测试包，提高打包效率。

图6：抖音项目拆分壳工程后目录结构

壳工程

图7：壳工程抽象

为了满足一个工程同时支持多个项目、部分业务线功能复用、部分业务线中台化发展的需求，我们把所有业务线抽象成独立的 Pod，所有业务 Pod 必须通过宿主的壳工程进行集成发版。

壳工程包含了项目依赖的 Pod 信息描述，同时还包括工程的配置、部分系统级别的资源文件、工程主入口代码。基于多份宿主壳工程，一份代码可以打包出抖音、抖音极速版等项目。

同时，基于宿主壳工程，一些业务线可以通过自动化同步生成自己的子壳工程，实现业务线自己的 Example 工程，进行独立开发，比如有语音通话的 Example 工程，有工具的 Example 工程，有直播的 Example 工程等等。

图8：子壳工程配置同步同步

接口层

接口层顾名思义，只提供依赖的抽象接口，所有接口都是 protocol 协议声明。

接口层限制了所有其他依赖，类、枚举、 外部协议都采用前向声明，podspec 上只允许声明对 DI（依赖注入）框架的依赖。接口层满足封装、隔离和组合的原则。

业务层面对外封装了实现代码；编译层面隔离了组件间依赖传递，减少头文件 import 嵌套提高编译缓存的命中率，对于 swift 业务组件，还能达到减少编译传递的问题；架构层面声明抽象协议支持接口组合；DI 容器框架同时支持 stateless DI 容器，也支持 stateful DI 容器。

依赖打平

采用 Cocoapods 本身自带的版本依赖决议进行版本分析会消耗大量的时间；Podfile.lock 过于繁琐，可读性很差，难以解决 Podfile.lock 的冲突；隐式依赖被动/不符合预期地升级，难以确定性地声明所有依赖，防止隐式依赖被升级；依赖版本在 Podfile/Podfile.lock 重复声明，增加了解决冲突的成本；Podfile.lock 参与依赖版本决议流程比较复杂，会出现不符合预期的情况。

图9：把版本管理和仓库源信息迁移到 Podfile.seer 文件

hook 掉 Cocoapods 采用 podfile.lock 进行版本决议的逻辑，采用 Podfile.seer 文件直接描述所有组件的版本信息，打平依赖。

阶段三：单仓多组件工程架构（Multicomponents in single repo）

图10：拆分单仓多组件后的工程架构

采用单仓多组件后，每个业务线仓库支持添加 podspec 增加组件，实现更小粒度的二进制依赖。业务线仓库内划分业务实现层、业务接口层、服务层和基础层，都是通过集成方式发版。

新增的服务层主要存放公共的业务逻辑和通用服务，限制 UI，一是满足业务逻辑复用，二是满足子壳工程最小化二进制依赖。同时服务层的服务接口也达到隔离依赖传递的目的，在不同的宿主上，支持通过改变服务层实现替换后台能力或者底层能力。建立分层间的依赖准入规则，完善 lint 编译链接检查。

图11：单仓多组件目录结构

编译链接完备性校验

编译校验：分开编译各个 subspec，确保每个 subspec 的依赖是正确的(由于 subspec 没有编译隔离)接口符号校验：校验当前接口组件(ModuleInterface)中符号是否完备的，以保证其他组件单独引用是否能正常使用。如 extern 声明的全局变量。

分层依赖准入规则：

高层依赖低层实现依赖接口接口层无依赖前向声明优先服务层去"UI"

以下动画展示了业务实现层和服务实现允许依赖的分层：

图12：组件依赖关系示意图动画

阶段四：Example 子壳工程架构（Subshell for bizcomponent in example project）

图13:子壳工程架构

每个业务仓从宿主同步工程配置构建子壳工程。增加 AWELaunchKit 为子壳工程提供运行时的基础能力。通过服务层提供业务间运行时共享的服务能力，满足代码复用和更小二进制依赖。

图14：子壳工程目录结构

AWELaunchKit

AWELaunchKit 框架为宿主和其他子壳工程提供了基础服务的依赖和初始化配置。同时提供了一套启动加载的 BootTasks 管理框架，部分业务涉及启动相关的逻辑可以在业务仓对应的服务层中实现，并通过 BootTasks 管理框架注册到启动加载器里面。

同时框架还提供了一套宿主 UI 入口和自定义入口框架。为了方便测试和调试，也整合了整套测试调试框架。

图15：子壳工程依赖关系

组件化探索过程中遇到的一些问题：

二进制污染

组件之间的依赖除了显式的依赖，还存在很多隐式依赖，代码层面，除了普通的接口依赖，还有宏依赖、枚举依赖、全局变量依赖以及内联函数等的依赖。单仓 lint 进行编译链接完备性检查并不能解决依赖变动对其他二进制的影响。

因此需要借助源码层面的依赖分析，判断当前组件的变更对其他依赖当前组件的二进制是否有影响，在 CI 流程中及时发现并拦截。否则错误的二进制发版，会直接导致整个 CI 研发流程和本地研发都受到影响。

编译优化

编译优化最高效的方式就是提高缓存的利用率。对于本地研发和 CI 流程，都涉及分布式编译缓存同步。同时通过编译参数优化、依赖优化、hmap 优化也能不同程度的提高编译效率

主干分支稳定性问题

对于多业务线并行开发，几百号人的业务开发团队，如果主干分支一旦出现问题，那么解决问题的时间就需要乘上几百倍。因此，需要从编译层面和运行层面都要有足够的机制去保证一个稳定的主干分支，才能保证业务侧的长期稳定性。

业务层的依赖耦合问题

大型项目动则千万行的代码，代码间的依赖关系是复杂的网状关系。需要基于代码的语法树模型，从语义中去分析不合理的依赖，并输出治理的方案。

我们内部自研了源码依赖关系分析平台用于依赖关系分析监控和代码治理，长期监控组件间的依赖度。同时，需要建立依赖健康度模型，从长期演进的角度去监控防止代码的劣化。

图16：spider 组件依赖分析平台

总结

大型项目的组件化工作是一个系统性工程。涉及工程架构的改造、CI/CD 研发工具链的支撑、本地研发工具链的支撑，业务架构的设计优化，需要从各个方面综合考虑成本和收益。

没有最好的架构，只有更好的架构，在架构演进的过程中，我们需要充分考虑架构的改动对业务的影响以及能给业务带来的收益。好的架构一定是能帮助业务节省时间，保证质量的。与此同时，我们在架构改进的过程中，要保证不能影响业务的正常迭代，所以向前兼容且避免大面积冲突也是很重要的事情。

组件化里面处处都有惊喜，比如一个小小的 hmap 优化，可以很大程度的减少编译耗时，比如一个二进制的压缩和解压的优化，可以很大程度减少 pod install 的整体耗时。

当然这里面也会有很多很棘手的问题，需要通过一些特殊的方案解决，比如针对分布式开发，由于阻塞式发版必然会导致一些不同分支存在冲突的代码发版后影响主干的稳定性。

由于文章篇幅有限，只能点到即止地介绍当前一些工作成果和思考，各个 Topic 还有一些新的方向在探索，如果你对 iOS 底层原理、架构设计、构建系统、自动化测试有深入了解，快来加入我们吧！

加入我们

我们是负责抖音客户端基础能力研发和新技术探索的团队。我们在工程/业务架构，研发工具，编译系统等方向深耕，支撑业务快速迭代的同时，保证超大规模团队的研发效能和工程质量。在性能/稳定性等方面不断探索，努力为全球数亿用户提供最极致的基础体验。

如果你对技术充满热情，欢迎加入抖音基础技术团队，让我们共建亿级全球化 App。目前我们在深圳、上海、北京、杭州、均有招聘需求，内推可以联系邮箱：tech@bytedance.com ，邮件标题：姓名-工作年限-抖音-基础技术-iOS/Android 。或直接点击拓展链接 查看部门所需岗位！

欢迎关注「字节跳动技术团队 」

投递简历请联系邮箱：tech@bytedance.com