布局分析：检测XML嵌套过深

布局分析：检测XML嵌套过深

Android 开发者都知道布局嵌套过深会导致性能问题------measure/layout 是自顶向下的递归过程，层级越深，一次 doFrame 的耗时就越长。但问题在于，项目里的 XML 布局文件动辄几十上百个，你很难靠肉眼一个个看过去找出"哪个布局嵌套太多了"。

SmartInspector 的布局分析从两个维度解决这个问题：一是在运行时通过 Hook LayoutInflater 追踪每个布局的 inflate 耗时，二是把 XML 布局文件作为归因的一部分，自动解析嵌套层级并关联到性能问题。

LayoutInflater 的 Hook 设计

Android 端的 TraceHook 用 Pine AOP 直接 Hook 了 LayoutInflater.inflate(int, ViewGroup, boolean) 方法：

private static void hookLayoutInflate() throws Exception {
    Method inflate = LayoutInflater.class.getDeclaredMethod(
            "inflate", int.class, ViewGroup.class, boolean.class);
    Pine.hook(inflate, new MethodHook() {
        @Override
        public void beforeCall(Pine.CallFrame cf) {
            int layoutResId = (int) cf.args[0];
            ViewGroup parent = (ViewGroup) cf.args[1];
            String layoutName;
            try {
                Context ctx = parent != null ? parent.getContext()
                        : (Context) cf.thisObject;
                layoutName = ctx.getResources().getResourceEntryName(layoutResId);
            } catch (Exception e) {
                layoutName = "0x" + Integer.toHexString(layoutResId);
            }
            String parentClass = parent != null ? parent.getClass().getSimpleName() : "null";
            Trace.beginSection(SI_PREFIX + "inflate#" + layoutName + "#" + parentClass);
        }

        @Override
        public void afterCall(Pine.CallFrame cf) {
            Trace.endSection();
        }
    });
}

生成的 tag 格式是 SI$inflate#layout_name#parent_class。注意这里做了资源 ID 到名称的转换------getResourceEntryName() 能把 R.layout.item_complex 转成可读的 item_complex。如果转换失败（比如系统资源 ID 在 app context 里查不到），就降级为十六进制 0x7f0b0012 这种格式。

为什么 inflate Hook 默认关闭

在 hook.py 的默认配置里，layout_inflate 和 view_traverse 都是 false：

defaults = {
    "activity_lifecycle": True,
    "fragment_lifecycle": True,
    "rv_pipeline": True,
    "rv_adapter": True,
    "layout_inflate": False,     # 默认关闭
    "view_traverse": False,      # 默认关闭
    "handler_dispatch": False,
}

原因是 inflate 调用频率太高了。一个稍微复杂点的页面，Fragment 切换时可能触发几十次 inflate，每次都写 atrace section 会显著增加 trace 数据量。而且 inflate 本身有开销------系统要解析 XML、反射创建 View 对象，Hook 这一层会增加额外的耗时（虽然很小，但频率高了就不可忽略）。

所以只在明确需要分析布局性能时才开启。用户通过 /config 命令动态开启：

SI> /config '{"layout_inflate": true, "view_traverse": true}'

View traverse Hook：measure/layout/draw 的精准追踪

除了 inflate，布局性能的另一面是 View 的三大流程。view_traverse Hook 直接拦截 View.measure、View.layout、View.draw 三个方法：

private static void hookViewTraverse() throws Exception {
    String[] methods = {"measure", "layout", "draw"};
    for (String methodName : methods) {
        // ... 获取对应参数签名 ...
        Pine.hook(m, new MethodHook() {
            @Override
            public void beforeCall(Pine.CallFrame cf) {
                Object thiz = cf.thisObject;
                String className = thiz.getClass().getName();
                // 跳过 RecyclerView（已有专门的 RV hook）
                if (className.contains("RecyclerView")) return;
                // 跳过系统 Widget（不是用户代码）
                if (className.startsWith("android.")
                    || className.startsWith("androidx.")
                    || className.startsWith("com.google.")) return;
                Trace.beginSection(SI_PREFIX + "view#" + className + "." + methodName);
            }
        });
    }
}

这里有两个关键过滤：

1. 跳过 RecyclerView ：RV 有专门的 rv_pipeline 和 rv_adapter Hook，不需要在这里重复追踪。
2. 跳过系统 Widget ：android.widget.TextView、androidx.appcompat.widget.AppCompatImageView 这些不是用户代码，追踪它们只会产生噪音。只追踪自定义 View。

生成的 tag 格式是 SI$view#com.example.MyCustomView.measure。

atrace 127 字节限制

