android分析
A. 分析android性能测试的要点有哪些
有如下几个工具： android针对上面这些会影响到应用性能的情况提供了一些列的工具： 1 布局复杂度： hierarchyviewer：检测布局复杂度，各视图的布局耗时情况： Android开发者模式—GPU过渡绘制： 2 耗电量：Android开发者模式中的电量统计； 3 内存： 应用运行时内存使用情况查看：Android Studio—Memory/CPU/GPU； 内存泄露检测工具：DDMS—MAT； 4 网络：Android Studio—NetWork； 5 程序执行效率： 静态代码检查工具：Android studio—Analyze—Inspect Code.../Code cleanup... ，用于检测代码中潜在的问题、存在效率问题的代码段并提供改善方案； DDMS—TraceView，用于查找程序运行时具体耗时在哪； StrictMode：用于查找程序运行时具体耗时在哪，需要集成到代码中； Andorid开发者模式—GPU呈现模式分析。 6 程序稳定性：monkey，通过monkey对程序在提交测试前做自测，可以检测出明显的导致程序不稳定的问题，执行monkey只需要一行命令，提交测试前跑一次可以避免应用刚提交就被打回的问题。 说明： 上面提到的这些工具可以进Android开发者官网性能工具介绍查看每个工具的介绍和使用说明； Android开发者选项中有很多测试应用性能的工具，对应用性能的检测非常有帮助，具体可以查看：All about your phone's developer options和15个必知的Android开发者选项对Android开发者选项中每一项的介绍； 针对Android应用性能的优化，Google官方提供了一系列的性能优化视频教程，对应用性能优化具有非常好的指导作用，具体可以查看：优酷Google Developers或者Android Performance Patterns。 二 第三方性能优化工具介绍 除了android官方提供的一系列性能检测工具，还有很多优秀的第三方性能检测工具使用起来更方便，比如对内存泄露的检测，使用leakcanry比MAT更人性化，能够快速查到具体是哪存在内存泄露。 leakcanary：square/leakcanary · GitHub，通过集成到程序中的方式，在程序运行时检测应用中存在的内存泄露，并在页面中显示，在应用中集成leancanry后，程序运行时会存在卡顿的情况，这个是正常的，因为leancanry就是通过gc操作来检测内存泄露的，gc会知道应用卡顿，说明文档：LeakCanary 中文使用说明、LeakCanary: 让内存泄露无所遁形。 GT：GT Home，GT是腾讯开发的一款APP的随身调测平台，利用GT，可以对CPU、内存、流量、点亮、帧率/流畅度进行测试，还可以查看开发日志、crash日志、抓取网络数据包、APP内部参数调试、真机代码耗时统计等等，需要说明的是，应用需要集成GT的sdk后，GT这个apk才能在应用运行时对各个性能进行检测。
B. 如何从技术上全面分析一款android app
一、用户体验是王道
1.这是一个看脸的时代，不论是人还是app。
2.Android出现也已经是很长的一段时间了，各种技术相对比较成熟，开源社区里那些图片库、网络库、UI界面、数据框架一抓一大把，在同一个类别的应用中，如果没点干货真的很难脱颖而出。谁来判断干货，不是研发，不是pm，是用户。
3.我现在的Leader之前跟我说过一句话，我深以为然--做一款app，其实最核心的是怎么获取到用户，怎么愿意让用户去使用你，而不是你应用内的技术怎么怎么牛B。不喜勿喷，其实我刚开始的时候也不能理解，但是后来逐渐领悟到他说的竟然是对的。对于移动互联网来说，app的生生死死真是太常见了，各个公司每年新开的项目一大片，真正能够活下来的又有几个。所以在应用的前期还是努力迭代功能，让自己的app活下去之后，再考虑技术的问题吧
二、应用架构是否合理
1.简单就一句话，不要重复造轮子，不要重复造轮子，尤其是不要在一个应用里反复造多个轮子。现在的软件开发早就过了单枪匹马闯天下的时代了，很多个研发同时工作，难免会造成各自代码不熟悉，这时候就需要有人能够将整个应用的架构能够捋清楚，千万不要出现项目中我用我的库方法，你用你的库方法，大家一起造轮子玩这种情况。
2.能够使用开源库就从了他吧。还是那句话，别人造好的轮子，为嘛不用，非得自己造一个，真以为自己是全能吗？你不累我看着都累啊。
三、内存、网络、界面性能响应优化
其实大家都说过了软件性能的重要性，我在这里也就不再进行复述了，反正LeakCanary,TraceView等等性能工具，谁用谁知道。
四、单元测试
感觉国内好像很少有研发自己写单元测试的情况啊，其实我觉得很多时候，研发才是对功能最熟悉的人，很多边界条件只有在代码中才能够恰好遇到，所以写好单元测试做一只不麻烦QA的猿才是好猿。
五、安全
Sorry，我对应用安全不是很懂，就是简单用用Proguard混淆就Over了，加壳什么的感觉貌似没有太大必要，毕竟对于很多Android应用而言，其实看一眼大概知道他的界面逻辑了，ui层自己重写绝对比逆向快，而api接口之类的东西，或许是我不太敏感吧。
C. 怎么分析android代码是否存在内存泄露
1、首先确定是否有内存泄露及哪个程序造成。
1.1、内存泄露已弹出out of memory对话框的情况。
这种情况很简单，直接看对话框就知道是哪个应用的问题了。然后再分析该应用是否是因为内存泄露造成的
out of memory对话框。
》中介绍的各种方法进行分析，确定是否有内存泄露以及是哪个进程造成的内存泄露。
2、生成hprof文件，用MAT进行分析。
生
成hprof文件可以在DDMS选中进程点击窗口左上角的mp hprof
file按钮来直接生成，也可以通过在程序加代码中来生成代码2：voidgenerateHprof(){String
packageName=getApplicationInfo().packageName;
StringhpFilePath=/data/data/+packageName+/input.hprof;try{//Debug.mpHprofData(/sdcard/input.hprof);Debug.
mpHprofData
(hpFilePath);}catch(IOException e) {//TODOAuto-generated catch block
e.printStackTrace();}}建议使用代码生成hprof，然后使用《
Android内存泄露利器（hprof篇）》中的工具自动提取多个hprof文件，然后用MAT进行比较分析。在MAT导入.hprof文件以后，
MAT会自动解析并生成报告，点击
Dominator Tree
，并按Package分组，选择自己所定义的Package类,比较各个类在不同时期的RetainedHeap
,找出可疑类，然后选择该类，点右键，选中
show retained Set项,参看Retained Heap
的详细信息，进一步找出嫌疑项。
3、在代码中查找内存泄露。
根据在MAT找到的内存泄露信息，参照《
Android内存泄漏简介
》进一步在内存中查找内存泄露的原因并解决。
另外如果代码很简单，可以直接参照《
Android内存泄漏简介
》在内存中查找内存泄露的原因并解决。
D. 如何在android画分析图（例如 柱状图、趋势图、饼图）
目前android上图标引擎并不少见，像aChartEngine就能很好的完成绘图：
aChartEngine支持：1、linechart(折线图)2、areachart(面积图；分区图，对比图)3、scatterchart(散点图)4、timechart(时间图；进度表)5、barchart(条形图;柱状图)6、piechart(饼图)7、bubblechart(气泡图)8、doughnutchart(圆环图)9、range(high-low)barchart(范围条形图)10、dialchart/gauge(拨号盘/压力表)11、combined(anycombinationofline,cubicline,scatter,bar,rangebar,bubble)chart(组合图)12、cubiclinechart(立方折线图)
上述所有支持的图表类型，都可以包含多个系列，都支持水平（默认）或垂直方式展示图表,并且支持许多其他的自定义功能。所有图表都可以建立为一个view,也可以建立为一个用于启动activity的intent.
下面是一个饼状图的源码事例：
package org.achartengine.chartdemo.demo.chart;
import org.achartengine.ChartFactory;
import org.achartengine.renderer.DefaultRenderer;
import android.content.Context;
import android.content.Intent;
import android.graphics.Color;
public class BudgetPieChart extends AbstractDemoChart {
public String getName() {
return "Budget chart";
}
public String getDesc() {
return "The budget per project for this year (pie chart)";
}
public Intent execute(Context context) {
double[] values = new double[] { 12, 14, 11, 10, 19 };//饼图分层5块,每块代表的数值
int[] colors = new int[] { Color.BLUE, Color.GREEN, Color.MAGENTA, Color.YELLOW, Color.CYAN };//每块饼图的颜色
DefaultRenderer renderer = buildCategoryRenderer(colors);
renderer.setZoomButtonsVisible(true);//设置显示放大缩小按钮
renderer.setZoomEnabled(true);//设置允许放大缩小.
renderer.setChartTitleTextSize(20);//设置图表标题的文字大小
return ChartFactory.getPieChartIntent(context, buildCategoryDataset("Project budget", values),
renderer, "Budget");//构建Intent, buildCategoryDataset是调用AbstraDemoChart的构建方法.
}
}
E. android 内存问题怎么分析
使用eclipse 自带的 DDMS 工具分析各线程的内存使用情况，如下图所示
Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化。
怎样判断当前进程是否有内存泄漏呢？
这里需要注意一个值：VM Heap页面中部有一个data object选项，即数据对象，也就是我们的程序中大量存在的类类型的对象。
在data object一行中有一列是“Total Size”，其值就是当前进程中所有java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。如上图中选中行所示。
可以据此判断内存有泄漏：
1) 不断的操作当前应用，或者重复某一动作，注意观察data object的Total Size值。
2) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说如果程序中的的代码逻辑良好，
没有创建的对象不被GC机制正常回收的情况，即便 我们不断的操作生成很多对象，而在虚拟机不断的进行垃圾回收的过程中，这些对象都被正常回收了，内存使用量会保持在一个比较稳定的水平。
3) 如果代码中存在对象引用没有释放的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大。
正常情况下，一个虚拟机的进程的内存在64M, 如果内存泄漏会发现 Heap Size 在不断的逼近 64M, 一旦达到这个值时，就会出现退出应用等情况。
发生内存泄露，Total Size的值越来越大时，按下“Dump HPROF file”按钮，这个时候会提示设置hprof文件的保存路径。保存后，可以对比log来分析是哪些操作造成了内存泄漏。
F. 如何分析android 内存泄漏
1.资源对象没关闭造成的内存泄漏描述：资源性对象比如(Cursor，File文件等)往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏。因为有些资源性对象，比如 SQLiteCursor(在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭)，如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
示例代码：
Cursor cursor = getContentResolver().query(uri...);
if (cursor.moveToNext()) {
... ...
}
修正示例代码：
Cursor cursor = null;
try {
cursor = getContentResolver().query(uri...);
if (cursor != null &&cursor.moveToNext()) {
... ...
}
} finally {
if (cursor != null) {
try {
cursor.close();
} catch (Exception e) {
//ignore this
}
}
}
2.构造Adapter时，没有使用缓存的convertView描述：以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法：
public View getView(int position, ViewconvertView, ViewGroup parent)
来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。由此可以看出，如果我们不去使用 convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。 ListView回收list item的view对象的过程可以查看:
android.widget.AbsListView.java --> voidaddScrapView(View scrap) 方法。
示例代码：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代码：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
3.Bitmap对象不在使用时调用recycle()释放内存描述：有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：
/**
Free up the memory associated with thisbitmap's pixels, and mark the
bitmap as "dead", meaning itwill throw an exception if getPixels() or
setPixels() is called, and will drawnothing. This operation cannot be
reversed, so it should only be called ifyou are sure there are no
further uses for the bitmap. This is anadvanced call, and normally need
not be called, since the normal GCprocess will free up this memory when
there are no more references to thisbitmap.
*/
4.试着使用关于application的context来替代和activity相关的context这是一个很隐晦的内存泄漏的情况。有一种简单的方法来避免context相关的内存泄漏。最显着地一个是避免context逃出他自己的范围之外。使用Application context。这个context的生存周期和你的应用的生存周期一样长，而不是取决于activity的生存周期。如果你想保持一个长期生存的对象，并且这个对象需要一个context,记得使用application对象。你可以通过调用 Context.getApplicationContext() or Activity.getApplication()来获得。更多的请看这篇文章如何避免Android内存泄漏。
5.注册没取消造成的内存泄漏一些Android程序可能引用我们的Anroid程序的对象(比如注册机制)。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。调用registerReceiver后未调用unregisterReceiver。
比如:假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。
虽然有些系统程序，它本身好像是可以自动取消注册的(当然不及时)，但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。
6.集合中对象没清理造成的内存泄漏我们通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
G. 如何分析一个Android程序
就像普通的程序一样，首先你得找到程序的入口，如main函数。但Android中没有main函数这一说，但也有程序的入口，而这个入口就是AndroidMainfest.xml中的MAIN和LAUNCHER所表示的Activity，这个Activity对应的类代码就是程序的入口。在安卓中，Avtivity往往采用MVC架构，然后你在Activity中找到相应的V，然后分析组件，再分析组件的事件，有线程的话再分析线程……就这样一步一步下去就可以把一个安卓程序分析完了。
H. 如何分析android bugreport
一、ChkBugReport介绍
ChkBugReport是一个开源工具，它可以把你得到的bugreprot解析成适合阅读的html文件。导出的html文件包含了根据bugreport数据得出的图表和分析结论。
它的源码中用到了以下开源类库： jQuery ，jsTree jquery plugin ， tablednd jQuery plugin ， tablesorter jQuery plugin ，js-hotkeys， jquery-cookie 。学习输出报告文档型html可以参考源码。
目前ChkBugReport可以从bugreport数据中抽取出如下信息：
1、Stacktraces ChkBugReport可以从bugreport中解析出输出bugreport的最后时刻、导致ANR时刻甚至更多时刻的堆栈信息。在例子中你可以看到进程的优先级和策略都已标示出来，堆栈中耗时的部分颜色是黑红，一些违反Strict Mode的部分（比如主线程中使用数据库）颜色标记为亮红。如果这个线程死锁，在报告的Errors将会出现。
2、Logs 这部分是对system、main和kernel日志的分析，在这里你可以看到每个进程内存使用图、那个程序产生的log最多、Activity的启动耗时、数据库操作耗时统计、对象被锁定时间、AIDL调用时间、Activity和Service的生命周期及其在内存中使用频率等等，详见
3、Packages ChkBugReport解析bugreport中存储的packages.xml并展示一系列的packages、user ids和 permissions。参见
4、Processes 操作app过程中产生的系统事件日志、内存使用信息等等，参见
5、Battery statistics 电池使用统计信息，参见
6、CPU Frequency statistics CPU频率统计信息，参见
7、Raw data 被分割成小段的原始数据
同时ChkBugReport也可以检测到（潜在的）错误，这些错误在输出的报告Errors部分中可以找到。你也可以在输出报告的stacktrace中找到死锁或一些违反Strict Mode的行为。
二、ChkBugReport使用
使用很简单：1 java -jar $HOME/Downloads/chkbugreport.jar $HOME/tmp/bugreport.txt
你也可以把chkbugreport.jar加到path下，然后这样使用1 chkbugreport thebugreport.txt
该工具将根据你的bugreport数据输出一个分析结果目录bugreport_out。
你可以使用如下命令取得bugreport：1 adb shell bugreport > bugreport.txt
当然你可以使用ChkBugReport分析bugreport的部分数据比如/data/anr/traces.txt1 chkbugreport -sl:the_system_log.txt -sa:traces.txt mmy
这将输出分析结果到mmy_out。
你甚至可以使用ChkBugReport分析traceview生成的数据1 chkbugreport -t something.prof
Prof数据生成方法可以参考以下方法：
1、可以使用eclipse插件traceview生成
2、也可以按如下步骤：
a.用adb shell ps列出所有进程并找出你想要trace的进程的PID
b.执行adb shell am profile PID start /data/profile.dat，开始分析
c.操作你的app
d.执行adb shell am profile PID stop ，停止分析
e.导出数据并清除临时文件：adb pull /data/profile.dat adb shell rm /data/profile.dat
f.使用ChkBugReport进行分析 chkbugreport -t profile.dat
I. 怎么样进行Android应用的性能分析
对于手机应用性能可以从两方面关注:
1.app产品做好之后必须从每个控件在国内不同的手机品牌和不同系统版本进行兼容性测试，业内也叫遍历测试，所谓的遍历测试是可以移动识别应用的控件从而进行多层次的运行测试，当中包含了安装测试，启动测试，控件遍历测试，最后是卸载测试！
2.兼容性测试，也就是适配测试完成之后需要开始对网络性能进行测试，这里大概有几个方面需要进行的:网络性能测试，元素加载性能测试，网络可用性测试等等！
国内现有的测试周期和测试手段都是通过人工化测试，真正实现自动化又节省时间与人力的只有借助第三方应用性能管理提供商才可以实现！