Linux Tips
Record the commands that I use more frequently in the form of a memo, and will continue to increase according to usage in the future.
本文的动态图皆来自于莉迪亚·哈莉(Lydia Hallie) 的文章 CS Visualized: Useful Git Commands。
首先,我们来聊聊 VCS, Version Control System, 即版本控制系统的发展历史。
最初的时候,大家都是通过复制目录来进行版本管理,如下图:
这样做的缺点显而易见:
pstore, persistent storage
, 是一个存储内核日志或者内核 panic 的文件系统,内核会把相关信息存储在一个不能被其他用户重写的指定 RAM 区域,下一次启动时,这个区域会被挂载到 /pstore
,一般在 /sys/fs/pstore
, 这样我们就可以访问这些数据了。
pstore 在内核中的开关是 CONFIG_PSTORE,pstore 提供的是一套可扩展的机制,提供如下类型:
ramoops 指的是采用 ram 保存 oops 信息的一个功能,这个功能从 3.10.40 开始采用 pstore 机制来实现,内核中的开关控制:
How does the repo of android source code work ?
通常情况下, Android 的 .repo
里面有如下内容:
1 | $ ls .repo |
manifests
路径是项目 manifest 仓的 git checkout
,其中的 .git
是 manifest.git
的软链接,追踪 repo init --manifest-branch
指定的分支。
1 | .repo$ ls manifests/.git/ |
不管远程分支名字是什么,manifests
的本地分支命名为 default。
1 | .repo$ cat manifests/.git/HEAD |
manifests.git
是当前项目 manifest
仓的一个没有工作空间的 checkout
,即只 checkout
.git
,追踪repo init --manifest-url
指定的 Git 仓。不能手动修改这部分,如果需要修改的话,可重新运行 repo init
来更新设置。
缓存 manifests.git/config
,用来提升 repo
的速度。
repo
使用的 manifest
, 此文件由 repo init --manifest-name
指定链接到 manifests
中的哪一个文件,如下:
1 | manifest.xml -> manifests/<manifest-name>.xml # 指向用户希望用来同步源码的 manifest |
俗话说“雨过留痕,雁过留声”,之前因为工作需要折腾了小几个月的性能 BUG,还是得留下一点东西,这是第一篇:Android 性能调试手册,这篇文章简单聊聊工作中应该怎么进行性能分析。因为没有深入研究 Performance 相关内容,所以保留出错的权利。
在我司处理 Performance 问题时,大多数情况不会像顶级大厂那样优化每一帧,尽量榨干每一个硬件的性能。因为没有前人提供经验,全是自己总结的,如果存在有失偏颇的地方,你也只能看着。我理解的主要处理方式如下:
第一种,推不解。
第二种嘛,当然就是想办法解决或优化了。
针对任何性能问题,我觉得第一步都先需要做如下三个确认:
“雨过留痕,雁过留声”的第二篇:APP 启动,触摸事件和 UI 绘制的简单分析示例,此文通过 systrace 分析一个示例 APP 的启动、触摸事件和 UI 绘制的流程和时间消耗。本文的示例 APP (SimpleApplication.apk)只有一个简单的按钮, 点击按钮时会改变屏幕的颜色。同样因为没有深入研究 Performance 相关内容,所以保留出错的权利。
如果对第一篇感兴趣,请查看: Android 性能调试手册.
我一开始看到 systrace 文件时,是一脸懵逼的,所以在开始正文之前先简单说一下 systrace 文件中的一些基本信息,如下:
Frames
: 一个圆圈代表一帧。 Alerts
: 右侧标签,跟踪记录中出现的问题以及这些问题导致出现卡顿的频率system_server iq
: 第一帧的触发gfx3d_clk
: GPU 频率iq in systemsever
: 触发中断bindApplication, activityStart ...
: 表示冷启动, 热启动不会有这些信息。surfaceflinger
->UI Thread
->HIDL::IComposerClient:setPowerMode_2_2:client
: 代表 LCD 上电时间 一般使用 Chrome 打开 systrace.html, 右上角的
?
也可以提供一些基本的帮助
1 | a. python systrace.py gfx input view sched am wm dalvik freq idle power video app -b 40960 -t 10 -o traceout.html |
查看 system_server
的 iq
去定位点击事件发生的时间,如下:
查看 InputResponse 确认点击事件,如下:
粗略看一下 Frames
,发现有一个红色的 frame,红色表示 jank, 即卡顿。
上诉红点也就是代表帧率少于了 60 fps,我们需要去点击红色的圆点查看详细信息,并查看下 UI thread
,看看是否有无用的耗时或者阻塞发生。此案例中有 11 ms 左右的 sleep,如下:
此状态表示线程正在等待硬盘 I/O 操作完成,如果有太多的橙色阻塞状态,通常存在低内存的问题。此案例中阻塞状态很短,判断为正常状态,如下:
表明线程处于可运行状态,等待 CPU 调度。如果线程处于可运行状态时间太长,通常 CPU 忙于调度,需要查看这些时间 CPU 忙于哪些任务。比较常见的问题场景如下:
此案例中处于可运行状态的时间很短,如下:
接下来查看下线程的运行的时间,如果耗时异常,通常需要注意如下场景:
此案例中线程运行在大核上,即频率最高的 CPU7,亦无其他异常,如下:
## 4.4 White: Sleeping
此状态表示线程无事可做,处于休眠状态,一个概率比较大的情况是被 mutex 阻塞。
如上所示,我们可以看到大部分时间是消耗在运行状态,且没有频繁切换状态,所以这部分问题不是太大,当然如果想要追求更佳的性能,我们可以针对上面说的场景做更深入的调查。
从系统角度来看,在 Activity
完成 onCreate/onStart/onResume
阶段后,ViewRootImpl
将调用两次 performTraversals
去初始化 Egl、measure、layout、draw等,最后完成界面显示。
个人认为很难在 systrace 中获得准确的 APP 启动时间,但是我们可以在 activityResume 之后选择一个点来估算相对准确的时间。如下:
Launcher 调用 startingWindow 去等待第一帧的绘制,如下:
在如下指定位置,第一帧绘制已经完成。
在 SystemSever 中查看绘制流程。
InputReader 获取 input 事件,然后移交给 InputDispatcher. InputDispatcher 再将输入事件传递给对应的 App,然后请求 Vsync 去绘制第一帧。
主要检查 CPU 使用率、C-stage、时钟频率和时钟频率的限制,以及每个核正在跑什么应用。SimpleApplication 主要运行在大核 cpu7 上,有时运行在中核上, 都是最大频率。所以 CPU 部分没有什么问题。
前面主要是通过全局视图和启动视图来分析 systrace,下面将分析单击事件。但是我将跳过与前面类似的分析步骤, 只重点查看一些可能会影响 UI 切换速度的差异点。
SimpleApplication 在现阶段也主要运行在大核 cpu7 上且以最大频率运行,但是部分时间运行在限频状态下的大核和中核,如果需要对其进行优化,这是需要考虑的一点。
第一次单击时睡眠太久,也许这是一个可以优化的点。
之前折腾局域网搭建 Gitbook,并写了一篇简易教程:Gitbook + Jenkins + Gitlab 搭建内网自动构建的 Gitbook。最近兴趣使然又用 docker 搭建了一套方便部署的内网 Gitbook 镜像,因此也总结一篇简易教程如下。
1 | sudo apt install docker |
下载 Gitbook Docker 镜像,我选择了 billryan/gitbook 镜像:
1 | docker pull billryan/gitbook |
mkdir gitbook
创建一个 gitbook 路径,我们也可以将启动的镜像存储为另一个镜像:
1 | # init |
detached HEAD
is a common situation, sometimes useful, sometimes dangerous. It doesn’t point to any branches, so it will be cleaned by git
.
The current commit history is as follows:
1 | $ git log --oneline --all --graph |