这里有个容易踩的坑：Android 的 Trace.beginSection() 有 127 字节的限制。如果类名很长，tag 会被截断。代码里做了处理：

if (viewTag.length() > 127) {
    viewTag = SI_PREFIX + "view#" + shortenFqn(className) + "." + methodName;
}

shortenFqn 保留最后两个包名段 + 类名，比如 com.smartinspector.hook.ui.HeavyDrawView 会缩短为 hook.ui.HeavyDrawView。

Fragment 生命周期 Hook：动态发现 + 精准拦截

布局 inflate 大多发生在 Fragment 的 onCreateView 里。Hook Fragment 生命周期是定位布局问题的重要环节。

但 Fragment 的 Hook 比 Activity 复杂得多，因为 Android 有两套 Fragment API（android.app.Fragment 和 androidx.fragment.app.Fragment），而且每个 Fragment 子类的 onCreateView 都需要单独 Hook 才能捕获完整的方法体耗时。

两阶段 Hook 策略

TraceHook 用了两阶段策略：

第一阶段：Hook 基类方法

private static void hookFragmentClass(Class<?> fragClass) throws Exception {
    safeHookMethod(fragClass, "onCreateView",
            new Class<?>[]{LayoutInflater.class, ViewGroup.class, Bundle.class}, ...);
    safeHookMethod(fragClass, "onResume", new Class<?>[0], ...);
    safeHookMethod(fragClass, "onDestroyView", new Class<?>[0], ...);
    // ...
}

这能覆盖没有 override 这些方法的 Fragment（直接使用基类实现的情况）。但如果子类 override 了 onCreateView，基类的 Hook 不会触发------因为 Java 方法分派会走到子类的实现。

第二阶段：FragmentLifecycleCallbacks 动态发现

这是关键。通过 Hook FragmentActivity.onCreate，在 Activity 创建时注册 FragmentLifecycleCallbacks，每当 Fragment 被创建时回调会触发，此时拿到 Fragment 的实际类型，对这个具体子类做 Hook：

private static void hookFragmentManagerRegisterFragment() throws Exception {
    Method onCreate = FragmentActivity.class.getDeclaredMethod("onCreate", Bundle.class);
    Pine.hook(onCreate, new MethodHook() {
        @Override
        public void afterCall(Pine.CallFrame cf) {
            // 获取 FragmentManager
            Method getFM = cf.thisObject.getClass().getMethod("getSupportFragmentManager");
            Object fm = getFM.invoke(cf.thisObject);
            
            // 注册回调，动态发现 Fragment 子类
            Object callback = Proxy.newProxyInstance(..., fmcClass, (proxy, method, args) -> {
                if (args[1] instanceof Fragment) {
                    hookConcreteFragment(args[1].getClass());  // 动态 Hook 实际类型
                }
                return null;
            });
            regMethod.invoke(fm, callback, false);
        }
    });
}

hookConcreteFragment 会对这个具体的 Fragment 子类做方法 Hook，包括 onCreateView。这样无论 Fragment 怎么 override 基类方法，都能精准捕获。

注册集合泄漏防护

注意这里用 WeakHashMap 的 keySet 做注册去重：

java.util.Set<Object> registered =
    java.util.Collections.newSetFromMap(new java.util.WeakHashMap<>());

为什么用 WeakHashMap？因为 registered 存的是 Activity 实例引用。如果用普通 Set，Activity 销毁后引用还在，就是内存泄漏。WeakHashMap 的 key 是弱引用，Activity 被 GC 回收后自动从 Set 中移除。

Python 端：从 inflate tag 到 XML 文件归因

Perfetto 采集端拿到 SI$inflate#item_complex#FrameLayout 这样的 slice 后，Python 端要做两件事：

1. SI$ tag 解析

parse_si_tag() 解析 inflate 类型 tag 时，设置 search_type = "xml"：

elif body.startswith("inflate#"):
    tag_type = "inflate"
    search_type = "xml"
    parts = body[8:].split("#")
    class_name = parts[0]  # "item_complex"
    method_name = "inflate"

这意味着归因模块在搜索源码时，不会去找 item_complex.java，而是找 item_complex.xml。

2. XML 布局的归因搜索

在 attributor agent 的 prompt 构建中，XML 类型的搜索策略和 Java 不同：

if search_type == "xml":
    line += ", xml布局:Glob **/{cn}.xml → Read完整文件, RESULT行请用: {cn}.{method_name}"

搜索过程是 Glob 找到 XML 文件 → Read 读取完整内容。因为布局文件通常不大，直接读全文比 Java 方法体的精准定位更合理。

