成都微信网站建设报价单,企业管理咨询心得体会,学生网站建设实训报告,网站空间 域名背景 影响 西瓜之前存在过一类RenderThread闪退#xff0c;从堆栈上看#xff0c;全部都是系统so调用#xff0c;给人的第一印象像是一个系统bug#xff0c;无从下手。闪退集中在Android 5~6上#xff0c;表现为打开直播间立即闪退。该问题在2022年占据Native Crash Top5从堆栈上看全部都是系统so调用给人的第一印象像是一个系统bug无从下手。闪退集中在Android 5~6上表现为打开直播间立即闪退。该问题在2022年占据Native Crash Top52023年更是上升到到Top1。因此有必要投入时间和精力再重新审视一下这个问题。在历经多周的源码分析和排查后逐步明确了问题根因并修复最终取得了显著的稳定性收益和业务收益。 接下来我们将抽丝剥茧一步步深入分析这个历史遗留问题揭开它背后真正的原因。 基本信息 具体堆栈如下 堆栈都是系统的so调用不能明确具体闪退业务场景只能看出是RenderThread线程主动abort了。 根据abort message找到对应的abort代码在CanvasContext::requireSurface时闪退了代码如下 问题特征 问题集中在Android 5.0~6.0线程集中在RenderThread无明显机型、厂商特征。 RenderThread简介 为了便于理解下面的分析过程先对RenderThread简单的介绍。顺便看一下是怎么调用到CanvasContext::requireSurface的。 相关类图如下 相关源码frameworks/base/libs/hwui/renderthread RenderThread::threadLoop RenderThread继承自Thread和Singleton是一个单例模式的线程通过RenderThread.getInstance()获取。和主线程很像内部是一个通过for实现的无限循环不断从TaskQueue里通过nextTask函数获取RenderTask并执行RenderTask执行完后会按需调用requestVsync。核心代码在threadLoop函数中 ThreadedRender Java层通过ThreadedRender与RenderThread进行通信。当Window启用硬件加速时ViewRootImpl会通过HardwareRenderer.create()创建一个ThreadedRender实例。ThreadedRender在创建时会调用nCreateProxy在native层创建一个RenderProxy。ThreadedRender通过RenderProxy向RenderThread提交任务。 RenderProxy RenderProxy在创建时会同步创建一个CanvasContext再通过RenderThread.getInstance()拿到RenderThread实例。RenderProxy通过CREATE_BRIDGE定义了许多Bridge函数再通过SETUP_TASK把这些Bridge函数包装成RenderTask再通过postAndWait提交给RenderThread调用。postAndWait之后当前线程进入等待状态当对应的task执行完毕之后唤醒当前线程。以RenderProxy::createTextureLayer为例 CanvasContext RenderProxy把任务提交给RenderThread之后执行的实际上是CanvasContext::createTextureLayer就是在这里调用了requireSurface。 初步猜想 其他 App 相似问题修复 其他端App也曾有过requireSurface() called but no surface set! 相关闪退。原因是在Activity进行侧滑退出时侧滑框架需要强制对下层Activity进行绘制生成Bitmap再用这个Bitmap来实现Activity的切换效果。但由于下层Activity此前已处于不可见状态可能有业务层主动释放了下层Activity中的TextureView导致了no surface set的闪退。经过对西瓜的侧滑框架的源码分析发现不会产生此类问题因此西瓜的问题应该另有其因。 正面分析西瓜问题 问题的条件是mEglSurface EGL_NO_SURFACE看下mEglSurface赋值为EGL_NO_SURFACE的时机。 总共有两处 第一处CanvasContext::setSurface 这里总共两处mEglSurface赋值操作。一处直接赋值为EGL_NO_SURFACE另一处为mEglManager.createSurface的返回值。而mEglManager.createSurface在返回前判断如果是EGL_NO_SURFACE会主动abort显然createSurface的返回值一定不是EGL_NO_SURFACE。 void CanvasContext::setSurface(ANativeWindow* window) {if (mEglSurface ! EGL_NO_SURFACE) {mEglSurface EGL_NO_SURFACE;}if (window) {//不可能返回EGL_NO_SURFACEmEglSurface mEglManager.createSurface(window);}
}EGLSurface EglManager::createSurface(EGLNativeWindowType window) {EGLSurface surface eglCreateWindowSurface(mEglDisplay, mEglConfig, window, nullptr);LOG_ALWAYS_FATAL_IF(surface EGL_NO_SURFACE,Failed to create EGLSurface for window %p, eglErr %s,(void*) window, egl_error_str());return surface;
} 那么这里根据window是否为nullptr又可以分为两种情况 setSurface(nullptr)之后mEglSurface 最终赋值为 EGL_NO_SURFACE之后调用requireSurface发生abort。setSurface(window)第5行会先设置为EGL_NO_SURFACE在第10行createSurface返回之前此时在另外一个线程调用requireSurface也会发生abort。 第二处初始值 初始值为EGL_NO_SURFACE。只有调用CanvasContext::setSurface时mEglSurface 才会被赋值在此之前调用了requireSurface也会引发闪退。 class CanvasContext : public IFrameCallback {private:EGLSurface mEglSurface EGL_NO_SURFACE;
} 总结下来有三个时机调用requireSurface会导致闪退 多线程并发mEglSurface短暂为EGL_NO_SURFACECanvasContext::setSurface(nullptr)之后即mEglSurface被销毁CanvasContext::setSurface之前即mEglSurface未初始化 深入分析 7.0系统是如何避免这个问题的 从多维信息看出问题在6.0及以下版本发生。那么7.0上系统做了哪些优化是如何规避我们上面三种可能的情况的这些优化思路对我们解决问题能否提供帮助 对比6.0和7.0代码之后发现谷歌直接把requireSurface这个方法移除了 逐个翻看6.0~7.0上RenderThread相关的commit最终找到了这个commit(8afcc769)。这里确实是把requireSurface删除了并在createTextureLayer中调用了一下 mEglManager.initialize()。而EglManager::initialize里的实现是执行下EglManager的初始化这里跟6.0基本一致。 那6.0上的abort原来是可以直接删掉的吗如果是这样我们是不是可以有样学样尝试hook requireSurface把abort去掉再主动调用一下mEglManager.initialize从而达到这个commit相似的修复效果 在云真机上找了个6.0的设备把libhwui.so pull下来通过 readelf -sW libhwui.so查看requireSurface的符号。发现没有requireSurface的符号。解开so后发现requireSurface被inline进了createTextureLayer 再尝试一下hook requireSurface的上一层调用CanvasContext::createTextureLayer发现也没有对应的符号只有RenderProxy::createTextureLayer 的符号。如果采用7.0的修复方案需要修改的指令非常多。而且这个MR中还有其他改动要不要一起hook这些问题暂时还没搞清楚花大力气去做的话风险太高。 看起来参考7.0修复方案操作难度大并且不确定是否有效。我们先把它作为备选方案另谋出路 正面分析三种可能性 多线程问题 CanvasContext的createTextureLayer和setSurface相关代码都被RenderProxy转移到了RenderThread上执行而RenderThread又是单例的所以这里不存在多线程问题因此可以直接排除线程并发问题。 setSurface(null)导致 前面分析过setSurface(nullptr)也会导致EGL_NO_SURFACE。下面是ThreadedRender一个大概的调用时序图把几个可能产生EGL_NO_SURFACE的setSurface调用做了标记序号24就是的闪退函数requireSurface。时序图 可以看出在CanvasContext中setSurface的调用有initialize、swapBuffers、makeCurrent、updateSurface、destory、~ConvasContext。对应的java层调用为ThreadedRender中的的initialize、draw、createTextureLayer、updateSurface、destory、finalize方法。排除一些不会出现异常的方法 排除ThreadedRender.initialize initialize时java层传过来的surface做了判断保护可以确保surface不为nullptr因此可以排除initialize代码如下 排除ThreadedRender.draw draw对应的问题是swapBuffers失败。发生在swapBuffers失败时也就是eglSwapBuffers错误了。 系统有以下两种方式处置错误 EGL_BAD_SURFACE打印失败日志。但翻看多个跟踪日志均没有发现类似日志暂时不关注。其他EGL错误直接abort掉此时变成另外一个闪退因此可以排除。 综上对于swapBuffers失败这种情况可能存在但未发现相关报错日志暂时不作过多关注。相关代码如下 排除ThreadedRender.finalize ThreadedRender.finalize之后会在native层通过delete 释放RenderProxy和ConvasContext在~ConvasContext析构时调用setSurface(nullptr)。因此如果之后再调用requireSurface应该会发生SIGSEGV相关错误不可能出现surface not set异常。因此也可以排除掉。代码如下 剩余情况 排除了intialize、swapBuffers、finalize之后还剩下makeCurrent失败、updateSurface(nullptr)、destory都有可能产生问题上游调用比较多追踪起来依然比较困难暂时无法排除。 初始化前触发了requireSurface 一般来说setSurface的首次调用是在initialize中。那么如果在initialize之前就调用了requireSurface是不是就会出问题呢从前面的分析可以看出requireSurface的上游是java层的createTextureLayer而createTextureLayer的调用处只有一个在TextureView的getHardwareLayer中。 getHardwareLayer是View的一个方法默认返回null。从注释上也能看出在6.0上只有TextureView用到了这个方法调用处也只有移除在getBitmap中。在7.0上也是直接把getHardwareLayer从View中移除了变成TextureView的一个方法。而getBitmap是个public方法这里是可以被app调用到的。 闪退的前提条件 ThreadedRender.initialize还未调用ThreadedRender.destroy或者ThreadedRender.updateSurface(null)之后 在Java层触发requireSurface步骤如下 TextureView.getBitmap ThreadedRender.createTextureLayer ConvasContext::requireSurface 最终定位 验证分析结论 通过前面的分析找到了问题的前提条件并发现了一条触发requireSurface的方式。那么就可以结束纸上谈兵通过实操来在本地复现这个闪退来实锤前面的结论。 ThreadedRender.initialize还未调用 由于ThreadedRenderer不是公开api需要通过反射来创建实例。拿到实例后不调用其intialize方法直接反射调用createTextureLayer。代码如下 果然复现了requireSurface() called but no surface set! 这个问题 destroy或updateSurface(null) 通过反射创建ThreadedRender实例先执行ThreadedRender.intialize之后调用destroy或updateSurface清空surface最后调用createTextureLayer也成功复现了这个闪退。 业务场景定位 前面的复现只是从技术层面确认了问题发生的几种可能但还没有与业务场景关联起来。真实的问题是否在前面提到的这几种可能中间如果在的话那具体的调用点在哪又该如何修复 尝试在真实场景中复现 通过shaddow hook RenderProxy的Initialize、destroy、updateSurface、createTextureLayer等函数在hook函数中打印一些日志。由于RenderProxy可能存在多个实例需要在日志里加上RenderProxy实例的地址来方便追踪单个RenderProxy调用时序。 hook函数如下 尽管这个问题在android 6上闪退率比较高但我用6.0测试机跑自动化测试还是没有复现这个问题。 线上定位 问题不是必现的排查进程在线下难以为继。而只有在真实的业务场景中复现才能明确问题根因找到最佳修复方案。因此需要加把这些hook点上线进一步排查。上线无小事线下可以小步快走逐渐定位问题。但上线步子一定要稳不能迈太大。但也不能太小否则周期会拉的很长。所以既要保证有足够的信息排查也要尽可能的降低稳定性和性能影响。 明确业务堆栈 前面的hook方案只能确认真实业务场景是否也有调用时序问题并不清楚具体的业务调用堆栈。 从业务上层代码到异常点必然经过了ThreadedRender的Initialize、destroy、update、createTexture等方法那么通过java hook把这些方法hook住并打印堆栈应该就定位到业务代码。需要注意的是 稳定性问题 Java hook 目前主流的方案中还没有能达到线上大规模使用的水平只能小流量观察。 保障方案系统版本限制在6.0放量计划1%-5%-10%小流量观察。 性能问题 由于这些api调用频率可能很高也都在主线程直接打印堆栈会影响性能。真正需要关注的就是异常前的几次调用且有些case可以通过以下条件预判其余的堆栈都不必要甚至是干扰信息。需要关注的堆栈如下 initialize不需要堆栈。只要知道有没有调用过打印一行日志即可。destroy必须全部打印堆栈。发生在异常前无法预判过滤。updateSurfacesurfacenull时打印堆栈。surface不为null不会导致异常。createTextureLayer未初始化或者surfacenull时打印堆栈。只有这两种可能会有异常。 总结可以通过surface是否为null、initialize是否调用过这两个条件减少stackTrace。 在ThreadedRender中surface都被透传给了native层没有对应的Java引用需要手动维护一个java 层的实例。初始化状态可以通过反射ThreadedRenderer.mInitialized拿到不过既然已经hook intialize和destroy了这里也选择手动维护一个初始化状态毕竟可以减少一次反射调用。 public class ThreadedRenderer extends HardwareRenderer {private boolean mInitialized false;Overridevoid updateSurface(Surface surface) throws OutOfResourcesException {updateEnabledState(surface);//透传给了Native层Java层没有引用nUpdateSurface(mNativeProxy, surface);}
} Java hook伪代码如下 public static class ExtraInfo {private boolean isSurfaceNull true;private boolean mInitialized false;
}static MapObject, ExtraInfo infoMap new ConcurrentHashMap();private static ExtraInfo extraInfo(Object instance) {ExtraInfo threadedRendererInfo infoMap.get(instance);if (threadedRendererInfo null) {threadedRendererInfo new ExtraInfo();infoMap.put(instance, threadedRendererInfo);}return threadedRendererInfo;
}
public static boolean initializedHook(Object instance,Surface surface) {extraInfo(instance).mInitialized true;return (Boolean) Hubble.callOrigin(initializeHookEntry, instance, surface);
}public static void destroyHook(Object instance) {infoMap.remove(instance);Log.d(REPAIR, destroy, new Throwable());Hubble.callOrigin(destroyHookEntry, instance);
}public static void updateSurfaceHook(Object instance, Surface surface) {extraInfo(instance).isSurfaceNull surface null;if (surface null) {Log.d(REPAIR, updateSurface null , new Throwable());}Hubble.callOrigin(destroyHookEntry, instance);
}public static void createTextureLayerHook(Object instance) {ExtraInfo extraInfo extraInfo(instance);if (extraInfo.mInitialized || extraInfo.isSurfaceNull) {Log.d(REPAIR, createTextureLayer null , new Throwable());}return Hubble.callOrigin(createTextureHookEntry, instance);
} 线上日志 上线后成功采集到了关键的Java调用堆栈基本都集中在直播业务场景下初始化前调用requireSurface。也有一些零星的destroy之后requireSurface的case由于量级太小本文不做重点讨论。 ThreadedRender.Initialize之前 日志截图如下 调用时序问题确认 对于地址为0x814a0b0的RenderProxy实例没有它intialize相关调用日志只有一条createTextureLayer调用日志。可以明确这个RenderProxy实例是在initialize之前调用createTextureLayer导致闪退 Java 堆栈分析 Log.d会对过长的堆栈进行截取FrameLayout.onMeasure之前的都被截取了不过对于排查问题影响不大。 堆栈关键信息整理如下 闪退时正在执行onMeasure在com.bytedance.android.livesdk.chatroom.ui.LivePlayerWidget.loadSharedPlayer中调用了TextureView的getBitmap方法再到ThreadedRender.creatTextureLayer之后就发生了Native crash。 为什么没有intialize onMeasure会早于ThreadedRender.initialize执行吗 ThreadedRender.initialize和performMeasure相关的代码都在performTraversals中再次回到源码中去分析。从代码结构来看initialize前后都有measure相关操作。initialize之前通过measureHierarchy调用了performMeasureinitialize之后是直接调用performMeasure。由于measureHierarchy外部包了许多判断条件所以不能直接从代码行的上下关系得出measure早于initialize的结论但我们可以保持这个怀疑进一步验证。 这个方法过于巨大移除无关代码后如下 private void performTraversals() {if (mFirst) {mLayoutRequested true;}boolean layoutRequested mLayoutRequested (!mStopped || mReportNextDraw);if (layoutRequested) {windowSizeMayChange | measureHierarchy(host, lp, res, desiredWindowWidth, desiredWindowHeight);}if (mApplyInsetsRequested) {if (mLayoutRequested) {windowSizeMayChange | measureHierarchy(host, lp, mView.getContext().getResources(), desiredWindowWidth, desiredWindowHeight);}}if (mFirst || windowShouldResize || insetsChanged || viewVisibilityChanged || params ! null) {if (!hadSurface) {if (mSurface.isValid()) {if (mAttachInfo.mHardwareRenderer ! null) {hwInitialized mAttachInfo.mHardwareRenderer.initialize(mSurface);}}}if (!mStopped || mReportNextDraw) {if (focusChangedDueToTouchMode || mWidth ! host.getMeasuredWidth() || mHeight ! host.getMeasuredHeight() || contentInsetsChanged) {performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);}}}
}private boolean measureHierarchy(final View host, final WindowManager.LayoutParams lp,final Resources res, final int desiredWindowWidth, final int desiredWindowHeight) {boolean goodMeasure false;if (lp.width ViewGroup.LayoutParams.WRAP_CONTENT) {if (baseSize ! 0 desiredWindowWidth baseSize) {performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);if ((host.getMeasuredWidthAndState()View.MEASURED_STATE_TOO_SMALL) 0) {goodMeasure true;} else {performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);if ((host.getMeasuredWidthAndState()View.MEASURED_STATE_TOO_SMALL) 0) {goodMeasure true;}}}}if (!goodMeasure) {performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);}return windowSizeMayChange;
} 由于堆栈被裁剪了无法确认异常是从哪个分支过来的。不过没关系注意到当mFirsttrue时满足layoutRequested true会先调用执行measureHierarchy可以在本地模拟mFirsttrue这种情况即可验证。 本地通过onMeasure复现 本地写个demo在FrameLayout.onMeasure中立即调用TextureView.getBitmap并通过反射查看mFirst的值找个6.0的云真机验证一下。onMeasure会连续执行多次只有第一次的mFirst为true但没能复现问题代码如下 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {boolean firstreflectFirst();//反射获取mFirstactivity.log(mFirst first);Bitmap bitmap mTextureView.getBitmap(mBitmap);super.onMeasure(widthMeasureSpec, heightMeasureSpec);
} 再来看下mTextureView.getBitmap的实现 public Bitmap getBitmap(Bitmap bitmap) {if (bitmap ! null isAvailable()) {if (mLayer null mUpdateSurface) {getHardwareLayer();}}return bitmap;}public boolean isAvailable() {return mSurface ! null;}public void setSurfaceTexture(NonNull SurfaceTexture surfaceTexture) {mSurface surfaceTexture;} 可以看到要想执行到ThreadedRender.createTextureLayer还需要满足以isAvailable()为true手动调用一下TextureView.setSurfaceTexture就可以满足。 根据猜想再次编写代码终于复现成功 demo如下 mTextureView.setSurfaceTexture(new SurfaceTexture(0));protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {boolean firstreflectFirst();activity.log(mFirst first);;mTextureView.getBitmap(mBitmap);super.onMeasure(widthMeasureSpec, heightMeasureSpec);
} 尝试只在mFisrtfalse时执行getBitmap再次运行不崩了。可见异常的关键条件就是mFirst if (!first) { //没问题mTextureView.getBitmap(mBitmap);} 问题根因 梳理下整体流程。ViewRootImpl首次performTraversals时(mFirsttrue)onMeasure会早于ThreadedRenderer.initialize。而业务方在onMeasure中又调用了TextureView.getBitmap最终在native层会调用CanvasContext::requreSurface。由于还没有执行过CanvasContext::initialize当前mEglSurface为EGL_NO_SURFACE于是在Android5~6上触发了abort发生surface not set的异常。 总结起来在android6.0上ViewRootImpl首次performTraversals时如过在onMeasure中调用了TextureView.getBitmap就可能会发生这个异常。 线上还存在一些零星的destroy之后requireSurface、swapBuffers失败后requireSurface的异常由于排查思路大同小异这里就不展开说了。 修复方案 通过字节码插桩全局替换TextureView.getBitmap方法当ViewRootImpl.mFirsttrue时就返回默认值而不执行getBitmap原有逻辑这样就不会调用到ThreadedRender.createTextureLayer。 但由于mFirst只能通过反射获取这可能会影响performTraversals性能有没有性能更好的方案 通过代码分析发现performTraversals会经历layout阶段而layout之后View会增加一个PFLAG3_IS_LAID_OUT /**
* Flag indicating that the view has been through at least one layout since it
* was last attached to a window.
*/
static final int PFLAG3_IS_LAID_OUT 0x4;public void layout(int l, int t, int r, int b) { mPrivateFlags3 | PFLAG3_IS_LAID_OUT;
}public boolean isLaidOut() {return (mPrivateFlags3 PFLAG3_IS_LAID_OUT) PFLAG3_IS_LAID_OUT;
} 因此可以通过isLaidOut ()获取到这一个属性达到和mFirst基本一致的效果。 最终方案 插装替换全局TextureView.getBitmap调用增加textureView.isLaidOut()判断。 public static boolean isGetBitmapSafe(TextureView textureView) {return Build.VERSION.SDK_INT 23 || textureView.isLaidOut() || !AppSettings.inst().mFerretSettings.autoFixRequireSurface.enable();
}ReplaceMethodInvoke(targetClass TextureView.class, methodName getBitmap, includeOverride true)
public static Bitmap getBitmapHook(TextureView textureView) {return isGetBitmapSafe(textureView) ? textureView.getBitmap() : null;
}ReplaceMethodInvoke(targetClass TextureView.class, methodName getBitmap, includeOverride true)
public static Bitmap getBitmapHook(TextureView textureView, int width, int height) {return isGetBitmapSafe(textureView) ? textureView.getBitmap(width, height) : null;
}ReplaceMethodInvoke(targetClass TextureView.class, methodName getBitmap, includeOverride true)
public static Bitmap getBitmapHook(TextureView textureView, Bitmap bitmap) {return isGetBitmapSafe(textureView) ? textureView.getBitmap(bitmap) : bitmap;
} 修复效果 实验全量后requireSurface 相关crash明显下降观察两周业务指标没有明显劣化直播场景有正向收益符合预期。全量后量级大幅下降还剩下一小部分主要是老版本、以及一些少量的destroy、swapBuffer失败相关的问题。 业务收益看播渗透显著提升人均看播天数显著提升 稳定性收益Native Crash大幅下降 后续思考 这个requireSurface问题发生在RenderThread但造成问题的原因在主线程因此如果能在RenderThread线程发生native crash时抓到主线程java堆栈就可以定位到业务根因也就不需要一系列自下而上地代码分析来寻找hook点了。 因此后续有RenderThread线程异常时应该把主线程堆栈上报上来提高RenderThread问题的排查效率。 加入我们 我们是字节跳动西瓜视频客户端团队专注于西瓜视频 App 的开发和基础技术建设在客户端架构、性能、稳定性、编译构建、研发工具等方向都有投入。如果你也想一起攻克技术难题迎接更大的技术挑战欢迎点击阅读原文或者投递简历到xiaolin.ganbytedance.com。 最 Nice 的工作氛围和成长机会福利与机遇多多在上海和杭州均有职位欢迎加入西瓜视频客户端团队 文章推荐 客户端架构设计的过程 Android D8编译器“bug”导致Crash的问题排查 Baseline Profile 安装时优化在西瓜视频的实践
