Android CPU FlameGraph

记得刚接触Android性能的时候，Android还是2.3，用的是TraceView，到Android 4.1的时候，又用了Systrace。TraceView可以称得上是Android APP的性能优化神器，然后Traceview的特点是对性能影响太大，几倍到几十倍的性能影响，导致很多时候，都不知道是代码的性能问题，还是工具本身的问题，虽然后来又采样的功能，但采样却是定期的去get thread stack，然后统计，显然这种方式不够精确。可能Google也发现了，Android上缺少针对系统的性能优化工具，于是在Android 4.1的时候，开发了Systrace，那个时候，Systrace很适合做Jank的问题，而且Systrace针对的是System，很长一段时间，我都在做System相关的Performance，于是经常用Systrace。Systrace需要对Framework的代码在method进入或退出的时候插入代码，所以Google在重要模块的关键路径，都有像：

private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) {
        Trace.traceBegin(Trace.TRACE_TAG_VIEW, "measure");
        try {
            mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
        } finally {
            Trace.traceEnd(Trace.TRACE_TAG_VIEW);
        }
    }

这样的代码。这种只Trace关键路径的方式，性能开销少，但因只追踪了部分函数导致信息的丢失，尤其在对应用做性能分析的时候，能使用Systrace地方很少，而损失了一个性能分析利器。

记得刚接触Systrace的时候，为了追踪系统代码，不停的在代码里面Trace.traceBegin和Trace.traceEnd这样的代码，然后编译，抓取Trace文件，就想如果我Debug的时候，可以在所有代码里面都自动添加好了这些代码，编译一遍，抓取Trace文件，分析问题，那该多爽呀！也就想想而已。最近，刚好在做一些代码注入相关的问题，有一天骑车上班的时候，正下着雨，我在想，如果在App里面自动注入Trace代码，那岂不是可以使用Systrace做App的性能分析。于是进行了大量尝试，大概花了一周左右的时间，期间过程不再累述，期间痛苦，亲历者自知。最终可以在Systrace里面Trace App代码:

只对Android App的代码进行了注入，当然，Framework的Java代码其实也可以同样实现，从而得到System更全面的信息。得到Trace文件以后，还可以对文件进行分析，得到Android CPU FlameGraph：

对于热点函数，一目了然。
如果说以前对应Respond Timer的问题，还有所畏惧的话，在能够使用Android App Systrace结果以后，在对代码不甚了解的情况下，问题也显得明了了很多，已经不在畏惧了。

自此，对于Android的Performance两个重要方面：Memory跟CPU，都可以得到FlamGraph，明白人却太少，有种知我着为我忧，不知我着为我何求的感觉。这个世界上，会说的比会做的活的更好，显然我不会说，对于很多东西，就像靖王评价誉王一样：

我学不来，也不想学。

最近，还跟UC、架构及WebView的人跟踪内存的问题，感慨良多。问题比较诡异，我本以为我会在这个问题上湿鞋的，因为问题根本上无重下手，只有应用的代码，没有系统代码，而问题出现的GL的内存分配上，而且还需要面对外界的各种纷扰。于是用了几个周末及晚上的时间，最后发现是VM的内存耗尽导致GL申请不到内存而奔溃。分析完了这个问题以后，对于Android Performance Trouble Shooting无所畏惧了，但也不是太想做这种活了，吃力不讨好，但无论怎样，只求问心无愧吧，何必要求太多，Android性能似乎变味了一样，不在是对技术的一种执着，太伤心，太悲哀了！

都说在工作5年左右，会迷茫、失落，我是凡人，显然也逃不过这种宿命，但我依旧坚持自己的原则，自己的梦想。

大丈夫有所为，有所不为。
我不断失望，不断期望。

最近天冷，注意防寒。