1.一款可让大型iOS工程编译速度提升50%的修改析工具
2.pod的工作原理 CocoaPods终端的工作原理是什么
3.实战！用Bazel来管理iOS程序
4.代码测试工具Fortify介绍及实操演示（下）

一款可让大型iOS工程编译速度提升50%的源码s源工具

       提升iOS编译速度的新利器：美团cocoapods-hmap-prebuilt

       面对大型iOS工程的编译挑战，美团自主研发的码分cocoapods-hmap-prebuilt插件凭借先进的Header Map技术，实现了革命性的修改析突破。这款插件针对全源码编译流程进行了深度优化，源码s源平均提升了高达%的码分软件开发源码编译速度，无论是修改析链路速度还是打包速度，都能让开发者体验到前所未有的源码s源速度提升。

       传统的码分CocoaPods管理方式常常因为Header Search Path的膨胀和文件I/O操作的冗余，导致编译时间过长，修改析甚至带来头文件查找的源码s源困扰。cocoapods-hmap-prebuilt的码分诞生，正是修改析为了解决这些问题，通过智能优化头文件搜索路径，源码s源减少不必要的码分编译负担，专为大型项目量身打造。

       然而，Header Map并非易用的魔法，它是一种头文件信息的映射表，只有当正确配置并理解其工作原理后，才能发挥效能。开启Use Header Map选项，工程师们需要深入研究Build Log中的编译命令和.hmap文件，这些二进制文件中的键值对关系随着项目结构和头文件引用方式的调整而动态变化。Facebook的黑马难逃指标源码buck工具虽然也有类似功能，但cocoapods-hmap-prebuilt的创新之处在于对iOS环境的深度定制。

       Public、Private和Project头文件的区别在Xcode的Copy Headers阶段有着明确的定义：Public允许外部广泛使用，Private限于内部，Project仅限项目内部。理解这些概念有助于解析.hmap文件内容，尤其是在处理Pods项目结构时，头文件的分类至关重要。

       尽管启用Header Map并不能直接加速编译，但在处理Static Library等复杂项目时，cocoapods-hmap-prebuilt展现出了独特价值。它通过创建头文件索引、生成.hmap文件，并重新配置Header Search Path，巧妙地处理了头文件命名冲突，同时关闭组件的Use Header Map功能，确保编译效率的最大化。

       使用cocoapods-hmap-prebuilt的步骤简单明了：在Gemfile中声明插件，然后在Podfile中集成。此外，它还提供了头文件补丁和环境变量注入功能，增强了跨场景的兼容性。尤其对于Swift和Objective-C混编项目，这款工具的AI音乐生成源码表现更为出色，相较于Xcode的Header Map，它在内存读取优化方面有着显著优势。

       技术的革新永不停歇，美团iOS工程师们持续探索，cocoapods-hmap-prebuilt就是他们对高效编译的一次突破。如果你对Clang Module技术感兴趣，或想了解更多，我们建议参考附录链接中的详细文档，那里有深入的技术解析和实践指南。

pod的工作原理 CocoaPods终端的工作原理是什么

       1、所有的开源三方库，都会把框架的.spec文件添加到CocoaPods远程索引库中，而每一个.spec文件中都包含三方库的作者名称、版本号和源码的地址

       2、执行pod setup

       远程索引库中所有的.spec都会被拷贝到本地索引库

       3、执行pod search

       会从本地检索索引文件中去查询所查询的库

       4、执行pod install

       当查询到后会从索引文件中对应的源码地址中下载代码集成到项目中

       5、当我们要做一个公开库的时候，只需要编写好源码，并且把源码的.spec文件添加到CocosPods远程索引库

       相反，当我们要做一个私有库的时候，只需要编写好源码，并且把源码的.spec文件添加到我们自己的远程索引库中

实战！用Bazel来管理iOS程序

       在探索Bazel作为iOS项目管理工具的kodi可以隐藏源码过程中，我总结了以下几点原因促使我选择Bazel而非Xcode：

       首先，Bazel提供更好的代码审查和依赖管理。Xcode的编译设置分散在多个文件中（xcscheme、pbxproj和xcconfig），使得代码审查变得困难。相反，Bazel的配置统一且可追踪，有利于代码审查流程。

       其次，Bazel具有高效的缓存机制和快速增量编译能力。Xcode的编译缓存管理效率低下，即使是细微的设置改动也可能导致全量编译。相比之下，Bazel仅对发生变化的文件或依赖进行编译，切换分支也不会显著影响编译速度。

       此外，Bazel支持远程缓存，这在项目规模增大时能显著提高编译效率。它还提供了更多模块化实践的友好环境，支持Swift等语言的大型项目开发。

       选择迁移Bazel的时机因工程团队规模和需求而异。在感受到Xcode编译系统的不足（如长时间编译时间、单体大项目或持续集成工具频繁报错）时，迁移可能需要几个月的挂京豆源码时间。而对于小型团队，迁移Bazel可能不是当前的首要任务。

       配置阶段涉及安装工具（如Bazelisk和Tulsi）和调整文件结构。在源码库中创建WORKSPACE文件以整合规则，使用generate_xcodeproj.sh脚本生成Xcode项目。同时，通过PodToBUILD项目自动将CocoaPods依赖转换为Bazel兼容的格式。

       处理CocoaPods依赖时，利用PodToBUILD将现有项目的依赖转换为Bazel格式，然后通过特定命令将依赖复制到源码库中。对于某些依赖，如Google的Protobuf，可以将官方的BUILD文件替换原有的CocoaPods配置。其他依赖通常通过Bazel的编译规则进行导入。

       在处理C++支持时，需要手动创建自定义的toolchain并将其集成到本地项目中，以确保使用C++。此外，还需要关注Bridging header的配置、Provisioning文件、entitlement设置、以及手机测试和打包的相关步骤。

       在Bazel下进行单元测试时，注意区分Hosted Tests与ios_unit_test的使用场景。对于大多数测试应转换为单元测试，而对于依赖特定环境的测试（如SnapshotTesting），则保持Hosted Tests的使用。

       将Bazel集成至持续集成系统中，如Bitrise，可以简化测试和打包流程。通过共享缓存，可以进一步提升持续集成的编译速度。同时，使用Bazel的select_a_variant函数选择性地编译不同版本的程序，如针对Apple的提交版本。

       随着项目的深入使用Bazel，可以探索更多的代码生成技术，例如自动将配置文件（如JSON文件）生成固定Swift文件，直接嵌入程序中，减少加载步骤。

       迁移Bazel虽然需要一定的前期投入，但相对于之前的切换经验（如从Xcode Workspace到Buck），过程变得更加顺畅。对于大型依赖复杂的项目，迁移工作量也相对较小，通常只需几天时间。

       尽管Bazel已提供了良好的基础支持，仍有改进空间，尤其是在工具集成与代码生成的自动化方面。此外，社区的反馈和讨论对于进一步优化迁移过程和利用Bazel的潜力至关重要。

