oujunli的专栏

对于Android的性能这方面评估，大部分都是有超级兔子去比跑分的，还是不能反映全面的问题。就我知道的而言，应用启动时间是很影响用户体验的一个性能方面问题。最近的一个项目，别人都说应用启动慢，我师傅看我没什么事，叫我看一下。以前也看过一次，但那次是当学习，只是看看整流程是怎么走的，这次确不一样了。开始的一天，按以前的方式再看了一下，感觉没有什么异常的地方，不过时间确实比对比机慢了很多，但不

最近公司的手机发现退出U盘模式后，在U盘存有图片等内容比较多的情况下，滑动Launcher会有一段时间卡顿的现象。其实不是最近的项目才有的问题，以前的项目就有，一直都没有解决而已，顽疾。       当然，是在U盘不同模式直接切换的时候出现了问题，跟负责Vold的一起分析了一下，没有发现什么异常的地方。测试的时候发现，U盘存储的内容越多，出现卡顿情况的时间越长，可能与media进程有关。不管怎

最近在项目上，发现很多应用在开始滑动的时候，都会卡顿一下，看了一下systrace文件，可以看到在buildLayer的时候耗时比较长：      可以看到是在glTexImage2D耗时比较多。进一步使用GL Trace分析，可以看到：glTexImage2D(target = GL_TEXTURE_2D, level = 0, interna

对于做性能的人来说，知道时间的花在哪了是比较重要的，可以在函数前后得到系统的时间，计算时间戳能够得到每个函数的时间。在JAVA中可以通过System.currentTimeMillis()得到：long>View.draw(canvas);long>long>Log.i(TAG,"draw:>在native的代码中，可以通过下面的方式得到函数的执行时间：

周末在家没事，

Android 4.4在ART

好久没有在Android Performance领域有什么新发现了，今天在跟踪问题的时候，突然发现Android也可以看到这样的图：在Android上找这种类型的图找了两年了，终于找到了。在Android Performance这条路上略感迷茫的时候，能找到这种图像，又看到了希望，继续坚持奋斗ing。路漫漫其修远兮，吾将上下而求索。

说到Android性能栅栏，b

不知不觉中，我又回归做性能接近三个月了，在performance这条路上，我已经走过四个年头了。知道性能的人很少，做性能的人更少，喜欢做性能的人，几乎找不到多少了，期间的艰辛似乎只有经历过的人才能明白。回到做性能，与以前的感觉完全不一样。毕业以来，一直都从事performance相关的工作，即使有变动，但还是做performance，更知道自己喜欢什么，所以更懂得珍惜。回来以后，就开始处理各种各样的

对于做性能的人来说，不知道问题所在时，最好可视化它，而Memory一直以来，都是性能关注的重点，然而在Android上，却也只能dumpsys meminfo这种运行古老的命令行查看内存，VM的内存好一点，可以dump hprof文件查看，但也是Static的方式，或者使用LeakCanary，查看内存泄露，也都是在memory leak境界，没有到memory performance的地步。大概在

记得刚接触Android性能的时候，Android还是2.3，用的是TraceView，到Android 4.1的时候，又用了Systrace。TraceView可以称得上是Android APP的性能优化神器，然后Traceview的特点是对性能影响太大，几倍到几十倍的性能影响，导致很多时候，都不知道是代码的性能问题，还是工具本身的问题，虽然后来又采样的功能，但采样却是定期的去get thread

CPU是系统非常重要的资源，在Android中，查看CPU使用情况，可以使用top命令和dump cpuinfo。我记得很久以前，就发现这两者存在不同，初步猜测应该是算法上存在差异。最近需要采集应用CPU的使用率，看了一下两种CPU的计算方法。1、toptop是比较经典的CPU计算方法，top的代码在androidm/system/core/toolbox/top.c下面，输出process的cpu

android 性能优化

android 4.3系统上，应用可以使用     import android.os.Trace;     Trace.beginSection("TEST");     Trace.endSection();添加systrace跟踪，然后通过thon systrace.py --app=TEST 指定apk。framework的java层代码里面添加systrace跟踪

在Android中，可以四给不同层次上开启硬件加速：1、应用：2、Activity3、WindowgetWindow().setFlags(WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);4、View

无论在哪层，都需要TAG，JAVA层的TAG在Trace.java里定义：29 public final class Trace { 30    // These tags must be kept in sync withframeworks/native/include/utils/Trace.h. 31    public static final long TRACE_TAG_

Android 4.1以后加了一个新的性能分析工具：systrace，没有搜到什么好的的资料，去做Android性能分析的也很少，自己这段时间一直都在弄systrace，把它记下来。  systrace可以把函数流程及CUP状态有HTML表示出来，主要是针对UI的流程性分析的工具。使用使用systrace首先的安装SDK 20以上，Android 4.1以上才能使用，在SDK/tools/sy

毕业到现在，做了一年多的Android了，一直都在负责性能这方面，感觉这方面的东西太杂了，要学的很多，要了解的也很多，而且没有一个系统的分析方法，最近一直都在玩systrace，结合自己以前学的东西，总结归纳，似乎有了点入门的感觉。  性能大的方向有响应时间及吞吐量，Android这种智能终端上，一般响应时间比较多，主要是系统的流畅性。以前看到哪个地方不流程，都只能去打LOG分析，这个方法太低

十一前后，遇到了两个很有意思的问题，现在记下来。记得十一之前的一周，突然公司所有机型的截屏都不弄用了，这可让我郁闷了。截屏一直都是我在弄，从Android 2.3起，到Android 4.1，都自己都在弄，自己已经两三个月没有动代码了。在Android 2.3的时候，还经常动，原因是那是自己写的，先从PhoneWindowManager得到事件，发送broadcast从引用，应用从fb里读取数

在Android中绘图中，线程可以使用postOnAnimation函数，用于在系统进行下一次动画操作时，运行当前的线程，postOnAnimation(this)：    public void postOnAnimation(Runnable action) {        final AttachInfo attachInfo = mAttachInfo;        if

硬件加速不是万能的，使用的好可以使速度更快，使用方式不当，不仅得不到加速的效果，而且还可能会引起其他的问题，合适的，才是最好的。使用硬件加速的drawText函数调用流程如下:ViewRootImpl.java :scheduleTraversals()->TraversalRunnable->doTraversal()->performTraversals()->pe

最近的项目开机启动花了40多秒，正常开机只需要28秒就能开机起来。内核的启动我没有去分析，另一个同事分析的。我主要是分析从SystemServer启来到开机动画结束显示解锁界面的这段时间，也就是开机动画的第三个动画开始到结束这段时间，这是个比较耗时阶段，一般都在17秒左右(见过牛B的手机，只需5秒)。        SystemServer分两步执行：init1和init2。init1主要

型号分辨率HVGA320*480WVGA480*800QHD540*960HD720*1280FHD1080*1920

1.配置kernel，在config文件中删除下面的设定；# CONFIG_PERF_EVENTS is not set# CONFIG_HW_PERF_EVENTS is not set# CONFIG_PROFILING is not set# CONFIG_EVENT_TRACING is not set# CONFIG_EVENT_POWER_TRACING_DEP

1、列表滑动     记得从去年快放假的那两周，刚开始的时候，是很多人信息列表卡顿。通过不停的跟踪发现在显示文本的时候，Android不提倡使用硬件加速的方式。虽然Android 4.0以后，Android在很多地方都提倡用硬件加速的方式去绘图，以提高绘图效率，但对于中文的文本，这种方式是不可取的。原因在于中文编码比较多，而使用硬件加速的时候，进行了缓存操作，导致在中文文本比较多的

1、 主机安装bootchart工具 sudo apt-get install bootchart(Ubuntu)2、  生成支持bootchart的boot.img export INIT_BOOTCHART=truemake boot.img烧写boot.img到手机，重启手机3、  设定bootchart收集信息 的结束时间adb shell ‘echo 120>

对于从事Android开发的人来说，遇到ANR(Application Not Responding)是比较常见的问题。一般情况下，如果有ANR发生，系统都会在/data/anr/目录下生成trace文件，通过分析trace文件，可以定位产生ANR的原因。产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件

1、push gdbserver到手机，并修改为可执行权限。adb shell push gdbserver /system/bin/adb shell chmod 777 /system/bin/gdbserver2、得到进程号并attact上进程。adb shell ps |grep system_serveradb shell gdbserver :1234 --atta

内存分配一波三折，小结一下：1.      先尝试快速分配，其中会从不同的zone以及迁移类型上去尝试，失败的话就进入慢速分配，里面会再划分单页面从pcp上分配以及多页面从伙伴系统中分配。2.      尝试慢速分配，一般流程就是唤醒内存页面回收线程，然后尝试低水位分配 -> 忽略水位分配 -> 压缩内存分配 -> 直接回收内存分配 -> oom killer杀死线程分配 -> 压缩内存分

在dalvik中，GC的类型有三种：1、GC_EXPLICIT：    应用主动调用System.gc()产生的GC事件。2、GC_FOR_ALLOC：    内存分配时，发现可用内存不够时触发的GC事件。3、GC_CONCURRENT：    给java层的class分配内存后，计算已分配的大小达到阈值(当前DVM heap size小一点)时会触发的GC事件。

以前在chinaunix上发过一遍同样的文章，原文内容如下（http://blog.chinaunix.net/uid-23738462-id-3244927.html）：写程序的话，只要有思路，实现起来不会太难，而我们经常要做的是读别人的程序，自己写的程序如果没有好的注释的话，过一段时间以后，尚且不知道当时为什么这么写，何况是别人写的呢？在读别人程序的时候，弄清楚程序的流程是很重要的，输出程

通常，对应Linux的系统来说，可以通过cat /proc/meminfo查看内存的使用情况，Android是基于Linux的，所有也可以使用adb shell cat /proc/meminfo查看内存的使用情况，如下所示：MemTotal:        1893284 kBMemFree:          823932 kBBuffers:           30628

最近几个版本，发现公司产品的线上启动时间，突然增加了2s左右，而且线下测试也能够测试在低端机器上，耗时增加明显。复现问题因为在低端机器上很容易复现，于是用红米note 1s测试，对比前后两个版本A和B，B版本确实会比A版本平均慢2s左右。在测试过程中会重复的安装与卸载apk，有的时候发现B版本时间跟A版本一样，很是奇怪。多次确认环境后，发现B版本登陆与不登陆应用，启动时间差别很大。分析问题既然在登陆