使用ARM DS-5与Dstream StreamLine进行Android底层性能分析的一个实例
前言
一个类似于Android的OS，只使用了BT机能的状态下，CPU的占有率超过20%，于是我们想看看是什么原因。本篇文章注意介绍了使用Dstream StreamLine来进行性能分析的过程和实例以及可能需要注意的地方。
StreamLine准备
使用StreamLine来分析性能主要包含以下几个过程
- 配置内核使得内核可以产生一些性能相关的数据，以及一些设施用以支持gator，例如：高精度的timer(hr_timer)
- 安装gator模块，用于系统性能数据（scheduler，event，Process）的采集以及对这些数据进行注释(annotate)，例如对CP15中的PMNC(Performance Monitor Control Register)寄存器的读取与配置，对调度器数据的采集
- gatord从gator内核模块中获取性能数据，并通过网络(不一定是网线)传递给Host PC中的DS-5
- DS-5中的streamline对应软件模块对性能数据进行分析，以及与模块代码做出对应
对于前面的第一、第二步骤可以参考ARM官方的说明文档：ARM Streamline
编译与环境准备时候的注意点
如果使用的是adb 来让gatord传输数据到Host PC，那么需要将其中gator kernel module中的宏去掉(注释掉)：
If you are building for an Android target, you must remove the comment hashtag from the following line in the makefile of the gator module to enable kernel stack unwinding
# EXTRA_CFLAGS += -DGATOR_KERNEL_STACK_UNWINDING
StreamLine数据采集与配置
gatord 端口号被占用问题
默认情况下，gatord使用的端口号为8080，但是在运行了许多应用程序的OS中，有可能这个端口号已经被占用了，如果被占用了，那么gatord在运行的时候，会出现如下的log提示，询问我们是否已经运行了一个gatord实例了：
Is an instance already running?
此时，我们可以使用ps 来查看一下是否已经存在运行的gatord，如果没有，那么可以看看这个端口号被谁使用了：
lsof | grep 8080
如果没有lsof（android），那么可以使用netstat来查看：
netstat -ltpn | grep 8080
另外也可以修改代码，打印出提示log对应的errno，在gator-daemon中的main.cpp中，添加errno的头文件，在bind IP地址失败后打印出errno来。
如果确实被占用了，那么我们需要更改这个端口号，可以直接对main.cpp中的端口号8080进行更改，也可以在运行gatord的时候，使用-p选项进行指定，例如将端口号指定为8888：
gatord -p 8888&
使用USB-ADB来连接Target与Host
如果没有网线，但是有adb（在android手机中，几乎都有），那么就可以使用adb
在PC中将远程gatord的端口号转发到本地的某个端口号，例如也是8888：
adb forward tcp:8888 tcp:8888
性能数据的采集
添加少量的elf文件用于分析
在弹出的设置对话框中，在Program Images中可以添加elf文件，但是这里只能一个个的添加，无法大量按照特殊要求添加（例如只添加libQt***）：
Figure: Add_ELF_Files
添加大量的elf文件用于分析
如果要添加大量的elf文件，或者要按照我们特别的需求来添加大量的elf文件，那么就需要其他方法。
从前面的Figure: Setting图中，方框标明了这个Capture文件的位置：
<?xml version="1.0" encoding="UTF-8"?>
<session version="1" output_path="x" call_stack_unwinding="yes" parse_debug_info="yes" high_resolution="no" buffer_mode="streaming" sample_rate="normal" duration="0" target_type="ARM - Streamline Agent" target_address="localhost:8888" live_rate="100">
<image path="${streamline_results}/Test.apc/vmlinux"/>
<image path="${streamline_results}/Test.apc/app.so"/>
<image path="${streamline_results}/Test.apc/ld-linux.so.3"/>
<image path="${streamline_results}/Test.apc/libc.so.6"/>
<image path="${streamline_results}/Test.apc/libQtGui.so"/>
<image path="${streamline_results}/Test.apc/libQtCore.so"/>
<image path="/home/hexiongjun/work/obj/SHARED_LIBRARIES/libpthread.so.0_intermediates/LINKED/libpthread.so.0"/>
<energy_capture version="1" type="none">
<channel id="0" resistance="20" power="yes"/>
</energy_capture>
</session>
session.xml (END)
注意红色字体的部分，就是添加了的几个文件。同时注意这些elf文件的路径位置，它们被拷贝到了/home/hexiongjun/Documents/Streamline/Test.apc/中。
因此，现在问题就转换成了在session.xml文件中按照格式添加文件列表了。对于需要添加的的文件我们假设有两种：
- 添加所有elf的文件：内核+OS+App
- 只添加符号某一类条件的文件：例如libQt***
添加所有elf的文件
为了表示最极端的情况，这里假设需要将所有的OS相关elf文件、以及APP elf文件都添加进来。那么其实就是：
- kernel相关：vmlinux + kernel modules(ko)
- Application相关：可执行的应用程序，应用程序依赖的shared objects,以及so依赖的so
对于前者，直接添加即可，如果kernel module比较多，那么可以直接在kernel module_install中find一把，然后重定向到一个文件中，即可得到所有的ko文件路径列表。
对于后者，需要根据实际情况来处理，如果是Android环境下，那么所有的没有strip过的elf文件都放在：
out/target/$TARGETPRODUCT/symbols
即
$OUT/symbols
然后，使用find命令以及realpath命令来获取这些文件路径，然后拷贝到session.xml中，并使用编译器或者sed/awk，让这些文件列表符合xml语言语法接口，例如在VIM中可以使用下面命令来添加每行的结束字符串"/>：
:%s/$/\"\/\>
只添加符号某一类条件的文件
要包含某一类的lib，可以使用realpath：
realpath all_libs/libQt* >> ../list.txt realpath all_libs/libqt* >> ../list.txt
StreamLine采集数据的分析
在添加好elf image文件之后，就可以双击采集好的session来进行分析了，但是如果添加的文件比较多，有可能会出现如下的提示：
java heap space
对于此问题，可以参考我在ARM社区的提问：How to solve the Java heap space when streamline analyse the capture?
分析完成后，可以在Timeline标签中看到各个Process的CPU占有率。如下图中，bt线程使用了21.3%的CPU：
然后我们需要找到都是那些函数占用的CPU，切换到Call Paths标签可以看到：
参考
捕鱼达人用的游戏引擎cocos2d-x使用StreamLine的优化实例
Streamline profiler: Revealing reality
Software Optimization: Four real-life Streamline use cases
如果文章有格式问题，请移步：http://www.hexiongjun.com/?p=187
转载请注明出处。作者：TonyHo hexiongjun.com