Android调试优化篇

时间 2019-11-16

原文原文链接

为了开发出商业级的应用程序，大规模的測试是不可避免的，同一时候为了提升应用程序的执行速度，需要进行必要的优化。在Android中。提供了丰富的调试与优化工具供开发者应用，主要包含模拟器和目标端等两种场景下使用的工具。java

1.Android调试linux

软件调试是一个伴随软件开发的一定过程。好的调试环境和工具可以提升开发的效率。在Android中，除了提供GDB调试外。还提供了DNSS、Logcat、Dmtracedump、DevTools、Procrank、Dumpsys等开发工具供开发人员使用，当中DMSS包括了多个组件。android

当发生Android ANR错误时，错误信息会保存在\data\anr\traces.txt中，这有助于在没法实时查看日志的状况下分析Bug。shell

（1）Logcat日志调试安全

android.util.Log常用的方法有下面5个：Log.v()、Log.d()、Log.i()、Log.w()及Log.e()。其分别相应VERBOSE、DEBUG、INFO、WARN、ERROR等不一样等级。性能优化

开发人员可以依据场景的不一样选择不一样的方法。普通状况下，对于纯粹的调试信息。笔者建议採用Log.d()方法。网络

需要说明的是。android.util.Log仅适用于应用层，对于框架层的调试。需要使用android.util.slog类。app

C/C++依旧支持log的输出。框架

（2）dmtracedump跟踪eclipse

dmtracedump是一个基于图形界面的使用方法间调用关系的工具。在使用dmtracedump前，必须安装Graphviz，在Linux下安装Graphviz的方法例如如下：

#apt-get install graphviz

dmtracedump的使用方法例如如下：

dmtracedump [-ho] [-s sortable] [-d trace-base-name] [-g outfile] <trace-base-name>

在实际操做中，为了分析函数间的调用关系。首先要在需要分析的方法中设置跟踪的起始点和结束点，方法例如如下：

開始跟踪：Debug.startMethodTracing("loadEvents"); //输出文件为loadEvents.trace

结束跟踪：Debug.stopMethodTracing();

程序执行结束后，就能够在\sdcard下看到loadEvents.trace就能够分析时间关系和方法调用关系。固然这是文本界面的，要经过图形界面来显示就要用到dmtracedump。方法例如如下：

#dmtracedump -g out.png clac.trace

浏览out.png就能够看到相关函数调用关系图，其结点的格式例如如下：

<ref> callname (<inc-ma>,<exc-ms>,<numcalls>)

上述格式中，ref表示编号，callname表示方法名。inc-ms表示调用事件，exc-ms表示运行时间。numcalls表示运行次数。

（3）Dev Tools调试

Dev Tools是Android特有的、帮组在物理设备上开发调试应用的工具。默认在SDK中存在。

经过Dev Tools可以打开一些设备帮组调试的设置，如USB的设备等。还可以查看安装包、启动终端等，这些对开发人员在物理设备上调试应用显得十分实用。

（4）屏幕截图分析

还有一个简单却十分实用的工具是DDMS下的screen capture工具。经过它，开发人员可以直接截图，供本身或同事进行对应的分析，这在需要沟通的场景中十分实用。

screen caption工具支持界面的手工刷新和旋转，其保存图片的格式为PNG。

眼下screen capture工具对视频播放尚没法提供有效的支持。这多是由于视频帧速率过快，而screen capture工具尚没法支持这么高的帧速率致使的。

（5）内存调试

内存调试不只限于C、C++等原生代码。Java也相同需要，在Android中。有多个工具如DDMS、Procrank、Dumpsys等可以获取系统执行期的内存信息，这些信息十分有助于进行内存调试。

1）DDMS内存调试

在Eclipse中集成的DMSS并无呈现出全部的DMSS能力，假设但愿观察系统更具体的信息。可以直接启动DK\tools\ddms。

2）Dumpsys内存调试

经过Dumpsys可以进行很是多分析。其分析内存的方法为adb shell dumpsys meminfo。

3）Procrank内存调试

