在 ReactNative 的 App 中,集成 Bugly 你会遇到的一些坑

  • 时间:
  • 浏览:0

在国内,开发 App,一般全是会集成其他第三方服务的,同类:升级、崩溃分析、数据统计等等。而那些第三方服务,提供的 SDK ,通常不到 Native 层的,同类 Android 本来使用 Java 写的。而 ReactNative 本身 JavaScript 和 Native 层(Java层)的通信,人太好因此做的很好了,本来大每种情况汇报下,朋友只需要对那些 SDK 做另另一一八个简单的封装就需要正常使用它了。

在 Debug 模式下,会从本地开启另另一一八个 Packager 服务,因此 App 运行起来过后,直接从服务里拉取最新的编译后的 JS 代码,原先需要在开发阶段,做到代码实时更新的效果,只需要在设备上,重新 Load 一下即可。

Native 层的崩溃,和常规 App 一样,没那些好说的。这里只看 Js 层的崩溃信息。

因此正是因此 ReactNative 会在 Debug 模式下,Hook 住朋友的崩溃栈,从而会意味着着分析 Bugly SDK 无法搜集到对应的崩溃也就无法进行上报。

这也本来朋友无法精准定位出错代码和锁在源文件的根本意味着着分析。

原先的崩溃栈,人太好追到来,可读性非常的差,因此并全是不可读的。

http://reactnative.cn/docs/0.49/native-modules-android.html#content

在这里,就需要很清晰的看一遍,它有另另一一八个 fileName 和 lineNumber 另另一一八个属性,分别用来记录当前源码的文件和这段代码所在的行数。而回忆一下过后 Release 版本的 JS 代码,让我发现关于源文件和行号的信息,被剥离了。

我这里把关键信息截图出来看着更清晰。

前面的内容因此认真看一遍,应该太难发现此处本来对 JS 崩溃输出的格式化拉平成一行了,本来因此朋友要针对 Bugly 的崩溃栈编写解析脚本,就需要考虑到那些情况汇报。

ReactNative App 的打包,完整篇 借助了 react.gradle 你你什儿 文件,让我在 Android 工程的 build.gradle 文件中找到它。

http://localhost:10081/index.android.bundle?platform=android&dev=true

到此,朋友否是 完成了 ReactNative App,崩溃分析的另另一一八个完整篇 的链路逻辑,朋友只需要人个写个脚本工具,就需要帮朋友精准定位了。

本文说是 ReactNative 集成 Bugly 的其他坑,实际上讲的更多的是在生产环境下,怎样分析 ReactNative 的崩溃栈。那些被搜集的原始信息,怎样被还原成朋友需要的信息。

而在 ReactNative 项目中,因此是 Native 层再次出显的崩溃,那人太好不到那些差别,崩溃信息和朋友平时开发常规 App 一样。

过后也提到,Debug 模式下,因此触发了崩溃,会直接进入红屏情况汇报,显示当前崩溃栈的信息。你你什儿 功能,在朋友开发阶段,非常的好用,能快速定位那些的疑问。

原先的逻辑被封放入 ReactInstanceManager 类的 recreateReactContextInBackgroundInner() 依据中,有兴趣需要自行看看。

而在 ReactNative 的系统任务管理器中,实际上运行的是 Js 的代码,而它也是分 Debug 和 Release 的。

ReactNative 原生模块(中文文档):

这每种内容没那些好说的,全是标准话的流程。接下来朋友来看看集成它将面临的坑。

而在 Release 模式下,ReactNative 会将 JS 代码,整体打包,因此放入 assets 目录下,因此从这里去加载 JS 代码。

--sourcemap-output 命令非常的简单,只需要配置另另一一八个输出的文件名就需要了。

再来对照朋友的源代码验证一下。

从你你什儿 崩溃栈让我发现,人太好下面 Java 的栈,基本上不到任何信息。这里主本来阅读上面 TypeError 上面的信息。这里描述了 Js 层崩溃的所有信息,暗含错误和崩溃栈。

人太好主要工作卡在了后者,接下来让朋友具体看看那些的疑问。

在 Debug 模式下,运行朋友的 Packager Server ,因此在浏览器中访问:

