android框架_5.0的SystemUI获取CPU负载以及进程cpu时间_014

最新推荐文章于 2024-06-26 15:43:45 发布
最新推荐文章于 2024-06-26 15:43:45 发布
阅读量2k 收藏 2
点赞数
分类专栏： Android框架
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wuwen__zhousi/article/details/80607442
版权


一、ProcessStats类；

１、Android源生系统中有一个叫ProcessStats类，用来获取系统的负载情况及进程时间；

public final class ProcessStats implements Parcelable {
    static final String TAG = "ProcessStats";
    static final boolean DEBUG = false;
    static final boolean DEBUG_PARCEL = false;

    public static final String SERVICE_NAME = "procstats";

２、 实现原理是读取/proc目录下的文件。linux系统运行时，内核会去更新 /proc目录下的文件，将pid的运行情况写入到/proc目录下对应文件中。

３、ProcessStats类只是一个继承Parcelable类的实体类，用来存储数据；

４、这个类会涉及到几个有用的文件： /proc/stat、/proc/loadavg、/proc/[pid]/；下面来说说这几个文件的作用和用途

４.1、/proc/stat，该文件包含了从系统启动开始累积到当前时刻的CPU活动信息。

　　看下后视镜的情况，cat /proc/stat的内容如下：

root@magc6580_we_l:/ # cat /proc/stat
cpu  162058 2972 358509 433432 1809 1 11476 0 0 0
cpu0 47425 758 98133 86127 439 1 3763 0 0 0
cpu1 44337 826 97981 95662 495 0 2977 0 0 0
cpu2 40722 756 94637 103627 504 0 2816 0 0 0
cpu3 29574 632 67758 148016 371 0 1920 0 0 0
intr 15498063 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3732026 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1989504 0 0 0 0 0 68871 0 0 7984 182387 11 1475 1 0 0 0 0 0 0 0 0 54963 51544 0 00
ctxt 32175008
btime 1528343324
processes 4288
procs_running 10
procs_blocked 1
softirq 3524467 427 963234 428 714933 434 427 71579 753458 44 1019503
root@magc6580_we_l:/ #
cpu 的每一列的意思如下
user (162058 ) 从系统启动开始累计到当前时刻，用户态的CPU时间（单位：jiffies） ，不包含 nice值为负进程。1jiffies=0.01秒
nice (2972 ) 从系统启动开始累计到当前时刻，nice值为负的进程所占用的CPU时间（单位：jiffies）
system (358509 ) 从系统启动开始累计到当前时刻，核心时间（单位：jiffies）
idle (433432 ) 从系统启动开始累计到当前时刻，除硬盘IO等待时间以外其它等待时间（单位：jiffies）
iowait (1809 ) 从系统启动开始累计到当前时刻，硬盘IO等待时间（单位：jiffies） ，
irq (1) 从系统启动开始累计到当前时刻，硬中断时间（单位：jiffies）
softirq (11476) 从系统启动开始累计到当前时刻，软中断时间（单位：jiffies）

最后的三个都是0,具体不知道做什么用
cpu0,cpu1,cpu2,cpu3代表系统有４个核；描述同cpu一样


其他的描述如下：
“intr”这行给出中断的信息，第一个为自系统启动以来，发生的所有的中断的次数；然后每个数对应一个特定的中断自系统启动以来所发生的次数。
“ctxt”给出了自系统启动以来CPU发生的上下文交换的次数。
“btime”给出了从系统启动到现在为止的时间，单位为秒。
“processes (total_forks) 自系统启动以来所创建的任务的个数目。
“procs_running”：当前运行队列的任务的数目。
“procs_blocked”：当前被阻塞的任务的数目。

4.2、/proc/loadavg文件
系统平均负载.该文件中的所有值都是从系统启动开始累计到当前时刻。该文件只给出了所有CPU的集合信息，不能该出每个CPU的信息；通过cat /proc/loadavg查看内容如下：

root@magc6580_we_l:/ # cat /proc/loadavg                                       
16.18 16.37 15.41 12/1408 4376
root@magc6580_we_l:/ #

每个值的含义为：

参数 解释
lavg_1 (16.18 )1-分钟平均负载
lavg_5 (16.37) 5-分钟平均负载
lavg_15(15.41) 15-分钟平均负载
nr_running (12) 在采样时刻，运行队列的任务的数目，与/proc/stat的procs_running表示相同意思
nr_threads (1408) 在采样时刻，系统中活跃的任务的个数（不包括运行已经结束的任务）

last_pid(4376) 最大的pid值，包括轻量级进程，即线程。


4.3、/proc/[pid]/文件

进程信息

1|root@magc6580_we_l:/ # cat /proc/40/stat                                     
40 (cmdq_auto_relea) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 0 -20 1 0 39 0 0 4294967295 0 0 0 0 0 0 0 2147483647 0 3221514176 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0
root@magc6580_we_l:/ # cat /proc/40/statm                                      
0 0 0 0 0 0 0
root@magc6580_we_l:/ # cat /proc/40/syscall                                    
0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
root@magc6580_we_l:/ #

二、ProcessCpuTracker类

public class ProcessCpuTracker {
    private static final String TAG = "ProcessCpuTracker";
    private static final boolean DEBUG = false;
    private static final boolean localLOGV = DEBUG || false;
　　//记录/proc下的信息
    private static final int[] PROCESS_STATS_FORMAT = new int[] {
        PROC_SPACE_TERM,
        PROC_SPACE_TERM|PROC_PARENS,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM,
        PROC_SPACE_TERM|PROC_OUT_LONG,                  // 10: minor faults
        PROC_SPACE_TERM,
        PROC_SPACE_TERM|PROC_OUT_LONG,                  // 12: major faults
        PROC_SPACE_TERM,
        PROC_SPACE_TERM|PROC_OUT_LONG,                  // 14: utime
        PROC_SPACE_TERM|PROC_OUT_LONG,                  // 15: stime
    };