另外，经过adb shell procrank也可以查看到进程占用内存的状况，当中Uss（Unique Set Size）的大小表明属于本进程正在使用的内存大小。这些内存在该进程被撤销后。会被全然回收，Uss也是进行内存泄露观察时的重点：Vss（Virtual Set Size）和Rss（Rsdident Set Size）表示共享库的内存使用，但是由于共享库的资源通常占用比較大，所以会使进程自身建立引发的内存波动所占比例减少。而Pss（Proportional Set Size）则依照比例进行共享内存切割。

经过间隔性地执行Procrank来观察进程占用Uss内存的变化。可以分析应用是否存在内存泄露。Procrank的代码位于system\extras\procrank目录。Procrank的使用方法为：

procrank [-W] [-v | -r| -p| -u| -h]

考虑到Android是基于Dalvik虚拟机的，垃圾回收并非实时的。故经过单个界面的单次启动、关闭是没法肯定内存是否泄露的。

一个号的策略是反复运行某个界面的启动、关闭。假设发现应用占用的内存不断上升，则可以推断该界面存在内存泄露。

4）Eclipse插件内存调试

在Eclipse中，有一个插件MAT（Memory Analyzer Tool）可以帮组分析Java层的内存泄露，其下载地址为http://www.eclipse.org/mat/。

MAT分析的是hprof文件，该文件里存放了进程的内存快照。

如下是从终端获取hprof文件的方法：

#adb shell

#ps //查看进程号

#chmod 777 /data/misc

#kill -10 PID //PID即进程号

这样就能够在\data\misc文件夹下生成一个带当前时间的hprof文件，但这个文件并不能直接被MAT读取，开发人员需借助hprof-conv将hprof转换为MAT可以读取的格式，而后才可用MAT进行分析。

hprof-conv的使用方法例如如下：

hprof-conv <infile><outfile>

2.Android布局优化

为了实现精细的布局。Android提供了两个Android布局优化，即Layoutopt和Hierarchyviewer。当中Layoutopt可以优化布局，帮组开发人员下降冗余信息，而Hierarchyviewer则可直接调试用户界面。

（1）Layoutopy优化

Layoutipt是一个优化布局的工具。它可以帮组开发人员分析採用的布局是否合理。并给出改动意见，其使用方法是：

layoutopt <directories/files to analyze>

详细方法例如如下：

layoutopt res/layout-land

layoutopt res/layout/main.xml

Layoutopt可以指出有问题的代码所在的位置和出问题的解决办法，还可以给出优化的建议。

（2）Hierarchyviewer优化

Hierarchyviewer赞成开发人员调试和优化用户界面。

一般Hierarchyviewer开发人员可以清晰地看到当前设备的UI界面的实际布局和控件属性，这在复杂界面的调试中显得很实用。可以帮助开发人员高速定位问题。固然出于安全性考虑，Hierachyviewer仅能优化debug模式的应用。

发起Hierarchyviewer优化的过程例如如下：

1）启动物理设备或模拟器。

2）执行应用至欲优化的界面。

3）在终端启动Hierarchyviewer（位于SDK的tools文件夹下）。

4）选择设备和Activity。

Hierarchyviewer提供了两个层次的分析界面，即视图界面和像素界面。在Herarchyviewer的视图界面中，开发人员可以清晰地看到布局文件的层次关系。针对特定的UI控件，开发人员可以清晰地看到控件在屏幕上的位置以及各属性的值。

熟练使用Hierarchyviewer，可以加快UI调试效率。

3.Android測试

Android提供的几种測试工具可以帮组开发人员最大限度地提高开发质量和应用程序的兼容性。

这些測试工具中最重要的两个为Monkey压力測试工具和CTS兼容性測试工具。

（1）Monkey压力測试

Monkey工具可以模拟各类按键、触屏、轨迹球、导航、Activity等事件。此工具使用方法例如如下：

adb shell monkey [option] <event-count> //特定事件

adb shell monkey -p your.packege.name -v 50000 //50000随机事件

为了使开发的应用程序具备必定的稳定度，在使用前建议进行Monkey压力測试。需要注意的是。Monkey压力測试仅能模拟系统事件监測应用中存在的语法Bug，对于深层次的语义Bug依旧无能为力，而且对于网络功能。Monkey压力測试也没法进行有效的測试。

