1. Appium超时错误连接到驱动程序时问题，怎么解决
问题
1. error: Failed to start an Appium session, err was: Error: Requested a new session but one was in progress
之前的会话没有关闭，然后你又运行了测试实例，也没有设置覆盖.
解决:
1.重新停止appium服务，开启Appium服务
2.在Genarel Setting那里设置覆盖Session，重启Appium
测试结束在AfterClass加driver.quit()
2. error: Failed to start an Appium session, err was: Error: Command failed: C:Windowssystem32cmd.exe /s /c "D:android-sdk-windowsplatform-toolsadb.exe -s adb server version (32) doesn't match this client (36); killing…
wait-for-device"
error: could not installsmartsocketlistener: cannot bind to 127.0.0.1:5037:
没有链接上手机或者模拟器，请确认已经连接成功，重新链接
3. error: Android devices must be of API level 17 or higher. Please change your device to Selendroid or upgrade Android on your device.
手机系统低于4.2，appium不支持4.2.2以下的系统，请换一个手机或者模拟器来测试。
4. Error: Permission to start activity denied.
**activity在清单文件里面没添加Android:exported="true"的话，你不能直接打开对应的activity，需要从启动页activity打开。
exported属性就是设置是否允许activity被其它程序调用**
5. error: Failed to start an Appium session, err was: Error: Activity used to start app doesn't exist or cannot ve launched! Make usre it exists and is launchable activity
要打开的activity不存在，activity路径错误，改为完整正确的activity路径
6. error: Failed to start an Appium session, err was: Error: 'java - version' failed. Error: Command failed: C:Windowssystem32cmd.exe /s /c "java -version"
Java版本错误，请安装最新的版本。
7.> info: [debug] Error: Command failed: C:Windowssystem32cmd.exe /s /c "D:android-sdk-windowsplatform-toolsadb.exe -s 8806a0b0 shell "echo 'ready'"error: unknown host service
链接手机失败，重新链接手机即可，我就是重新拔插了一下usb
Error: Command failed: C:Windowssystem32cmd.exe /s /c "D:android-sdk-windowsplatform-toolsadb.exe -s 8806a0b0 shell "echo 'ping'""
error: unknown host service
adb被突然占用导致，例如你在运行用例的时候运行了模拟器。
8. UIAutomatorViewer提示: Unable to connect to adb. Check if adb is installed correctly
解决，sdk升级到了25产生的问题。
解决方法:
将adb.exe复制一份到uiautomatorviewer.bat目录下
修改uiautomatorviewer.bat文件最后一行（改binddir=%prog_dir%为自己的platform-tools本地路径）
9 error: Failed to start an Appium session, err was:INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install io.appium.settings without first uninstalling
When you are at final step to execute test automation script for mobile app testing on a mobile emulator or a virtual device or a real device, you might observe that script execution fails with different kinds of errors, In context to current article you will look at the error and solutions for: INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install io.appium.settings without first uninstalling.
Error in Appium Server:
1
2
3
4
5
6
7
8
Error: Command failed: C:Windowssystem32cmd.exe /s /c
"C:Users{User}-toolsadb.exe -s
emulator-5554 install
"C:Program Files (x86)Appium ode_molesappiumuildsettings_apksettings_apk-debug.apk""
> Failed to install C:Program Files (x86)Appium ode_molesappiumuildsettings_apk
settings_apk-debug.apk: Failure [INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install
io.appium.settings without first uninstalling.]
Error in Android studio run console:
1
2
3
4
5
6
7
8
9
org.openqa.selenium.SessionNotCreatedException: A new session could not be created.
(Original error: Command failed: C:Windowssystem32cmd.exe /s /c
"C:Users{User}-toolsadb.exe -s emulator-5554 install
"C:Program Files (x86)Appium ode_molesappiumuildsettings_apksettings_apk-debug.apk""
Failed to install C:Program Files (x86)Appium ode_molesappiumuildsettings_apk
settings_apk-debug.apk: Failure [INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install
io.appium.settings without first uninstalling.]
) (WARNING: The server did not provide any stacktrace information)
Command ration or timeout: 0 milliseconds
For the first time when you execute the script itmight pass, but it will fail with above error when you try to execute the same or any other script multiple times. Or when your test script execution fails on the first attempt for some other reason, and when you fix it and execute it again, you might encounter this new issue.
原因：
The reason for this error is that Appium installs 2 mobile applications before executing the script.
1. io.appium.settings
2. io.appium.unlock
Theseare the supportive mobile applications appium utilizes to execute the test automation script in Mobile Emulator or virtual device or a real mobile device.
Ideally Appium should remove these files every time at the end of the script execution or termination, if it is intends to install themevery time a script is executed, or it should conditionally install these apps / apksto the mobile emulator or mobile device.
In your mobile emulator / Virtual Device / Real device, the 2 mobile applications appear as below:
There are multiple ways to troubleshootthis error and go ahead for asuccessful test script execution.
解决办法
Solution 1: ADB's uninstall command to remove the files.
You can open command prompt, assuming that you already had set the environment variables for ANDROID_HOME and Path variables for sdk tools and platform tools.
And execute commands as shown below:
Solution 2: Uninstall manually
You can open the mobile emulator / virtual device / real device and go to apps and uninstall them.
Solution 3: Write code as part of your test automation script.
As part of your selenium test automation script, you could write instructions to execute the commands provided in solution 1 above, so that this issue would not arise.
Hope this article has been helpful and you are able to proceed further with script execution.
Request to kindly share any of your queries in form of comments, we would try our best to provide any solution for you.
10.出错信息里含有"ps 'uiautomator'，具体信息未 A new session could not be created. (Original error: Command failed: C:Windowssystem32cmd.exe /s /c "C:Userssxie-toolsadb.exe -s emulator-5554 shell "ps 'uiautomator'""
android-appium: A new session could not be created
junitexceptionandroidappium自动化
detail log:
org.openqa.selenium.SessionNotCreatedException: A new session could not be created. (Original error: Command failed: C:Windowssystem32cmd.exe /s /c "C:Userssxie-toolsadb.exe -s emulator-5554 shell "ps 'uiautomator'""
) (WARNING: The server did not provide any stacktrace information)
Command ration or timeout: 0 milliseconds
Build info: version: '3.4.0', revision: 'unknown', time: 'unknown'
System info: host: 'WL00070299', ip: '10.110.12.39', os.name: 'Windows 8.1', os.arch: 'x86', os.version: '6.3', java.version: '1.8.0_40'
Driver info: driver.version: AndroidDriver
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect..newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:215)
at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:167)
at io.appium.java_client.remote.AppiumProtocolHandShake.createSession(AppiumProtocolHandShake.java:161)
at io.appium.java_client.remote.AppiumProtocolHandShake.createSession(AppiumProtocolHandShake.java:76)
at io.appium.java_client.remote.AppiumCommandExecutor.doExecute(AppiumCommandExecutor.java:111)
at io.appium.java_client.remote.AppiumCommandExecutor.execute(AppiumCommandExecutor.java:162)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:637)
at io.appium.java_client.DefaultGenericMobileDriver.execute(DefaultGenericMobileDriver.java:42)
at io.appium.java_client.AppiumDriver.execute(AppiumDriver.java:1)
at io.appium.java_client.android.AndroidDriver.execute(AndroidDriver.java:1)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:250)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:236)
at org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:137)
at io.appium.java_client.DefaultGenericMobileDriver.(DefaultGenericMobileDriver.java:38)
at io.appium.java_client.AppiumDriver.(AppiumDriver.java:88)
at io.appium.java_client.AppiumDriver.(AppiumDriver.java:112)
at io.appium.java_client.android.AndroidDriver.(AndroidDriver.java:73)
at com.sky.demo.ContactTest.setUp(ContactTest.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schele(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
==========================================
直接在cmd中执行"C:Windowssystem32cmd.exe /s /c "C:Userssxie-toolsadb.exe -s emulator-5554 shell "ps 'uiautomator'""
bad pid 'uiautomator'"， 报错： bad pid 'uiautomator'
代码内容为
public class ContactTest {
private AndroidDriver driver;
@Before
public void setUp() throws Exception {
//设置apk的路径
File classpathRoot = new File(System.getProperty("user.dir"));
File appDir = new File(classpathRoot, "apps");
File app = new File(appDir, "ContactManager.apk");
}
解决办法：
resolved by this way:
adb.js(C:Program Files (x86)Appium
ode_molesappium
ode_molesappium-adblibadb.js) 中1035 行this.shell("ps '" + name + "'", function (err, stdout) {
对应执行的指令是ps 'uiautomator', Android7不支持这个指令格式，所以执行结果是bad pid 'uiautomator'
目前Appium未对此进行处理,所以需要修改此指令的执行方式
即将
this.shell("ps '" + name + "'", function (err, stdout) {
if (err) return cb(err);
替换成
this.shell_grep("ps", name, function (err, stdout) {
if (err) {
logger.debug("No matching processes found");
return cb(null, []);
}
并增加上面用到的shell_grep函数：
ADB.prototype.shell_grep = function (cmd, grep, cb) {
if (cmd.indexOf('"') === -1) {
cmd = '"' + cmd + '"';
}
var execCmd = 'shell ' + cmd + '| grep ' + grep;
this.exec(execCmd, cb);
};
11.Android 7.0系统的手机无法执行appium脚本的问题
AppiumAppium 版本 1.4.16，Android 设备固件 7.x，执行脚本时，报错使用语言：python报错如下：
WebDriverException: Message: A new session could not be created. (Original error: Could not extract PIDs from ps output. PIDS: [], Procs: ["bad pid 'uiautomator'"])
这个是因为appium版本1.4.16使用的uiatumator1.0不支持的原因导致？如果不升级appium版本，是否有解决方案？
解决办法
uiautomator1.0应该是不支持7.0，不升版本就换用uiautomator2.0吧，或者用下面的改脚本的方法使用。
解决Android 7.0系统的手机无法执行appium脚本的问题，改问题的具体解决方法如下：
找到appium的安装目录下的adb.js文件，windows版本的目录如下：Appium
ode_molesappium
ode_molesappium-adblib
2、打开adb.js，手动修改该文件下的内容，此方法我已经试验成功。
adb.js 中1035 行this.shell("ps '" + name + "'", function (err, stdout) {
对应执行的指令是ps 'uiautomator', Android7不支持这个指令格式，所以执行结果是bad pid 'uiautomator'
目前Appium未对此进行处理,所以需要修改此指令的执行方式
即将
this.shell("ps '" + name + "'", function (err, stdout) {
if (err) return cb(err);
替换成
this.shell_grep("ps", name, function (err, stdout) {
if (err) {
logger.debug("No matching processes found");
return cb(null, []);
}
并增加上面用到的shell_grep函数：
ADB.prototype.shell_grep = function (cmd, grep, cb) {
if (cmd.indexOf('"') === -1) {
cmd = '"' + cmd + '"';
}
var execCmd = 'shell ' + cmd + '| grep ' + grep;
this.exec(execCmd, cb);
};
网上还有如下的修改解决办法：以下我未试验。
ADB.prototype.getPIDsByName = function (name, cb) {
logger.debug("Getting all processes with '" + name + "'");
this.shell("ps '" + name + "'", function (err, stdout) {
if (err) return cb(err);
stdout = stdout.trim();
var procs = [];
var outlines = stdout.split("
");
outlines.shift(); //在该处添加此行代码
3、重启appium
技巧
1.每次测试都重新安装app
为capabilities色设置noReset为true
capabilities.setCapability("noReset", true);
2.中文乱码
这都是编码问题:
1.方法1:
Android Studio修改文件编码的方法，最底部的UTf-8,点击选GBK就可以了，reload文件。（ps:先把文件内容全选复制一下再转换编码，再粘贴，不然文件内容就变乱码了）
2.方法2:
用的是原来的UTF-8编码，然后在测试mole的build.gradle里面添加三行代码
tasks.withType(JavaCompile){
options.encoding = 'UTF-8'
}
3.清除编辑框EditText内容
这个问题好像是看手机系统的，我之前的手机就会出现sendKeys的时候没有全选去掉本来的内容，现在都会自动全选覆盖了，这个也不算问题了。
/**
* 逐字删除编辑框中的文字
* @param element 文本框架控件
*/
public void clearText(AndroidElement element){
String className = element.getClass().getSimpleName();
if (className.equals("EditText")){
String text = element.getText();
//跳到最后
driver.pressKeyCode(KEYCODE_MOVE_END);
for (int i = 0; i < text.length(); i ++){
//循环后退删除
driver.pressKeyCode(BACKSPACE);
}
}else {
print("不是文本输入框架，无法删除文字");
}
}
1
4.点击输入法键盘的回车搜索
方法1:切换输入法
利用adb命令先切换为自己的输入法，按了搜索再切换为appium的输入法
查看当前手机的输入法
cmd执行下面的的代码
adb shell ime list -s
可以看到类似下面的结果，
C:UsersLITP>adb shell ime list -s
com..input_mi/.ImeService
com.sohu.inputmethod.sogou.xiaomi/.SogouIME
io.appium.android.ime/.UnicodeIME
C:UsersLITP>
执行adb命令
先写好一个执行cmd的方法
/**
* 执行adb命令
* @param s 要执行的命令
*/
private void excuteAdbShell(String s) {
Runtime runtime=Runtime.getRuntime();
try{
runtime.exec(s);
}catch(Exception e){
print("执行命令:"+s+"出错");
}
}
在需要搜索的时候执行下面的代码，切换的输入法用自己查看列表的输入法内容，我这里是搜狗输入法
//使用adb shell 切换输入法-更改为搜狗拼音，这个看你本来用的什么输入法
excuteAdbShell("adb shell ime set com.sohu.inputmethod.sogou.xiaomi/.SogouIME");
//再次点击输入框，调取键盘，软键盘被成功调出
clickView(page.getSearch());
//点击右下角的搜索，即ENTER键
pressKeyCode(AndroidKeyCode.ENTER);
//再次切回 输入法键盘为Appium unicodeKeyboard
excuteAdbShell("adb shell ime set io.appium.android.ime/.UnicodeIME");
2. Android性能测试（内存、cpu、fps、流量、GPU、电量）——adb篇
3）查看进程列表：adb shell "ps"，同时也能获取到应用的UID，方式如下（不需root权限）：
u0_a开头的都是Android的应用进程，Android的应用的UID是从10000开始，到19999结束，可以在Process.java中查看到（FIRST_APPLICATION_UID和LAST_APPLICATION_UID），u0_a后面的数字就是该应用的UID值减去FIRST_APPLICATION_UID所得的值，所以，对于截图这个应用进程，它是u0_a155，按前面的规制，它的UID就是155 + FIRST_APPLICATION_UID = 10155。
VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
使用 adb shell "mpsys meminfo -s <pakagename | pid>"命令，输出结果分以下4部分:
PS：在apk内调用运行获取其他app的内存数据则需要root权限
adb命令：adb shell mpsys gfxinfo <package | pid>
正常情况下帧率应该在16.67ms左右，1秒60帧，执行结果如下：
详细计算方法如下：
还有一个命令是: adb shell mpsys SurfaceFlinger --latency LayerName
其中LayerName在各个不同系统中获取的命令是不一样的
在Android 6系统直接就是SurfaceView
在Android 7系统中可以通过 mpsys window windows | grep mSurface | grep SurfaceView 然后通过数据截取到
在Android 8系统中可以通过 mpsys SurfaceFlinger | grep android包名获取到
执行命令结果如下：
计算方法比较简单，一般打印出来的数据是129行（部分机型打印两次257行，但是第一部分是无效数据，取后半部分），取len-2的第一列数据为end_time，取len-128的第一列数据为start_time
fps = 127/((end_time - start_time) / 1000000.0)
至于为啥要取第一列数据，这里不做过多介绍，欢迎参看这两篇文章
老罗的文章SurfaceView原理
Android性能测试之fps获取
至于为啥要处于1000000，因为命令打印出来的是纳秒单位，要转为毫秒进行计算，127就是因为命令一次打印出来127帧的数据而已
有两种方法可以获取
1） adb shell "top -n 5 | grep <package | pid>" ，第三列就是实时监控的CPU占用率（-n 指定执行次数，不需root权限），这边top命令执行需要2到3s左右，一般可以采用busybox 的top命令执行，效率会快很多
2） adb shell "mpsys cpuinfo | grep <package | pid>"
两种方法直接区别在于，top是持续监控状态，而mpsys cpuinfo获取的实时CPU占用率数据
adb命令：adb shell "mpsys batterystats < package | pid>" (Android 5.0后引入)
获取单个应用的耗电量信息，具体返回结果待研究
adb命令：adb shell "mpsys battery"
出现信息解读：
AC powered：false 是否连接AC（电源）充电线
USB powered：true 是否连接USB（PC或笔记本USB插口）充电
Wireless powered：false 是否使用了无线电源
status: 1 电池状态，2为充电状态，其他为非充电状态
level：58 电量（%）
scale: 100. 电量最大数值
voltage: 3977 当前电压（mV）
current now: -335232. 当前电流（mA）
temperature:355 电池温度，单位为0.1摄氏度
adb 命令：adb shell "mpsys< package | pid> | grep UID" [通过ps命令，获取app的UID（安装后唯一且固定）]
adb shell cat /proc/uid_stat/UID/tcp_rcv [cat为查看命令，读取tcp_rcv获取应用接收流量信息（设备重启后清零）]
adb shell cat /proc/uid_stat/UID/tcp_snd [cat为查看命令，读取tcp_snd获取应用发送流量信息（设备重启后清零）]
计算流量消耗步骤：
或者还有一种方式获取应用流量消耗：
首先判断类型：
cat /sys/class/thermal/thermal_zone*/type
只有红框框出来的是有效的
cat /sys/class/thermal/thermal_zone*/temp
获取CPU温度
mpsys battery | grep temperature 单位0.1摄氏度
获取/proc/stat文件内容（无权限限制）
总的cpu时间片是 total = user+nice+system+idle+iowait+irq+softirq
忙碌时间为 notidle = user+nice+system +iowait+irq+softirq
cpu使用率计算方法为，先取开始的total值和忙碌时间notidle，隔一段时间片，再取一次计算total2，notidle2, cpuuse = (notidle2 – notidle) * 100 / (total2 - total)%
PS:由于Android 8权限收紧，在Android 8系统手机内apk内读取文件内容为空，需要shell权限才可获取文件内容，下同
读/sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq文件的值，X不定，看是几核手机，scaling_cur_freq是否存在也不一定，需要判断
至于为啥不取cpuinfo_cur_freq文件的值，原因是android 6,7系统获取的时候，这个文件shell没有读取权限，需要root权限
参考文章： https://blog.csdn.net/long_meng/article/details/45934899
Android 6,7系统可执行
mpsys window windows | grep "mCurrentFocus"
执行结果一般为类似：
mCurrentFocus=Window{81caaa5 u0 com.tencent.mobileqq/com.tencent.mobileqq.activity.SplashActivity}
按照一定规则把com.tencent.mobileqq提取出来即可
直接apk内读取文件即可，不需要shell权限（支持到Android8）
Gpu使用率获取：会得到两个值，（前一个/后一个）*100%=使用率
adb shell cat /sys/class/kgsl/kgsl-3d0/gpubusy
Gpu工作频率：
adb shell cat /sys/class/kgsl/kgsl-3d0/gpuclk
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/cur_freq
Gpu最大、最小工作频率：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/max_freq
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/min_freq
Gpu可用频率
adb shell cat /sys/class/kgsl/kgsl-3d0/gpu_available_frequencies
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/available_frequencies
Gpu可用工作模式：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/available_governors
Gpu当前工作模式：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/governor
3. 怎么排查这些内存泄漏
最原始的内存泄露测试
重复多次操作关键的可疑的路径，从内存监控工具中观察内存曲线，是否存在不断上升的趋势且不会在程序返回时明显回落。
这种方式可以发现最基本，也是最明显的内存泄露问题，对用户价值最大，操作难度小，性价比极高。
MAT内存分析工具
2.1 MAT分析heap的总内存占用大小来初步判断是否存在泄露
在Devices 中，点击要监控的程序。
点击Devices视图界面中最上方一排图标中的“Update Heap”
点击Heap视图
点击Heap视图中的“Cause GC”按钮
到此为止需检测的进程就可以被监视。Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：
进入某应用，不断的操作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。
2.2 MAT分析hprof来定位内存泄露的原因所在。
这是出现内存泄露后使用MAT进行问题定位的有效手段。
A)Dump出内存泄露当时的内存镜像hprof，分析怀疑泄露的类：
B)分析持有此类对象引用的外部对象
C)分析这些持有引用的对象的GC路径
D)逐个分析每个对象的GC路径是否正常
从这个路径可以看出是一个antiRadiationUtil工具类对象持有了MainActivity的引用导致MainActivity无法释放。此时就要进入代码分析此时antiRadiationUtil的引用持有是否合理（如果antiRadiationUtil持有了MainActivity的context导致节目退出后MainActivity无法销毁，那一般都属于内存泄露了）。
2.3 MAT对比操作前后的hprof来定位内存泄露的根因所在。
为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去
A） 第一个HPROF 文件(usingFile > Open Heap Dump ).
B）打开Histogram view.
C）在NavigationHistory view里 (如果看不到就从Window >show view>MAT- Navigation History ), 右击histogram然后选择Add to Compare Basket .
D）打开第二个HPROF 文件然后重做步骤2和3.
E）切换到Compare Basket view, 然后点击Compare the Results (视图右上角的红色”!”图标)。
F）分析对比结果
可以看出两个hprof的数据对象对比结果。
通过这种方式可以快速定位到操作前后所持有的对象增量，从而进一步定位出当前操作导致内存泄露的具体原因是泄露了什么数据对象。
注意：
如果是用 MAT Eclipse 插件获取的 Dump文件，不需要经过转换则可在MAT中打开，Adt会自动进行转换。
而手机SDk Dump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)
首先，要通过控制台进入到你的 android sdk tools 目录下执行以下命令：
./hprof-conv xxx-a.hprof xxx-b.hprof
例如 hprof-conv input.hprof out.hprof
此时才能将out.hprof放在eclipse的MAT中打开。
手机管家内存泄露每日监控方案
目前手机管家的内存泄露每日监控会自动运行并输出是否存在疑似泄露的报告邮件，不论泄露对象的大小。这其中涉及的核心技术主要是AspectJ，MLD自研工具（原理是虚引用）和UIAutomator。
3.1 AspectJ插桩监控代码
手机管家目前使用一个ant脚本加入MLD的监控代码，并通过AspectJ的语法实现插桩。
使用AspectJ的原因是可以灵活分离出项目源码与监控代码，通过不同的编译脚本打包出不同用途的安装测试包：如果测试包是经过Aspect插桩了MLD监控代码的话，那么运行完毕后会输出指定格式的日志文件，作为后续分析工作的数据基础。
3.2 MLD实现监控核心逻辑
这是手机管家内的一个工具工程，正式打包不会打入，BVT等每日监控测试包可以打入。打入后可以通过诸如addObject接口（通过反射去检查是否含有该工具并调用）来加入需要监控的检测对象，这个工具会自动在指定时机（如退出管家）去检测该对象是否发生泄漏。
这个内存泄露检测的基本原理是：
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用必须和引用队列（ReferenceQueue）联合使用（在虚引用函数就必须关联指定）。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，自动把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。
基于以上原理，MLD工具在调用接口addObject加入监控类型时，会为该类型对象增加一个虚引用，注意虚引用并不会影响该对象被正常回收。因此可以在ReferenceQueue引用队列中统计未被回收的监控对象是否超过指定阀值。
利用PhantomReferences(虚引用)和ReferenceQueue(引用队列)，当PhantomReferences被加入到相关联的ReferenceQueue时，则视该对象已经或处于垃圾回收器回收阶段了。
MLD监控原理核心
目前手机管家已对大部分类完成内存泄露的监控，包括各种activity，service和view页面等，务求在技术上能带给用户最顺滑的产品体验。
接下来简单介绍下这个工具的判断核心。根据虚引用监控到的内存状态，需要通过多种策略来判断是否存在内存泄露。
（1）最简单的方式就是直接在加入监控时就为该类型设定最大存在个数，举个例子，各个DAO对象理论上只能存在最多一个，因此一旦出现两个相同的DAO，那一般都是泄露了；
（2）第二种情况是在页面退出程序退出时，检索gc后无法释放的对象列表，这些对象类型也会成为内存泄露的怀疑对象；
（3）最后一种情况比较复杂，基本原理是根据历史操作判断对象数量的增长幅度。根据对象的增长通过最小二乘法拟合出该对象类型的增长速度，如果超过经验值则会列入疑似泄露的对象列表。
3.3 UIAutomator完成重复操作的自动化
最后一步就很简单了。这么多反复的UI操作，让人工来点就太浪费人力了。我们使用UIAutomator来进行自动化操作测试。
目前手机管家的每日自动化测试已覆盖各个功能的主路径，并通过配置文件的方式来灵活驱动用例的增删改查，最大限度保证了随着版本推移用例的复用价值。
至此手机管家的内存泄露测试方案介绍完毕，也欢迎各路牛人交流沟通更多更强的内存泄露工具盒方案！
腾讯Bugly简介
Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布以后，对用户侧发生的Crash以及卡顿现象进行监控并上报，让开发同学可以第一时间了解到App的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。
4. 我手机进入了apply update from ADB 这是什么
apply update from ADB 从ADB进行更新。 ADB: ADB驱动是Android设备(如手机)连接PC时仿陵基所需要的应用程序。请试试以下方法：
直接长按电源键关机重启，等了两三分钟自备谨动回到汪蚂重启位置，按重启一切正常。
如果是三星手机，只有拆电池再进入 Odin3 线刷模式，再使用完美刷机助手。