Android-Tips（实用Android开发技巧）

整理本人实际开发中遇到的一些问题以及解决办法和一些开发技巧，以后会不定时更新。

tip:利用“目录”可快速导航

1.追溯sdk中某一个类随sdk版本升高导致的历史变迁。（find API changes）

问题来源：SwipeRefreshLayout源码：判断子View是否能向上滚动（或者是否滚动到顶部）：

    /** * @return Whether it is possible for the child view of this layout to * scroll up. Override this if the child view is a custom view. */
    public boolean canChildScrollUp() {
        if (android.os.Build.VERSION.SDK_INT < 14) {
            if (mTarget instanceof AbsListView) {
                final AbsListView absListView = (AbsListView) mTarget;
                return absListView.getChildCount() > 0
                        && (absListView.getFirstVisiblePosition() > 0 || absListView.getChildAt(0)
                                .getTop() < absListView.getPaddingTop());
            } else {
                return ViewCompat.canScrollVertically(mTarget, -1) || mTarget.getScrollY() > 0;
            }
        } else {
            return ViewCompat.canScrollVertically(mTarget, -1);
        }
    }

进入Android开发官网，假如要查看View API的变化，输入View,选择android.view.View，如图：

进入View的API参考页面（文档页），如图：

从图中可以看到三个主要信息：

• View是在API level 1添加的
• View的类层次
• 通过左侧的API level choose button 可以查看不同API level下的View API，进行纵向的查看,同时可以将不同API level下的View API进行横向对比。

追溯API 变化就是通过上述第三条实现的。比如我们想看看API level 13和 API level 14之间有什么变化，将左侧API level设置为13,查看方法列表：

我们会发现一些API 是灰色的，当鼠标hover过方法名时，会显示出一个提示，如图：

这个提示告诉我们：View中的canScrollVertically(int direction) 方法是在API level 14以后才添加的，另外canScrollHorizontally(int direction) 也是API level 14以后才添加的方法。当我把API level 切换到14时，发现上述两个方法的颜色变为蓝色了，说明他们的确是在API level 14添加的：

总结：

使用这种方法的好处是不用下载每一个api 版本的源代码，也可以很方便的对比他们之间的变化。开发参考除了可以对比方法的变化以外，还可以对比内部类，接口等变化，当前选中的API level 为9，结果如图：

2.使用device monitor 中的method profiling 工具寻找app卡顿的元凶

问题来源：使用RxJava时，出现莫名的卡顿，方法嵌套过深，或类关系过于复杂，难以定位问题。

进入sdk->tools文件夹。双击运行monitor.bat 打开device monitor：

左侧Device tab下是当前的设备名以及待调试应用的包名。在要测试某个操作（方法调用）之前，点击method profiling 按钮，弹出对话框：

输入采样间隔：

输入采样间隔，间隔越大，采集到某个方法调用栈的可能性就越小，可能漏掉某个调用栈，越小，采样精度越高（或者说覆盖率越高）但是采样间隔太小，会导致卡顿。所以需要输入一个合适的采样间隔。输入后点确认，然后在app上执行你的操作，执行完后点stop method profiling,会生成一个名为“ddms+时间戳+.trace”的文件，这个文件记录了方法的调用栈信息，这个文件是我们分析的重点:

视图中上一栏，展示了在method profile过程中并行执行的所有线程或进程。下一栏的表格展示了方法的调用信息，如方法名，所耗时间，cpu占用等。可参考：http://blog.csdn.net/androiddevelop/article/details/8223805

表格中相关列名的说明：

点击表格每一栏的名字可以进行排序，根据Name找到上述操作调用的方法，如fetchData:

Parents值得是fetchData的调用入口，而Children指的是fetchData方法中的子调用。
可以看出每个子调用或父调用的耗时情况，fetchData中的子调用fetchDataImpl耗时22.777ms,继续点击fetchDataImpl可以进入fetchDataImpl的调用栈，分析方式就同fetchData了，通过这种方式可以定位耗时操作的源头：

总结：

使用method profiling可以分析方法的调用栈，找出app的性能瓶颈。android device monitor的功能很强大，是一个工具的合集，还可以分析Heap Dump,Allocation,Network,查看Device的文件等。好的工具可以提升开发效率，科学使用工具可以事半功倍。另外推荐一款在线app 冷启动性能分析工具：Nimbledroid 可以分析app 冷启动的调用栈，通过分析app冷启动调用栈，可以找到影响app的启动速度的因素。另外，Nimbledroid上可以查找到许多app不同版本的冷启动调用栈信息，我们可以从中借鉴加速app启动的方式。

以后会不定时更新，未完待续。