ReactNative 在 Debug 的情况汇报下,人太好还是很贴心的,因此再次出显崩溃的 Bug,会直接出红屏,提示你崩溃的栈的具体信息,那些内容需要帮助你快速的定位那些的疑问。

人太好也如 map.js 脚本输出的一样。

点开看看,完整篇 看不懂,随便截个图让朋友感受一下。

注意看这里指定的 1004 行 1133 列,朋友运行一下,看看输出。

运行效果如下:

注意这段命令,需要在 ReactNative 目录的根目录下执行,否者会提示你没哟 node_module 。执行完成,就需要在 ReactNative 项目目录下,看一遍输出的 android-release.bundle.map 文件了。

首先,ReactNative 中 JavaScript 和 Native 层的通信,官方文档因此写的非常清楚了。在官方文档中,举了另另一一八个 Toast 模块的例子,写的很清晰,这里就不再赘述了,还不了解的,需要先看看文档。

只要 Release 和 Debug 一样,需要有不到清晰的崩溃栈,人太好那些的疑问就因此得到补救。因此当你使用 Release 包来触发另另一一八个崩溃的过后,你就会发现,它并全是一样的。

这里人太好是两行命令,先进入到 android 项目的目录,因此运行 ./gradlew installRelease 你你什儿 没那些好说的,因此运行失败,注意一下当前 shell 环境的目录路径。

原先的编译后的代码,查 Bug 查起来就非常的费时了,你首先需要根据当前版本发布出去的 Apk,因此根据其中的 index.android.bundle 文件,定位到具体的代码,过后再结合上下文全文搜索你的源代码,才能找到对应出错的代码。

而只要现在同样的代码,使用 Release 模式得话,则会直接崩溃了。

使用命令,需要直接安装另另一一八个 Release 版本到设备上。

人太好到这里,因此离朋友的答案,更近一步了,Android 混淆的 Mapping 文件,也全是朋友肉眼能清晰看懂的,朋友接下来只需要找到它的解析规则就需要了。

不到接下来来看看怎样定位到你你什儿 崩溃的真实代码,value@1004:1133 这里,本来线索。朋友把 Apk 解压,拿到其内 assets/index.android.bundle 文件,它其内本来朋友 ReactNative 编译好的 Js 文件,需要看一遍它的第 1004 行 1133 列,本来朋友需要定位的出了那些的疑问的代码。

https://bugly.qq.com/docs/user-guide/instruction-manual-android/?v=201710100170001

最方便的是,你直接点击崩溃栈的代码,会自动打开对应的 Js 文件。当然,因此是另另一一八个 Native 层的崩溃,人太好也会出红屏,因此点击太大能跳转。

请确保你的 Packager Server 保持运行的情况汇报下访问。

http://reactnative.cn/docs/0.49/native-modules-android.html#content

不过那些,还是期待国内环境下,更多第三方 SDK 能支持到 ReactNative,毕竟官方团队支持的肯定要比朋友人个写补丁脚原先的方便实用。

本文转自承香墨影博客园博客,原文链接:http://www.cnblogs.com/plokmju/p/7825865.html,如需转载请自行联系原作者

本期就来分享一下,怎样在 ReactNative 的基础之上,集成 Bugly。这里主本来看它的崩溃搜集,这也是 Bugly 的主要功能。对于崩溃的整理,我主要关心另另一一八个每种:

Release 包的 Js 一定是经过混淆的,会剥离掉其他必要的信息,那些被剥离的信息,意味着着分析朋友无法精准定位到代码的源文件上。

本文的分析全是基于最新的 ReactNative (v0.49) 版原先分析。

本来,因此你在 ReactNative 项目内,集成了 Bugly 过后。造的崩溃不到得到上报,检查一下人个编译模式,一定要切换到 Release 模式下。

Bugly 的注册不到那些门槛,这里直接使用人个 QQ 号就需要登录,创建另另一一八个专门为 ReactNative 测试的 App,因此根据文档绑定对应的 AppID 即可。

既然因此明确的知道,在 Release 下,会过滤掉其他关于源文件和行号的信息,就如同 Android 的混淆一样,那它否是 暗含同类对照关系的 Mapping 文件,需要帮助朋友还原回去?