    static final int PROCESS_STAT_MINOR_FAULTS = 0;
    static final int PROCESS_STAT_MAJOR_FAULTS = 1;
    static final int PROCESS_STAT_UTIME = 2;
    static final int PROCESS_STAT_STIME = 3;

    /** Stores user time and system time in jiffies. */
    private final long[] mProcessStatsData = new long[4];

１、此类为cpu跟踪记录类,首先看update方法更新了哪些信息；

public void update() {
    if (DEBUG) Slog.v(TAG, "Update: " + this);

    final long nowUptime = SystemClock.uptimeMillis();
    final long nowRealtime = SystemClock.elapsedRealtime();
    final long nowWallTime = System.currentTimeMillis();
    // 读取/proc/stat中的cpu时间
    final long[] sysCpu = mSystemCpuData;
    if (Process.readProcFile("/proc/stat", SYSTEM_CPU_FORMAT,
            null, sysCpu, null)) {
        // Total user time is user + nice time.
        final long usertime = (sysCpu[0]+sysCpu[1]) * mJiffyMillis;
        // Total system time is simply system time.
        final long systemtime = sysCpu[2] * mJiffyMillis;
        // Total idle time is simply idle time.
        final long idletime = sysCpu[3] * mJiffyMillis;
        // Total irq time is iowait + irq + softirq time.
        final long iowaittime = sysCpu[4] * mJiffyMillis;
        final long irqtime = sysCpu[5] * mJiffyMillis;
        final long softirqtime = sysCpu[6] * mJiffyMillis;

        // This code is trying to avoid issues with idle time going backwards,
        // but currently it gets into situations where it triggers most of the time. :(
        if (true || (usertime >= mBaseUserTime && systemtime >= mBaseSystemTime
                && iowaittime >= mBaseIoWaitTime && irqtime >= mBaseIrqTime
                && softirqtime >= mBaseSoftIrqTime && idletime >= mBaseIdleTime)) {
            mRelUserTime = (int)(usertime - mBaseUserTime);
            mRelSystemTime = (int)(systemtime - mBaseSystemTime);
            mRelIoWaitTime = (int)(iowaittime - mBaseIoWaitTime);
            mRelIrqTime = (int)(irqtime - mBaseIrqTime);
            mRelSoftIrqTime = (int)(softirqtime - mBaseSoftIrqTime);
            mRelIdleTime = (int)(idletime - mBaseIdleTime);
            mRelStatsAreGood = true;

            if (DEBUG) {
                Slog.i("Load", "Total U:" + (sysCpu[0]*mJiffyMillis)
                      + " N:" + (sysCpu[1]*mJiffyMillis)
                      + " S:" + (sysCpu[2]*mJiffyMillis) + " I:" + (sysCpu[3]*mJiffyMillis)
                      + " W:" + (sysCpu[4]*mJiffyMillis) + " Q:" + (sysCpu[5]*mJiffyMillis)
                      + " O:" + (sysCpu[6]*mJiffyMillis));
                Slog.i("Load", "Rel U:" + mRelUserTime + " S:" + mRelSystemTime
                      + " I:" + mRelIdleTime + " Q:" + mRelIrqTime);
            }

            mBaseUserTime = usertime;
            mBaseSystemTime = systemtime;
            mBaseIoWaitTime = iowaittime;
            mBaseIrqTime = irqtime;
            mBaseSoftIrqTime = softirqtime;
            mBaseIdleTime = idletime;

        } else {
            mRelUserTime = 0;
            mRelSystemTime = 0;
            mRelIoWaitTime = 0;
            mRelIrqTime = 0;
            mRelSoftIrqTime = 0;
            mRelIdleTime = 0;
            mRelStatsAreGood = false;
            Slog.w(TAG, "/proc/stats has gone backwards; skipping CPU update");
            return;
        }
    }

    mLastSampleTime = mCurrentSampleTime;
    mCurrentSampleTime = nowUptime;
    mLastSampleRealTime = mCurrentSampleRealTime;
    mCurrentSampleRealTime = nowRealtime;
    mLastSampleWallTime = mCurrentSampleWallTime;
    mCurrentSampleWallTime = nowWallTime;
 // 读取所有/proc/[pid]/文件夹中的进行信息
    final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskReads();
    try {
        mCurPids = collectStats("/proc", -1, mFirst, mCurPids, mProcStats);
    } finally {
        StrictMode.setThreadPolicy(savedPolicy);
    }
// 读取/proc/loadavg中的平均负载
    final float[] loadAverages = mLoadAverageData;
    if (Process.readProcFile("/proc/loadavg", LOAD_AVERAGE_FORMAT,
            null, null, loadAverages)) {
        float load1 = loadAverages[0];
        float load5 = loadAverages[1];
        float load15 = loadAverages[2];
        if (load1 != mLoad1 || load5 != mLoad5 || load15 != mLoad15) {
            mLoad1 = load1;
            mLoad5 = load5;
            mLoad15 = load15;
            onLoadChanged(load1, load5, load15);
        }
    }

    if (DEBUG) Slog.i(TAG, "*** TIME TO COLLECT STATS: "
            + (SystemClock.uptimeMillis()-mCurrentSampleTime));

    mWorkingProcsSorted = false;
    mFirst = false;
}

２、再来看看进程信息的方法：

private int[] collectStats(String statsFile, int parentPid, boolean first,
        int[] curPids, ArrayList<Stats> allProcs) {
		//获取全部PID
    int[] pids = Process.getPids(statsFile, curPids);
    int NP = (pids == null) ? 0 : pids.length;
    int NS = allProcs.size();
    int curStatsIndex = 0;
    //迭代PID，创建或更新PID对应的Stats对象
    for (int i=0; i<NP; i++) {
        int pid = pids[i];
        if (pid < 0) {
            NP = pid;
            break;
        }
        Stats st = curStatsIndex < NS ? allProcs.get(curStatsIndex) : null;
				// Stats对象已经存在，更新
        if (st != null && st.pid == pid) {
            // Update an existing process...
            st.added = false;
            st.working = false;
            curStatsIndex++;
            if (DEBUG) Slog.v(TAG, "Existing "
                    + (parentPid < 0 ? "process" : "thread")
                    + " pid " + pid + ": " + st);

            if (st.interesting) {
                final long uptime = SystemClock.uptimeMillis();

                final long[] procStats = mProcessStatsData;
                // 读取/proc/[pid]/stat文件中的信息至procStats
                if (!Process.readProcFile(st.statFile.toString(),
                        PROCESS_STATS_FORMAT, null, procStats, null)) {
                    continue;
                }

                final long minfaults = procStats[PROCESS_STAT_MINOR_FAULTS];
                final long majfaults = procStats[PROCESS_STAT_MAJOR_FAULTS];
                final long utime = procStats[PROCESS_STAT_UTIME] * mJiffyMillis;
                final long stime = procStats[PROCESS_STAT_STIME] * mJiffyMillis;
		// cpu用户时间系统时间没变化，设置Stats的active为false
                if (utime == st.base_utime && stime == st.base_stime) {
                    st.rel_utime = 0;
                    st.rel_stime = 0;
                    st.rel_minfaults = 0;
                    st.rel_majfaults = 0;
                    if (st.active) {
                        st.active = false;
                    }
                    continue;
                }

                if (!st.active) {
                    st.active = true;
                }
		// 从/proc/[pid]/cmdline中读取进程名
                if (parentPid < 0) {
                    getName(st, st.cmdlineFile);
                    if (st.threadStats != null) {
                        // 如果需要读取线程信息，怎从/proc/[pid]/task/中读取全部线程的信息
                        mCurThreadPids = collectStats(st.threadsDir, pid, false,
                                mCurThreadPids, st.threadStats);
                    }
                }

                if (DEBUG) Slog.v("Load", "Stats changed " + st.name + " pid=" + st.pid
                        + " utime=" + utime + "-" + st.base_utime
                        + " stime=" + stime + "-" + st.base_stime
                        + " minfaults=" + minfaults + "-" + st.base_minfaults
                        + " majfaults=" + majfaults + "-" + st.base_majfaults);
		// 设置Stats的值
                st.rel_uptime = uptime - st.base_uptime;
                st.base_uptime = uptime;
                st.rel_utime = (int)(utime - st.base_utime);
                st.rel_stime = (int)(stime - st.base_stime);
                st.base_utime = utime;
                st.base_stime = stime;
                st.rel_minfaults = (int)(minfaults - st.base_minfaults);
                st.rel_majfaults = (int)(majfaults - st.base_majfaults);
                st.base_minfaults = minfaults;
                st.base_majfaults = majfaults;
                st.working = true;
            }

            continue;
        }
	// Stats对象不存在，创建
        if (st == null || st.pid > pid) {
            // We have a new process!
            st = new Stats(pid, parentPid, mIncludeThreads);
            allProcs.add(curStatsIndex, st);
            curStatsIndex++;
            NS++;
            if (DEBUG) Slog.v(TAG, "New "
                    + (parentPid < 0 ? "process" : "thread")
                    + " pid " + pid + ": " + st);

            final String[] procStatsString = mProcessFullStatsStringData;
            final long[] procStats = mProcessFullStatsData;
            st.base_uptime = SystemClock.uptimeMillis();
            String path = st.statFile.toString();
            //Slog.d(TAG, "Reading proc file: " + path);
            if (Process.readProcFile(path, PROCESS_FULL_STATS_FORMAT, procStatsString,
                    procStats, null)) {
                // This is a possible way to filter out processes that
                // are actually kernel threads...  do we want to?  Some
                // of them do use CPU, but there can be a *lot* that are
                // not doing anything.
                st.vsize = procStats[PROCESS_FULL_STAT_VSIZE];
                if (true || procStats[PROCESS_FULL_STAT_VSIZE] != 0) {
                    st.interesting = true;
                    st.baseName = procStatsString[0];
                    st.base_minfaults = procStats[PROCESS_FULL_STAT_MINOR_FAULTS];
                    st.base_majfaults = procStats[PROCESS_FULL_STAT_MAJOR_FAULTS];
                    st.base_utime = procStats[PROCESS_FULL_STAT_UTIME] * mJiffyMillis;
                    st.base_stime = procStats[PROCESS_FULL_STAT_STIME] * mJiffyMillis;
                } else {
                    Slog.i(TAG, "Skipping kernel process pid " + pid
                            + " name " + procStatsString[0]);
                    st.baseName = procStatsString[0];
                }
            } else {
                Slog.w(TAG, "Skipping unknown process pid " + pid);
                st.baseName = "<unknown>";
                st.base_utime = st.base_stime = 0;
                st.base_minfaults = st.base_majfaults = 0;
            }

            if (parentPid < 0) {
                getName(st, st.cmdlineFile);
                if (st.threadStats != null) {
                    mCurThreadPids = collectStats(st.threadsDir, pid, true,
                            mCurThreadPids, st.threadStats);
                }
            } else if (st.interesting) {
                st.name = st.baseName;
                st.nameWidth = onMeasureProcessName(st.name);
            }

            if (DEBUG) Slog.v("Load", "Stats added " + st.name + " pid=" + st.pid
                    + " utime=" + st.base_utime + " stime=" + st.base_stime
                    + " minfaults=" + st.base_minfaults + " majfaults=" + st.base_majfaults);

            st.rel_utime = 0;
            st.rel_stime = 0;
            st.rel_minfaults = 0;
            st.rel_majfaults = 0;
            st.added = true;
            if (!first && st.interesting) {
                st.working = true;
            }
             // 创建的流程和更新差不多
            continue;
        }

        // This process has gone away!
        st.rel_utime = 0;
        st.rel_stime = 0;
        st.rel_minfaults = 0;
        st.rel_majfaults = 0;
        st.removed = true;
        st.working = true;
        allProcs.remove(curStatsIndex);
        NS--;
        if (DEBUG) Slog.v(TAG, "Removed "
                + (parentPid < 0 ? "process" : "thread")
                + " pid " + pid + ": " + st);
        // Decrement the loop counter so that we process the current pid
        // again the next time through the loop.
        i--;
        continue;
    }

    while (curStatsIndex < NS) {
        // This process has gone away!
        final Stats st = allProcs.get(curStatsIndex);
        st.rel_utime = 0;
        st.rel_stime = 0;
        st.rel_minfaults = 0;
        st.rel_majfaults = 0;
        st.removed = true;
        st.working = true;
        allProcs.remove(curStatsIndex);
        NS--;
        if (localLOGV) Slog.v(TAG, "Removed pid " + st.pid + ": " + st);
    }

    return pids;
}
使用这个类，来进行cpu负荷和进程时间的监控。Android5.1系统在systemui中有一个服务，就使用了这个类。

在systemui的Manifest文件，可以找到一个叫LoadAverageService的服务，它就是使用了ProcessCpuTracker获取cpu和进程信息，并把他们显示出来。

如何使用LoadAverageService这个服务,方法有两种：
１、可以在adb shell中直接运行am startservice -n com.android.systemui/.LoadAverageService
２、用【设置】->【开发者选项】->【显示cpu使用情况】打开服务桌面上即可显示cpu占用情况


在开发应用的时候，开启这个选项，可时时跟踪系统的cpu占用情况












rockyvogue
关注
专栏目录
Android性能优化高阶：卡顿、ANR、死锁，线上如何监控？
chenjingsb的博客
06-16 2201
一、前言 最近参加了几轮面试，发现很多5-7年工作经验的候选人在性能优化这一块，基本上只能说出传统的分析方式，例如ANR分析，是通过查看/data/anr/ 下的log，分析主线程堆栈、cpu、锁信息等， 然而，这种方法有一定的局限性，并不是每次都奏效，很多时候是没有堆栈信息给你分析的，例如有些高版本设备需要root权限才能访问/data/anr/ 目录，或者是线上用户的反馈，只有一张ANR的截图加上一句话描述。 假如你的App没有实现ANR监控上报，那么你大概率会把这个问题当成“未复现”处理掉，而没有真正
Android绘制优化与内存优化
nanquan11的博客
03-23 716
文章目录一、绘制优化1.绘制原理2.卡顿原因3.使用GPU渲染模式分析工具进行分析4.使用系统跟踪Systrace工具进行分析5.使用CPU分析器工具进行分析5.1使用 Debug API 记录 CPU 活动5.2导入跟踪数据6.使用布局优化工具进行分析6.1使用布局检查器和布局验证工具调试布局6.2 Android Lint工具7.布局优化方法7.1合理运用布局7.2使用Include标签来进行布局复用7.3使用Merge标签去除多余层级7.4使用ViewStub来提高加载速度8.避免GPU过度绘制二、内
ANR系列之一：ANR显示和日志生成原理讲解
分享+记录
10-12 5462
序言 前几天有人问我，什么时候会触发ANR？随口回答，主线程卡顿并且有输入操作未被响应的时候，会触发ANR，这应该也是网上标准的答案了。但是仔细想一想，好像debug调试的时候没有点击也会出现应用没有响应的问题。好吧，那我们就带着这个问题，去一步一步的看一下，安卓什么时候会触发ANR。 一.程序无响应Dialog的入口 排查这个问题，我们首先要找到排查问题的入口。造一个程序无响应的场景，然后打开uiautomatorviewer工具查看布局。首先我们看到的是下面这样一个场...
Android 性能优化——ANR监控与解决
maniuT的博客
04-12 2026
ANR(Application Not responding):如果 Android 应用的界面线程处于阻塞状态的时间过长，会触发“应用无响应”(ANR) 错误。如果应用位于前台，系统会向用户显示一个对话框。ANR 对话框会为用户提供强制退出应用的选项。 ANR 是一个问题，因为负责更新界面的应用主线程无法处理用户输入事件或绘制操作，这会引起用户的不满
使用 ADB 查看 Android 设备的 CPU 使用率（详解）
最新发布
WriteBug001的博客
06-26 4411
希望这篇文章对你在 Android 开发过程中监控 CPU 使用率有所帮助。
Android ANR log trace日志文件分析
qq_25330791的博客
05-23 1935
如果CUP使用率很低,说明主线程被阻塞了,并且当IOwait很高,可能是主线程在等待I/O操作的完成.traces.txt只保留最后一次ANR的信息,Android系统有个DropBox功能功能,它能记录系统出现的crash错误.因此保留有发生过的ANR的信息.(log路径:/data/system/dropbox)应用ANR产生的时候,ActivityManagerService的appNotResponding方法就会被调用,然后在/data/anr/traces.txt文件中写入ANR相关信息.
MTK Android手机进程列表
travellers的专栏
01-18 886
root@android:/ # ps USER PID PPID VSIZE RSS WCHAN PC NAME root 1 0 9048 864 001c7ca8 00437e64 S /init root 2 0 0 0 000c21c4 00000000 S k...
深入解析：Android卡顿检测及优化项目实战经验总结
chuhe1989的博客
06-19 1926
前言 之前在项目中做过一些Android卡顿以及性能优化的工作，但是一直没时间总结，趁着这段时间把这部分总结一下。 GitHub系统教程学习地址：https://github.com/Timdk857/Android-Architecture-knowledge-2- 包括【面试专题】、【Jetpack】、【Android framework全套学习笔记】、【flutter全套教程】、【微信小程序全套教程】、【全方位性能优化专题】持续更新中~~ 欢迎白嫖、标星、指教~~ 作者：Hanking 链接：
Android面试从新手到架构师，一篇解析就够(1)，跳槽字节跳动
m0_60607609的博客
09-07 288
5.抽象工厂模式： 结构型（7）：描述如何将类或对象按某种规则组成更大的结构 1.桥接模式：对于两个或以上纬度独立变化的场景，将抽象与具体实现分离，实例：用不同颜色画不同形状 2.外观模式：对外有一个统一接口，外部不用关心内部子系统的具体实现，这是"迪米特原则"的典型应用 3.适配器模式：改变类的接口，使原本由于接口不匹配而无法一起工作的两个类能够在一工作，实例：RecycleView 的 Adapter 不管什么类型的 View 都返回 ViewHolder 4.代理模式：由代理对..
系统角度解读Android P新特性
Gityuan的博客
04-15 7526
引言2018年3月8日，谷歌发布了Android P的预览版，预计今年的Q3季度发布final release版本，有不少文章从开发者角度介绍了Android P的新特征，初步来看给感觉这次大版本似乎并没有什么改变。接下来，将从系统Treble，System，Framework，Runtime, Security等多方面来解读一下Android P的变化。这是我的微信公众号：Android达摩院(...
史上最全的Android面试题集锦
weixin_45258969的博客
07-30 4838
前言 很多人面试之前，可能没有在互联网公司工作过或者说工作过但年头较短，不知道互联网公司技术面试都会问哪些问题？ 再加上可能自己准备也不充分，去面试没几个回合就被面试官几个问题打蒙了，最后以惨败收场。 下述是我收录整理的Android面试题汇总，由于篇幅原因，在这之前都是把每一小节分开列出来，这次全部发出来，后续还会更新其余面试题内容，大家可以 关注 一下我，及时知晓我更新的知识点，同时这份面试集...
卡顿、死锁、ANR原理，线上监控方案分析
Androiddddd的博客
06-15 825
一、前言 最近参加了几轮面试，发现很多5-7年工作经验的候选人在性能优化这一块，基本上只能说出传统的分析方式，例如ANR分析，是通过查看/data/anr/ 下的log，分析主线程堆栈、cpu、锁信息等， 然而，这种方法有一定的局限性，并不是每次都奏效，很多时候是没有堆栈信息给你分析的，例如有些高版本设备需要root权限才能访问/data/anr/ 目录，或者是线上用户的反馈，只有一张ANR的截图加上一句话描述。 假如你的App没有实现ANR监控上报，那么你大概率会把这个问题当成“未复现”处理掉，而没有真正
WatchDog工作原理
omnispace的博客
05-19 2709
一、概述 Android系统中，有硬件WatchDog用于定时检测关键硬件是否正常工作，类似地，在framework层有一个软件WatchDog用于定期检测关键系统服务是否发生死锁事件。WatchDog功能主要是分析系统核心服务和重要线程是否处于Blocked状态。 监视reboot广播；监视mMonitors关键系统服务是否死锁。 二、WatchDog初始化 2.1 st
Android源码浏览器的性能分析工具类
苏法迪的专栏
01-13 734
一、Performance.java 本来想查看 proc/stat文件的，居然发现系统源码还有如此好东西，即查看浏览网页的各种事件计算，进行辅助性能分析。 有需要的童鞋拿去吧，我只是搬运工 String performanceString = "It took total " + (SystemClock.uptimeMillis() - mStart) +
给解决问题ANR一个印象
baidu_32472003的博客
09-30 4358
简介 现在感觉自己做的工作，基本上脱离Android了就是用java写代码，而且可能试用期完了就会被刷，很多东西是公司自己的，完全不知道怎么下手研究，导师指导也就是几句话的说你看下哪里哪里的代码。要不是旁边的一个大牛，我是真的走不下去了。大佬们，要是被刷求介绍工作,不怕加班，只怕没有讨论没有指导。 写这篇博客另外感谢之前小米的同事，她在北邮念完研究生，但是却很低调，她是很好的学姐，她当时工作就...
Android 分析ANR和死锁
热门推荐
好久不见
09-22 3万+
Android 分析ANR和死锁
Android CPU使用率：top和dump cpuinfo的不同
oujunli的专栏
05-20 1万+
CPU是系统非常重要的资源，在Android中，查看CPU使用情况，可以使用top命令和dump cpuinfo。我记得很久以前，就发现这两者存在不同，初步猜测应该是算法上存在差异。最近需要采集应用CPU的使用率，看了一下两种CPU的计算方法。1、toptop是比较经典的CPU计算方法，top的代码在androidm/system/core/toolbox/top.c下面，输出process的cpu
android高级程序开发-app启动流程
我是小小舒
02-28 373
Android系统启动流程分析：之所以分析它，是为了更好的理解整个系统，也有助于我们后面的学习，更深入理解我们Android App的启动流程一、开机流程：开机后会加载引导程序BootLoader，它是Android系统运行的第一个程序，在操作系统运行之前运行。BootLoader主要功能：1.检查RAM，初始化硬件参数等功能；2.拉起操作系统二、初始化内核Kernel：完成了内核的大部分初始化工...
bluesoleil_5.0
09-12
Bluesoleil_5.0是一款蓝牙驱动程序和管理工具，它可以在计算机上提供蓝牙功能。它兼容多个蓝牙设备，包括手机、耳机、键盘、鼠标等。 Bluesoleil_5.0具有简单易用的界面，用户可以轻松连接和管理蓝牙设备。它提供了...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值