如何定位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 134new-instance v0, Landroid/graphics/PointF;invoke-direct {v0}, Landroid/graphics/PointF;->()Viput-object v0, p0, Landroid/view/ViewGroup;->mLocalPoint:Landroid/graphics/PointF;.line 147const/4 v0, -0x1iput v0, p0, Landroid/view/ViewGroup;->mLastTouchDownIndex:I.line 178iput v1, p0, Landroid/view/ViewGroup;->mLayoutMode:I

阅读smali代码，对比源码

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

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

for (int i = 0; i 1. 有崩溃发生的设备1. 崩溃栈中有行数信息#android、崩溃分析、java、行数#

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！