代码测试工具Fortify介绍及实操演示（下）

       Fortify是一款在代码审计中广泛应用的静态代码分析工具，尤其在金融等行业中受到青睐。它是软件开发组织及专业评测机构构建软件测试体系时的常用安全测试工具。在前面的文章中，我们已经介绍了Fortify的最新功能和通过“Audit Workbench”模式测试Java语言源代码的方法。接下来，本文将继续介绍通过“Scan Wizard”模式和命令行进行测试的操作流程。

       通过“Scan Wizard”进行测试

       “Scan Wizard”支持多种语言或框架的源代码测试，包括Java、Python、C/C++、.Net、Go、PHP、Flex、Action Script、HTML、XML、JavaScript、TypeScript、Kotlin、SQL、ABAP、ColdFusion。

       （1）打开Scan Wizard

       （2）选择Python文件所在目录

       （3）确认测试工具自动识别内容

       （4）选择库文件

       （5）生成脚本文件

       （6）完成脚本文件生成

       （7）执行生成的脚本文件

       通过命令行进行测试

       命令行方式支持各语言源代码的测试。

       一、Linux项目测试

       以Linux下C/C++程序代码测试为例：

       1. 代码编译

       在代码测试执行前，首先需要进行C/C++程序代码的编译，如下面的示例：

       gcc -I. -o hello.o -c helloworld.c

       通过gcc编译器将代码进行编译。

       2. 代码测试

       在代码编译后，使用sourceanalyzer命令进行代码文件测试。

       sourceanalyzer -b gcc -I. -o hello.o -c helloworld.c

       3. 代码扫描结果文件生成

       在代码测试后，使用sourceanalyzer命令进行代码文件扫描及结果文件生成。

       sourceanalyzer -b -scan -f hello.fpr

       其中，本命令中的与第2步命令中的相同。成功生成结果文件后，可以基于该结果文件生成测试报告。

       4. 代码扫描结果文件生成

       二、iOS项目测试

        1. iOS项目测试条件

       （1） iOS项目需要使用non-fragile Objective-C runtime模式（ABI version 2或3）

       （2） 使用Apple “xcode-select command-line tool”设置Xcode path，同时供Fortify使用。

       （3） 确保项目相关依赖库文件已经包含在项目中。

       （4） 针对Swift代码，确保所有第三方模块都已经被包含，包括Cocoapods。

       （5） 如果项目中包含二进制的属性列表文件，需要将它们转化为XML格式，通过Xcode的putil命令进行转换。

       （6） 针对Objective-C项目，需要保证头文件能够被获取。

       （7） 针对WatchKit应用，需要同时转化iPhone应用和WatchKit扩展目标。

       2. iOS代码测试执行

       sourceanalyzer -b xcodebuild []

       测试报告生成

       通过“Scan Wizard”生成测试报告

       通过“Scan Wizard”方式进行测试执行，会生成.fpr测试结果文件，然后通过命令行方式基于测试结果文件生成测试报告文件。

       通过命令行生成测试报告

       通过“Scan Wizard”方式或命令行方式生成测试结果文件后，可以基于“ReportGenerator”命令生成测试报告。

       下面示例中，基于.fpr结果文件生成PDF格式的测试报告。

       ReportGenerator -format pdf -f.pdf -source .fpr

       .pdf为命名的PDF格式测试报告名称，.fpr为测试结果文件名称。

       以上就是我们为大家介绍的Fortify不同模式下的使用操作流程，欢迎大家交流讨论。如需其他软件测试体系建设相关的内容可私信我交流。

       （谢绝转载，更多内容可查看我的专栏）

       相关链接：

       @道普云 持续输出软件测试技术、软件测试团队建设、软件测评实验室认可等内容。不断更新中，欢迎交流探讨。

       我的专栏：

       性能测试 工具、方法、流程、诊断、调优......

       安全测试 app安全测试、web安全测试、渗透测试、代码测试

       软件测试CNAS认证 标准解读、政策分析、体系建设、测试方法、测试工具

       功能测试 功能自动化测试、自动化测试工具、测试用例、缺陷管理

       新兴技术测试 人工智能系统测试、大数据系统测试、自动化测试...