(1)ActivityThread分析

1. 入口。

以前一直都说Activity的人口是onCreate方法。其实android上一个应用的入口,应该是ActivityThread。和普通的java类一样,入口是一个main方法。

public static final void main(String[] args) {
        SamplingProfilerIntegration.start();
       ……
        Looper.prepareMainLooper();
        if (sMainThreadHandler == null) {
            sMainThreadHandler = new Handler();
        }
        ActivityThread thread = new ActivityThread();
        thread.attach(false);
       ……
        Looper.loop();
       ……
        thread.detach();
        ……
        Slog.i(TAG, "Main thread of " + name + " is now exiting");
    }

下面仔细分析一下这个main方法。


2.Looper.prepareMainLooper();

ActivityThread其实就是我们经常说的UI thread,也就是主线程。我们都知道主线程可以使用Handler进行异步通信,因为主线程中已经创建了Looper,而这个Looper就是在这里创建的。如果其他线程需要使用Handler通信,就要自己去创建Looper。


3. sMainThreadHandler = new Handler();

创建一个Handler。


4. ActivityThread thread = new ActivityThread();

创建ActivityThread 对象。

ActivityThread 有几个比较重要的成员变量,会在创建ActivityThread对象时初始化。

(1)final ApplicationThread mAppThread = new ApplicationThread();

ApplicationThread继承自ApplicationThreadNative, 而ApplicationThreadNative又继承自Binder并实现了IApplicationThread接口。IApplicationThread继承自IInterface。这是一个很明显的binder结构,用于于Ams通信。IApplicationThread接口定义了对一个程序(linux的进程)操作的接口。ApplicationThread通过binder与Ams通信,并将Ams的调用,通过下面的H类(也就是Hnalder)将消息发送到消息队列,然后进行相应的操作,入activity的start, stop。

(2)final H mH = new H();

          private final class H extends Handler

mH负责处理ApplicationThread发送到消息队列的消息,例如:

public void handleMessage(Message msg) {
            if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + msg.what);
            switch (msg.what) {
                case LAUNCH_ACTIVITY: {
                    ActivityClientRecord r = (ActivityClientRecord)msg.obj;

                    r.packageInfo = getPackageInfoNoCheck(
                            r.activityInfo.applicationInfo);
                    handleLaunchActivity(r, null);
                } break;


5. handleLaunchActivity(r, null);

从名字中就可以看出,这里就将进行启动activity的工作了。

方法中主要调用了这一句:

Activity a = performLaunchActivity(r, customIntent);


6. performLaunchActivity()

进行了一些初始化和赋值操作后,创建activity。

activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);

然后调用:

mInstrumentation.callActivityOnCreate(activity, r.state);

这一句就会调用到acitivity的onCreate方法了,就进入了大多数应用开发的入口了。