由于Monkey是经过载入特定Activity（category属性需为android.intent.category.LAUNCHER或android.intent.category.MONKEY）做为程序入口来进行測试的，故在进行Monkey压力測试时，easy造成孤岛的Activity，为了进行全面測试，需要为其添加Intent过滤器。对应的參考实现例如如下：

<intent-filter>

</intent-filter>

</activity>

需要注意的是。假设仅仅针对单个应用进行压力測试，Monkey会阻止对其它包的调用，固然针对单个应用的压力測试没法检測应用间交互可能存在Bug。为了測试系统内应用交互与冲突带来的问题，可以针对系统进行Monkey压力測试，方法例如如下：

#adb shell monkey -p -v 50000

在进行Monkey压力測试的过程当中。Monkey会因为应用奔溃、网络超时及一些没法处理的异常而中止測试。建议在对网络应用进行压力測试时，忽略网络超时的状况，方法例如如下：

#adb shell monkey -p your.package.name -v 50000 --ignore-timeouts

假设但愿忽略应用奔溃的状况，那么可运行例如如下方法：

#adb shell monkey -p your.package.name -v 50000 --ignore-crashes

在进行压力測试时。假设发生异常状况。如系统奔溃。那么Android会本身主动打印出相关的系统信息（如内存分配等）供开发人员分析。

另外，为了更好地进行Monkey压力測试，需要使外围设备的配置保持和实际产品一样，如默认的键盘时QWERTY键盘（这对于没有物理键盘的产品不适用）。

（2）JUnit回归測试

JUnit回归測试即白盒測试，通常用在单元測试场景中，如对非图形界面的接口的測试，这在开发框架性代码时很实用。

Android仅支持JUnit3，尚不支持JUnit4。

在Android中。Google对JUnit进行了封装，Android JUnit还支持图形界面如Activity、View等的測试。甚至支持对图形界面接口的功能压力測试。

Android JUnit的内容分主要分布在android.text中，另外android.text.mock和android.text.suitebuilder也提供了一些辅助和支持。

依据约束的不一样。測试可以分为SmallTest、MediumTest、LargeTest、AndroidOnly、SideEffect、UiThreadTest、BrokenTest、SmokeSuppress等。当中AndroidOnly、表示測试项仅适用于Android。SideEffect表示測试项具备反作用；UiThreadTest表示測试项在UI主线程中执行；BrokenTest表示測试项需要修复。Smoke表示測试项为冒烟測试；Suppress表示该測试项不该出现在測试用例中。

为了进行JUnit回归測试，需要在Eclipse中建立Android Test Project，可经过运行File-New-Other-Android-Android Test Project命令完毕，运行測试的方法为右击project项，在弹出的菜单中运行run as-android JUnit Test命令。对于具备多个Instrumentation-TestRunner的測试project。在运行測试时。应该先在project的Run Configurations中指明InstrumentationTestRunner。測试完毕后，会本身主动给出測试结论。

在物理设备上借助Dev Tools也可以作JUnit測试，固然，经过am命令也可以运行JUnit測试。只是这样的方法比較繁琐。

1）JUnit測试的框架

Junit測试主要包含TestCase、Instrumentation等。

为了执行測试用例。必须将測试用例加入到TestSuite中。经过Instrumentation来管理。測试用例的继承关系例如如下图：

除了上面的測试用例外。开发人员还可以经过PerformanceTestCase运行性能測试。注意，ProviderTestCase和ActivityInstrumentationTestCase已经被抛弃，应慎用。

InstrumentationTestRunner主要经过AndroidTestRunner的支持被载入的。AndroidTestRunner的继承关系例如如下图所看到的：

AndroidTestRunner继承了TestListener接口，用来发起和结束測试，生成測试报告，当中发起执行測试的方法为runTest()，这才是JUnit測试的核心。

2）JUnit測试的实现

经过JUnit进行回归測试，需要作例如如下几方面的工做：

构建AndroidMainifest.xml配置文件。