最近开新项目,准备尝试一下 ReactNative,所过后期做了其他调研工作,ReactNative 的优点非常的明显,需要做到跨平台,除了少每种 UI 效果因此需要对不同的平台进行单独适配,其中的核心逻辑代码,全是需要重用的。本来因此最终用 ReactNative 得话,需要省出某一端的客户端开发人员。而我这里调研的主要方向,本来它对国内第三方 SDK 的支持。

这段代码,会很清晰的输出对应的源文件名和行号,以及错的字段,还是很清晰的。

这里看另另一一八个崩溃,第另另一一八个趋于稳定在 Js 层,第八个趋于稳定在 Native 层。

这里朋友直接在命令行里运行如下代码,就需要自动重新生成另另一一八个 index.android.bundle 文件,因此一同也会生产另另一一八个对应关系的 map 文件。

ReactNative 原生模块(中文文档):

而因此你查阅文档,让我发现 react-native 命令,还有另另一一八个可配置的参数 —sourcemap-output,它本来朋友需要的。

前面有点硬长,这里总结一下本小结的内容。

因此,因此你你什儿 崩溃是趋于稳定在 Js 层得话,它最终会把崩溃抛到 Native 层,同样也是需要统计的的。因此那些崩溃会被封装成另另一一八个 JavascriptException 抛出来,从而意味着着分析它们被简单的归为了 JavascriptException 。因此它们描述的是不同的 Bug,因此却被归位一类,原先过后查阅起来,就需要人工进行筛选。

Bugly 为了方便开发者查看,会将同类崩溃栈的崩溃,整合成另另一一八个,因此进行计数统计,只显示当前崩溃了有几个次和影响的人数。

很尴尬的是,人太好崩溃栈也被输出出来了,和前面红屏的截图对比一下,才能发现它们人太好是另另一一八个内容。因此,那些代码被混淆过了,因此 Native App 一样,混淆过的代码,反编译来看会变成 a.b.c ,这里的效果也是同类的。

解析你你什儿 source-map ,NodeJs 为朋友提供了另另一一八个专门的库来解析,这里太大解释,直接上代码。

需要看一遍它实际上是通过 react-native bundle 命令,通过增加参数的形式,输出 index.android.bundle 文件的。

Bugly 的集成,非常的简单。因此过后用过 Bugly 的,因此阅读 ReactNative 和 原生通信 这每种文档得话,差太大十分钟就需要集成完毕。

还不了解 ReactNative 和原生通信内容的,建议先阅读一下本文档了解一下。

这里给的例子,是另另一一八个 Js 层的崩溃,需要看一遍它崩溃栈中,很清晰的看一遍 App.js 文件的第 48 行 21列,会有另另一一八个 ReferenceError 的错误。

不清楚的需要查阅 Bugly 的文档:

需要很清晰的看一遍,在 Debug 和 Release ,分别使用的不同的依据,加载 JS 文件的。这里为那些要说到 ReactNative App 的编译模式呢?人太好和上面的逻辑有关系。

继续最终 node/modules 下的 react.gradle 文件。

此时,朋友再运行它就会直接意味着着分析崩溃,来看看崩溃的 Log 输出。

https://docs.bugsnag.com/platforms/react-native/showing-full-stacktraces/

原先面的内容需要了解到,Release 包同样也是需要定位到出错的代码的。因此,你依然需要全文的搜索这段代码,无法精准定位到具体出错代码所在的源文件,这是为那些?

完整篇 的说明,让我在你你什儿 网站上找到资料:

注意我这里本身 项目本来另另一一八个 Demo 项目,代码量比较少,还能准确的定位到那些的疑问,因此是另另一一八个实际的项目,在打 Release 包的过后,会将所有的 JS 文件完整篇 打包到 index.android.bundle 文件中去。在你你什儿 例子中,因此 props.username.name 这段代码,我在本来地方都用到得话,筛选它也是非常麻烦的。

不到朋友就需要找到 index.android.bundle 你你什儿 文件,是怎样产生的。

就需要看一遍当前 Debug 模式,App 所运行的 JS 代码。朋友直接根据出错代码,精准定位一下。