<think>好的,用户现在问的是关于systrace的分析方法。之前他们询问过Android Camera Trace,我介绍了整体架构、工具和常见问题定位,其中提到过Systrace/Perfetto的使用。现在他们可能想更深入了解如何具体使用systrace来分析性能问题,尤其是在Android开发或调试中。 首先,我需要确定用户的背景。他们可能是Android开发者,或者测试人员,遇到了性能问题,比如应用卡顿、启动慢等,想用systrace来定位问题。也可能是刚接触Android性能优化,想学习工具的使用方法。 用户之前的问题涉及Camera Trace,可能他们现在的问题依然在摄像头相关的问题上,比如预览卡顿,或者想更广泛地了解systrace的应用。不管怎样,我需要详细解释systrace的使用步骤、分析方法以及常见场景。 我需要确保回答结构清晰,步骤明确,符合用户要求的逐步解决问题的方式。同时,要记住系统级指令,比如行内数学表达式用$...$,但这里可能用不上。需要检查LaTeX语法是否正确,不过systrace相关内容可能更多是代码块和命令行示例,需要注意格式。 另外,用户可能需要知道如何安装、捕获trace文件,以及如何解读结果。还要提到Perfetto,因为它是systrace的升级版,Android官方现在推荐使用。需要比较两者的区别,但可能用户更关注systrace的具体方法。 还要考虑常见错误或用户可能遇到的难点,比如权限问题,如何正确配置trace类别,如何过滤关键信息。同时,举一些例子,比如分析UI卡顿、Binder调用延迟等,让用户更容易理解。 需要注意不要遗漏关键点,比如工具的准备步骤,命令行参数,以及如何利用工具中的不同视图(比如线程、CPU频率)来分析性能。还要提醒用户注意时间段的选取,复现问题时的操作同步标记,比如使用按键或添加自定义事件。 最后,检查是否所有信息准确,比如命令的正确性,参数是否适用最新Android版本,是否需要root权限等。如果有不确定的地方,可能需要提到参考官方文档或厂商特定信息,但尽量保证回答的可靠性。</think>以下是 Systrace 的分析方法及步骤详解,帮助开发者定位 Android 系统或应用性能问题: --- ### 一、Systrace 基础概念 1. **作用**:捕获系统关键组件(如 CPU、SurfaceFlinger、Binder、App 主线程)的实时行为,生成时间轴可视化图表。 2. **底层原理**:基于 Linux 内核的 `ftrace` 机制,记录线程调度、锁竞争、IO 操作等事件。 3. **替代工具**:Android 10+ 推荐使用 **Perfetto**(功能更强大,操作类似)。 --- ### 二、抓取 Trace 文件 #### 步骤 1:安装 Python 环境 - 需安装 Python 2.7(Systrace 依赖)或使用 Android Studio 内置工具(推荐)。 #### 步骤 2:命令行抓取 Trace ```bash # 进入 Android SDK 的 platform-tools/systrace 目录 cd ~/Library/Android/sdk/platform-tools/systrace # 执行抓取命令(示例:抓取 10 秒,包含 app、sched、gfx 类别) python systrace.py -t 10 -o output.html sched gfx input view webview wm am app ``` - **常用参数**: - `-t N`:抓取时长(秒)。 - `-o file`:输出文件路径。 - `-a <包名>`:仅追踪特定应用。 - 类别列表:`gfx`(图形)、`input`(触控)、`sched`(CPU 调度)、`binder_driver`(Binder 调用)等。 #### 步骤 3(可选):通过代码插入标记 在应用中添加自定义事件(需 API 18+): ```java Trace.beginSection("MyCustomEvent"); // 你的代码 Trace.endSection(); ``` --- ### 三、分析 Trace 文件 #### 1. **整体观察 - **时间轴**:横向为时间,纵向为不同线程/进程。 - **关键区域**: - **Alerts**(红色警告):直接指出性能问题(如 UI 帧超过 16.6ms)。 - **CPU 频率**:检查 CPU 是否降频或满载。 - **主线程状态**:重点关注 `RUNNABLE`(执行中)、`SLEEPING`(休眠)、`Uninterruptible Sleep`(阻塞)。 #### 2. **UI 卡顿分析 1. **定位掉帧**: - 查看 `SurfaceFlinger` 的 `vsync` 信号间隔(正常 16.6ms/帧)。 - 检查 `Choreographer#doFrame` 的耗时(应用绘制时间)。 - **示例**:某帧耗时 30ms → 超出 16.6ms,触发掉帧。 2. **阻塞原因**: - **主线程阻塞**:查找主线程长时间处于 `RUNNABLE` 或 `Uninterruptible Sleep`。 - **锁竞争**:观察 `Monitor` 锁的等待时间(红色高亮)。 - **Binder 调用**:检查跨进程调用(如 `Binder.transact`)是否耗时过长。 #### 3. **CPU 调度分析 - **CPU 闲置**:检查是否有线程因等待 CPU 资源而长时间处于 `runnable` 状态。 - **核心负载不均**:观察任务是否集中在某几个 CPU 核心。 #### 4. **I/O 或网络延迟 - 查找 `binder`、`disk I/O` 或 `network` 相关线程的阻塞事件。 --- ### 四、快捷键与操作技巧 1. **导航**: - `WASD`:缩放/平移时间轴。 - `M`:标记选中区域的时间跨度。 2. **搜索**: - `Ctrl + F`:搜索关键词(如线程名、方法名)。 3. **查看详情**: - 点击事件查看参数(如锁名称、Binder 事务 ID)。 --- ### 五、典型案例分析 #### 案例 1:应用启动慢 1. 抓取应用启动期间的 Trace。 2. 分析主线程: - 检查 `ActivityThread` 的 `bindApplication` 和 `activityStart` 耗时。 - 定位 `ClassLoader` 或 `inflate` 布局的瓶颈。 #### 案例 2:列表滑动卡顿 1. 滑动列表时抓取 Trace。 2. 查找 `RecyclerView` 的 `onBindViewHolder` 或 `onDraw` 耗时。 3. 检查是否有主线程的磁盘读写(如 `SQLite` 操作)。 --- ### 六、注意事项 1. **抓取时间**:不宜过长(通常 5~20 秒),避免文件过大。 2. **复现问题**:抓取期间需手动复现问题(如卡顿场景)。 3. **结合其他工具**: - 使用 `dumpsys gfxinfo` 获取更详细的帧数据。 - 配合 `CPU Profiler` 或 `Perfetto` 进行深度分析。 通过 Systrace 的时间轴和事件详情,开发者可快速定位性能瓶颈,优化代码或系统配置。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值