制定InstrumentationTestRunner文件。

构建详细測试代码。

假设是基于源码进行的測试，那么还需要构建Android.mk文件。

（1）构建AndroidMainifest.xml配置文件

和普通project相似的是。JUnit回归測试project需要构建AndroidMainfest.xml配置文件；但和普通project不一样的是。JUnit回归測试project没有图形界面，必须声明要用到“android.test.runner"JAR包，声明对应的Instrumentation TestRunner。在经过SDK建立測试project时，AndroidMainfest.xml会本身主动生成，默认的InstrumentationTestRunner为android.testRunner。在某些状况下。开发人员需要定义InstrumentationTestRunner。如下是JUnit回归測试的AndroidMainfest.xml文件的实现：

<mainfest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.android.calcutor2.tests">

<use-library android:name=”android.test.runner"/>

<instrumentation android:name="CalculatorLaunchPerformace" //仅在源码下可用

android:targetPackage="com.android.calculator2"

android:label="Calculator Launch Performance">

</instrumentation>

<instrumentation

android:name="android.test.InstrumentationTestRunner"

android:targetPackage="com.android.calculator2"

android:label="Calculator Funstional Testset">

</instrumentation>

</manifest>

（2）指定InstrumentationTestRunner文件

InstrumentationTestRunner文件为Junit測试的入口文件，在某些状况下本身定义InstrumentationTestRunner类。最重要的是addTestSuite方法。他将TestCase归入TestSuite流程，调用对应的方法。步骤例如如下：