归因的 LLM 分析会结合 XML 内容给出布局优化建议：嵌套层级过深、不必要的容器 ViewGroup、可以合并的层级等。

3. 关联依赖：从 Java 代码到布局文件

这是比较巧妙的设计。在依赖搜索阶段（_enrich_with_dependencies），attributor 不仅搜索 Java 代码引用的其他 Java 类，还会提取 R.layout.xxx 引用并搜索对应的 XML 布局文件：

def _extract_layout_refs(source: str) -> list[str]:
    """从源码中提取 R.layout.xxx 引用。"""
    layouts = []
    for m in _R_LAYOUT_RE.finditer(source):
        layouts.append(m.group(1))  # "item_complex"
    return layouts

比如 DemoAdapter.onCreateViewHolder 里调用了 inflater.inflate(R.layout.item_complex, parent, false)，归因时不仅会读取 DemoAdapter.java 的代码，还会顺藤摸瓜找到 item_complex.xml，把布局内容作为关联依赖上下文一起交给 LLM 分析。

这解决了一个常见问题：你知道 Adapter 的 onCreateViewHolder 慢，但真正的原因可能不在 Java 代码里，而在它 inflate 的 XML 布局嵌套太深。

嵌套深度保护：atrace 的硬限制

Android 的 atrace 系统本身有嵌套深度限制------最多支持 16 层嵌套的 Trace.beginSection。超过这个限制，后续的 beginSection 调用会被静默丢弃，导致 trace 数据不完整。

TraceHook 做了深度保护：

private static final int MAX_TRACE_DEPTH = 10;
private static final ThreadLocal<Integer> traceDepth = ThreadLocal.withInitial(() -> 0);

private static boolean enterTrace() {
    int depth = traceDepth.get();
    if (depth >= MAX_TRACE_DEPTH) return false;  // 超限，跳过
    traceDepth.set(depth + 1);
    return true;
}

private static void exitTrace() {
    int depth = traceDepth.get();
    if (depth > 0) traceDepth.set(depth - 1);
    Trace.endSection();
}

enterTrace() 返回 false 时，这次 Hook 直接跳过，不写 atrace section。设成 10 而不是 16 是留了 6 层余量给系统 atrace tag（Choreographer、doFrame 等系统 trace 也占嵌套层）。

这个保护特别重要。如果 inflate Hook 和 view_traverse Hook 同时开启，一个嵌套 5 层的布局，inflate 出来的每个 View 都会触发 measure/layout/draw Hook，嵌套深度很容易超过限制。有了保护，超限的 Hook 静默跳过，不会导致上层 trace 数据丢失。

用 ThreadLocal 是因为 Hook 可能在不同线程触发（虽然 measure/layout/draw 通常在主线程，但 Handler hook 可能在任意线程）。

布局分析结果在 trace 数据中的样子

一个完整的布局分析链路在 Perfetto trace 里长这样：

doFrame                                     [16.5ms]
  ├─ performMeasure                          [8.2ms]
  │    └─ SI$view#CustomView.measure         [3.1ms]
  ├─ performLayout                           [5.3ms]
  │    └─ SI$view#CustomView.layout          [1.8ms]
  └─ performDraw                             [2.4ms]
       └─ SI$view#CustomView.draw            [1.2ms]

SI$Fragment#DetailFragment.onCreateView      [12.3ms]
  └─ SI$inflate#item_complex#RecyclerView    [9.8ms]

从这个 trace 可以直接看出：

• DetailFragment.onCreateView 花了 12.3ms，其中 9.8ms 在 inflate item_complex 布局
• CustomView 的 measure 阶段耗时最久（3.1ms），可能是 onMeasure 实现有问题
• 整个 doFrame 16.5ms，超过了一帧的 16ms 预算（60Hz），会导致掉帧

Python 端的调用链重建会把这条链完整还原出来，归因模块会自动关联到 item_complex.xml 和 CustomView.java，分析出布局嵌套和自定义 View 的性能问题。

实际的布局检测建议

根据实际使用经验，布局分析主要关注这几个指标：

inflate 耗时 > 5ms：布局文件可能过大或嵌套过深。一个合理的 item 布局 inflate 应该在 2-3ms 以内。

自定义 View 的 measure 耗时 > 2ms：通常说明 onMeasure 里有多次测量或复杂计算。

布局层级 > 4 层：在 RecyclerView item 里，4 层以上的嵌套会显著影响滑动性能，因为每个 item 的 measure/layout 都要递归遍历整棵 View 树。

这些判断标准不需要 LLM------它们是确定性的规则，秒级就能给出结论。这也是 SmartInspector 的设计理念：确定性分析优先，LLM 做补充。