百度APP iOS端包体积50M优化实践(六)无用方法清理

一、包体积优化的核心挑战与无用方法清理的必要性

在移动应用开发中，iOS端包体积直接影响用户下载意愿、安装成功率及内存占用。百度APP作为超大型应用，其iOS端包体积曾长期面临增长压力，尤其是功能迭代带来的代码膨胀问题。无用方法清理作为包体积优化的关键环节，能够直接减少二进制文件大小，降低资源占用，同时提升应用启动速度和运行效率。

1.1 无用方法的影响分析

无用方法通常指未被任何代码路径调用的方法，其存在会导致：

二进制体积增加：每个方法都会占用Mach-O文件中的代码段空间；
链接时间延长：编译器需处理更多符号，影响构建效率；
内存占用隐性增长：动态库加载时需映射更多代码页。

1.2 百度APP的优化目标

在50M包体积优化专项中，无用方法清理的目标是：

精准识别并移除所有无效代码；
避免误删导致功能异常；
结合其他优化手段（如资源压缩、动态库合并）实现综合降本。

二、无用方法清理的技术方案与工具链

百度APP通过构建自动化工具链与人工复核机制，实现了高效、安全的无用方法清理。

2.1 静态分析：基于符号依赖的识别

2.1.1 工具选择：MachOView + 自定义脚本

MachOView：可视化分析Mach-O文件结构，定位未引用的符号；
自定义脚本：通过otool命令解析__TEXT,__text段，统计方法调用关系。

示例脚本片段：

import subprocess
def find_unused_methods(binary_path):
    # 获取所有方法符号
    symbols = subprocess.check_output(["nm", "-U", binary_path]).decode()
    # 过滤未定义符号（需结合调用图分析）
    unused_candidates = []
    # ...（调用图分析逻辑）
    return unused_candidates

2.1.2 调用图构建

使用Clang静态分析器生成方法间的调用关系，标记未被任何入口点（如main、UIApplicationDelegate方法）触发的路径。

2.2 动态分析：运行时跟踪

2.2.1 插桩技术

通过LLVM中间表示（IR）插桩，在方法入口和出口插入日志，记录实际执行的方法：

; 原始方法
define void @original_method() {
    ret void
}
; 插桩后
define void @original_method() {
    call void @log_method_entry("original_method")
    ret void
}

2.2.2 用户行为模拟

结合自动化测试框架（如EarlGrey），模拟核心用户路径，确保覆盖90%以上功能，避免遗漏动态调用的方法。

2.3 人工复核与风险控制

2.3.1 代码所有权映射

建立方法与开发者的映射关系，要求负责人确认删除：

// 示例：方法标记注解
@available(iOS, deprecated, message="需确认是否无用")
func legacyMethod() { ... }

2.3.2 灰度发布验证

分阶段发布优化后的版本，监控Crash率、功能异常等指标，确保无副作用。

三、实战案例：百度APP核心模块优化

3.1 案例1：旧版推送服务清理

背景：推送服务从NSURLConnection迁移至URLSession后，遗留的回调方法未被移除。

优化步骤：

静态分析：通过nm发现- [PushService legacyCallback:]等符号存在；
调用图验证：确认无任何代码路径调用该符号；
删除与测试：移除方法后，通过自动化测试覆盖推送全流程，无异常；
效果：单模块减少1.2M二进制体积。

3.2 案例2：动态库合并后的冗余代码

背景：合并多个动态库时，重复引入了相同工具类（如DateUtils）。