public class MusicPlayerFunctionalTestRunner extends InstrumentationTestRunner{

public TestSuite getAllTests(){

TestSuite suite=new InstrumentationTestSuite(this);

suite.addTestSuite(TestSongs.class);

suite.addTestSuite(TestPlaylist.class);

suite.addTestSuite(MusicPlayerStability.class);

retuen suite;

}

public ClassLoader getLoader(){

return MusicPlayerFunctionnalTestRunner.class.getClassLoader();

}

（3）构建详细測试代码

为了測试详细的代码，需要依据组件的类型构建对应的測试用例。当中。有两个关键的方法要注意：setUp方法用来构建測试环境，如打开网络连接等；tearDown方法可以确保在进入下一个測试用例前所有资源被销毁并被回收。

对于不一样的測试，应该配置不一样的測试类型。測试Activity的用例的实现例如如下：

public class SpinnerTest extends ActivityInstrumentationTestCase2<RelativeLayoutStubActivity>{

private Context mTargetContext;

public SpinnerTest(){

super("com.android.cts.stub", RelativeLayoutStubActivity.class);

}

protected void setUp() throws Exception{

super.setUp();

mTargetContext=getInstrumentation().getTargetContext();

}

protected void tearDown() throws Exception{

super.tearDown();

}

public void testGetBaseline(){ //測试项方法必须以test开头

Spinner spinner=new Spinner(mTargetContext);

assertEquals(-1, spinner,getBaseline());

spinner=(Spinner)getActivity().findViewById(R.id.spinnere1);

ArrayAdapter<CharSequence> adapter=ArrayAdapter.createFromResource(mTargetContext, com.android.cts.stub.R.array.string, android.R.layout.simple_spinner_item);

adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);

spinner.setAdapter(adapter);

assertTrue(spinner.getBaseline() > 0);

}

（4）构建Android.mk文件

在源码中进行编译。必须构建Android.mk文件。和普通Android.mk文件不一样，Android.mk文件需要指定LOCAL_MODULE_TAGS为tests。经过LOCAL_JAVA_LIBRARIES变量载入android.test.runner的JAR包。经过LOCAL_INSTRUMENTATION_FOR指定对那个包进行回归測试。如下是进行JUnit回归測试的Android.mk实现：

LOCAL_PATH:=$(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE_TAGS:=tests //指定TAGS为“tests”

LOCAL_JAVA_LIBRARIES:=android.test.runner //载入名为android.test.runner的JAR包

LOCAL_SRC_FILES:=$(call all -java-file-under, src)

LOCAL_PACKAGE_NAMES:=CalculatorTests //包名

LOCAL_INSTRUMENTATION_FOR:=Calculator //指定为那个project作回归測试

include $(BUILD_PACKAGE)

利用JUnit进行回归測试时，假设在控制台上发现例如如下错误提示：

Application does not specify a android.test.InstrumentationTestRunner instrumentation or does not declare uses-library android.test.runner

应检查AndroidManifest.xml的配置是否正确。假设Eclipse弹出提示信息“No tests found with runner 'JUnit 3'，应检查測试项目目的Run Configurations中InstrumentationTestRunner的配置是否有误。

（3）CTS兼容性測试

为了防止OEM厂商对Android的定制致使平台的不兼容问题，Google在公布Android版本号的同一时候会公布相关的CTS測试。编译CTS和启动交互CTS控制台的方法例如如下：

cd /path/to/android/root

make cts

cts

运行CTS測试并设置測试參数的方法例如如下：

cts start --plan CTS -p android.os.cts.BuildVersionTest

需要说明的是，为了保持Android系统间的兼容性，Google规定，必须经过CTS兼容性測试，才会授予OEM厂商Android商标和接入Android Market的权利。

CTS兼容性測试对于很多OEM厂商甚至芯片厂商而言，是没法全然经过的。

（4）目标环境測试

在实际的开发过程当中。假设临时没法得到物理设备进行測试，考虑到目标环境的差别，应该针对目标物理设备构建本身定义的模拟器。这就是所谓的目标环境測试。

1）硬件配置

硬件的配置可以经过AVD管理器在建立模拟器时设置，固然之后也可以变动。在默认Eclipse工做空间的登陆用户为root的状况下，AVD的配置位于\root\.android\avd\avdname.avd文件夹下的config.ini中。

如下是一个config.ini的配置：

hw.lcd.density=160

sdcard.size=200M

skin.name=WVGA800

skin.path=platforms/android-8/skins/WVGA800

hw.cpu.arch=arm

abi.type=armeabi

vm.heapSize=24

image.sysdir.1=platforms/android-8/images

除了以上硬件信息外。开发人员开可以配置摄像头、电池、耳机、麦克风、GPS、LCD背光等。

另外\root\.android\avd\avdname.avd\hardware-qemu.ini中给出了和硬件相关的全然配置。

在模拟器执行时，会检查config.int和hardware-qemu.int中相应的配置项是否一致。当不一致时。依据config.int中的配置来改动hardware-qemu.int中的配置。

2）网络模式

在Android模拟器中，童工AVD管理器还可以模拟网络，如是否支持GSM。经过project的Run Configuration可以选择网络速度，其类型包含Full、GSM、HSCSD、GPRS、EDGE、UMTS、HSDPA等；还可以选择网络延迟。其类型包含None、GPRS、EDGE、UMTS等。这些在开发具备卓越用户体验的移动终端时很重要。

网络配置会在模拟器启动时做为參数传递给模拟器。

3）通话/SNS/模拟

在DDMS中，Andoid支持通话/SMS的測试。

在DDMS面板中，选择好网络状态，如unregistered、home、roaming、searching、denied等。作好速度和延迟配置。以后就能够測试语音、数据和SMS。

关于网络状态和无线接入协议的详细含义。涉及无线通讯的协议栈内容。

4）GPS模拟

Android还支持GPS模拟。可以明白指定经纬度，还可以载入GPX、GML等轨迹文件。

4.Android性能优化

尽管眼下的Android终端广泛配置了ARM Cortex A8甚至ARM Cortex A9的双核处理器。但是这并不意味着无须优化性能。Android採取了多种手段来加快应用启动和执行速度。还提供了多个工具供用户分析性能的瓶颈。

在详细的软件开发中，智能终端尽管近今年获得了高速发展，但其所拥有的资源仍然有限。为了下降没必要要的开销。有两个原则必须遵照：

不作没必要要的事。

不分配没必要要的内存。

（1）优化资源读取

依据资源性质的不一样，Android对资源文件和SD卡资源进行了优化。

1）资源文件

Android在编译时对描写叙述UI的XML文件进行了优化，这就是开发人员将APK解包后没法打开当中的XML文件的缘由。

2）SD卡

对于SD卡中的数据，Android会在设备启动和SD卡插拔时进行增量式扫描。而不是在应用载入资源时进行扫描，这无疑加快了启动速度，其实，这依赖于MediaScanner的实现。固然其也存在局限性。对于文件类型没有包括在MediaFile.java中的文件。MediaScanner就无能为力了。

（2）优化APK载入

Android提供了zipalign。zipalign提供了4字节的边界对齐来映射内存，经过空间换时间的方式来提升APK载入的运行效率。

zipalign的使用方法： zipalign [-c] [-f] [-v] <align> infile.zip outfile.zip //-c表示检查对齐，-f表示强制覆盖已有输出文件

常用的zipalign方法例如如下：#zipalign -v 4 infile.zip outfile.zip //-v 表明具体输出。 ”4“表示4字节对齐

对于APK的载入。假设是预制应用，Android会在系统编译后生成后缀为ODEX的优化文件。对于非预制应用。在第一次启动应用时，DEX文件会被优化为DEY文件并放置到\data\dalvik-cache文件夹下，从而加快启动速度。

（3）Dalvik虚拟机

在Android中，出于性能和规避知识产权方面的考虑。Google并无直接採用CLASS字节码，而是先将Java代码编译成CLASS字节码，而后再将CLASS字节码转化为DEX字节码。在这一过程当中，Android会删除冗余，这很是大程度上减少了APK的大小，最后将APK载入到Dalvik虚拟机中。

在CLASS字节码转化为DEX字节码的过程当中。Android对冗余信息进行了处理。

另外，经过Dexdump可以查看出APK文件里DEX运行状况，这有助于开发人员优化本身的程序。

（4）TraceView性能分析

TraceView是Android提供的一个调试应用和优化性能的图形界面工具，其包含两个面板。Timeline Panel和Profile Panel。Timeline Panel从时间维度为开发人员提供了优化性能的视角，在Timeliness Panel的左側显示的是不一样的线程；Profile Panel从方法调用顺序角度为开发人员提供了优化性能的视角。Profile Panel面板中显示的方法有父方法和子方法，所谓父方法即调用当前方法的方法，所谓子方法即当前方法调用的方法。

为了经过TraceView进行性能分析，首先要在代码中设置跟踪的起点和终点。方法例如如下：
Debug.startMethodTracing("test"); //"test"为生成的trace文件名称

setContentView(R.layout.main);

Debug.stopMethodTracing();

生成的trace文件会被放置在\sdcard文件夹下。固然为了在SD卡下运行写入操做。需要例如如下权限：

<uses-permission>

android:name="android.permission.WRITE_EXTERNAL_STORAGE">

</uses-permission>

这里生成的trace文件为test.trace。在将test.trace导出到Linux下后，就能够经过android_sdk_linux/tools/traceview脚本进行性能分析，方法例如如下：

#cd ANDROID_SDK_HOME

#./tools/traceview test.trace

Inclusive表示整个方法从调用到结束的运行时间。包括子方法运行时间；而Exclusive仅表示方法自己的运行时间。

固然由于test.trace仅分析了setContentView的载入过程，从视图上看不出有不论什么性能问题，但是在实际的开发中就不同了。开发人员要活用TraceView。提高应用的质量。

（5）执行效率优化

为了提高代码的执行效率。必须知道最消耗计算能力的代码段的位置，依据80/20法则，优化最重要的20%的代码就能够大幅提高代码的执行效率。

最直接的观察执行效率的方法是算出代码段在目标环境下执行时间。对应方法例如如下：

long start = System.currentTimeMillis();

long duration = System.currentTimeMillis()-start; //毫秒数

另外，经过观察Logcat显示的虚拟机释放内存的状况，也可观察出计算能力消耗的位置。

在平台方面，为了充分挖掘CPU的性能，Android还针对armv5te进行了优化，充分利用armv5te的运行流水线来提升运行的效率。

在建立新进程时。Android採用了Linux的写时拷贝（Copy on Write）机制。是建立一个新进程很高效。