如何定位framework层崩溃

在我们的漫漫解bug的路上，有一类bug是比较头疼的：崩溃在SDK实现代码中，例如下面这个：

  java.lang.NullPointerException: java.lang.NullPointerException
        at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2803)
        at android.view.View.getDisplayList(View.java:12709)
        at android.view.View.getDisplayList(View.java:12755)
        ...
        at android.widget.FrameLayout.draw(FrameLayout.java:467)
        at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2211)
        at android.view.View.getDisplayList(View.java:12711)
        at android.view.View.getDisplayList(View.java:12755)
        at android.view.HardwareRenderer$GlRenderer.draw(HardwareRenderer.java:1205)
        at android.view.ViewRootImpl.draw(ViewRootImpl.java:2193)
        at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2065)
        at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1874)
        at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1009)
        at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:4418)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:749)
        at android.view.Choreographer.doCallbacks(Choreographer.java:562)
        at android.view.Choreographer.doFrame(Choreographer.java:532)
        at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:735)
        at android.os.Handler.handleCallback(Handler.java:725)
        at android.os.Handler.dispatchMessage(Handler.java:92)
        at android.os.Looper.loop(Looper.java:137)
        at android.app.ActivityThread.main(ActivityThread.java:5063)
        at java.lang.reflect.Method.invokeNative(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:511)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:817)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:584)

这类bug往往是开发中的使用API不当，只是崩溃在SDK实现中。

头疼的是，虽然崩溃栈上有行数，但是由于Android版本和各种手机对源码都有修改，这个行数不是准确的，所以，从这个地方只能定位到函数。例如上例，只能定位到崩溃在ViewGroup#dispatchDraw这个方法中，而具体是由于哪个变量为空导致的空指针，则无能为力了。

如果是在开发中遇到这样的崩溃，能够复现，最简单的办法就是用Nexus系列手机，SDK版本能对上就能准确定位到问题出现的代码行数。这里不再详述。#Android开发一定要有亲儿子

如果实在后台发现这样的崩溃数据，如果你手上有产生这个崩溃的设备的话，那么下面的方法也许可以帮助定位问题。

找到SDK实现，反编译

这一步需要相应的设备，因为设备上是有SDK实现，有可能是jar包，有可能是odex，通常在 /system/framework里，在上述例子中，/system/framework/framework.jar就是要找的jar包。
根据找到的是jar包还是odex，选择不同的工具反编译。
反编译出来的smali代码中，会保留如下的行数信息：

.line 134
new-instance v0, Landroid/graphics/PointF;

invoke-direct {v0}, Landroid/graphics/PointF;-><init>()V

iput-object v0, p0, Landroid/view/ViewGroup;->mLocalPoint:Landroid/graphics/PointF;

.line 147
const/4 v0, -0x1

iput v0, p0, Landroid/view/ViewGroup;->mLastTouchDownIndex:I

.line 178
iput v1, p0, Landroid/view/ViewGroup;->mLayoutMode:I

阅读smali代码，对比源码

找到smali代码中的行数，阅读附近的源码，对比一份版本相近的SDK源码，就算是定制的rom，源码也不会修改太多。根据这个，能找到具体崩溃在什么地方。

通过上述方法，找到崩溃对应的代码：

for (int i = 0; i < childrenCount; i++) {
    int childIndex = customOrder ? getChildDrawingOrder(childrenCount, i) : i;
    final View child = (preorderedList == null)
            ? children[childIndex] : preorderedList.get(childIndex);
    if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) {
        more |= drawChild(canvas, child, drawingTime);
    }
}

这个时候再定位问题就方便很多了。

前提

简单来说，用上述方法需要两个前提条件：

1. 有崩溃发生的设备

2. 崩溃栈中有行数信息