查找android应用崩溃_已发布的Android应用中的崩溃检测

最新推荐文章于 2021-12-01 14:03:05 发布

weixin_26739079

最新推荐文章于 2021-12-01 14:03:05 发布

阅读量766

点赞数

文章标签： android python 安卓 android studio leetcode

原文链接：https://medium.com/tech-iiitg/crash-detection-in-published-android-app-21466f5cd38c

版权

查找android应用崩溃

In the process of building an Android Application, while testing we face a lot of crashes. We detect a crash, fix it and this cycle repeats until and unless our application is built completely and it’s crash-free. And then, after months of hard work, we finally push our application to the Play Store.

在构建Android应用程序的过程中，我们在进行测试时会遇到很多崩溃。我们检测到崩溃，将其修复，此循环重复进行，直到并且除非我们的应用程序完全构建且没有崩溃。然后，经过几个月的努力，我们终于将应用程序推送到Play商店。

“Tough times over. Now let’s relax and binge series!

艰难的时期结束了。 现在让我们放松和狂欢系列！

. . . But that’s not the case.”

。。。 但是事实并非如此。”

To elaborate the discussion, lets have a conversation between me and my friend:-

为了详细讨论，让我和我的朋友之间进行对话：-

Tony Stark:- Hey Sayantan, I am throwing a party tonight at my place. It’s based on my Android Application finally ready for production. You are cordially invited.

托尼·史塔克(Tony Stark)：嗨，萨彦坦，今晚我要在自己的地方举办一个聚会。它基于我的Android应用程序，最终可以投入生产。诚挚地邀请您。

Me:- That’s awesome news. Congrats buddy. I will attend it for sure.

我：-这真是个好消息。恭喜你。我肯定会参加。

Tony Stark:- Thanks :)

托尼·史塔克(Tony Stark)：-谢谢：)

Me:- So who’s in charge for maintaining the Application?

我：-那么谁负责维护应用程序？

Tony Stark:- Maintenance… Umm… No one for now. Well, I don’t need any recent update and it’s completely bug-free as of now.

托尼·史塔克(Tony Stark)：-维护……嗯……暂时没有人。好吧，我不需要任何最新更新，并且到目前为止，它是完全没有错误的。

Me:- Well Tony, that’s not the case. There may be cases when other devices may face CRASH, although your device might be crash-free.

我：-托尼，事实并非如此。尽管您的设备可能没有崩溃，但在某些情况下其他设备也可能面临崩溃。

Tony Stark:- Now that’s horrible. How come another device faces Crash?

托尼·史塔克(Tony Stark)：-现在太可怕了。另一个设备如何面对崩溃？

Me:- Well the primary reason for this is due to different manufacturers present out in the world. Many manufacturers use their own CUSTOM Operating System, customizing different aspects of a device. And these customizations can bring out issues with the application in these devices, thus leading to performance issues and finally CRASH!

我：-好吧，主要原因是由于世界各地存在不同的制造商 。许多制造商使用自己的CUSTOM操作系统来定制设备的不同方面。这些自定义可能导致这些设备中的应用程序出现问题，从而导致性能问题并最终导致崩溃！

Tony Stark:- Never thought like that. Any example where different manufacturers cause problems?

托尼·史塔克(Tony Stark)：从来没有那样想过。是否有其他制造商引起问题的示例？

Me:- Background threading requires more handling in Chinese manufactured devices than the Stock Android device, as they tend to stop Services on its own due to Battery Optimisation.

我：- 后台线程在中国制造的设备中比在股Android设备上需要更多的处理，因为由于电池优化 ，它们倾向于自行停止服务。

Tony Stark:- Okay that’s a good example. Any other cases where different devices may cause Crash?

托尼·史塔克(Tony Stark)：-好的，这是一个很好的例子。其他情况下，其他设备可能会导致崩溃？

Me:- The change of the Android SDK version can also lead to CRASH, as maybe there was a feature that works in the newer SDK version, but not in previous SDK versions and vice versa.

我： -Android SDK版本的更改也可能导致CRASH，因为可能有一个功能在更新的SDK版本中起作用，但在以前的SDK版本中不起作用，反之亦然。

Tony Stark:- Yes, the Application built may not be Backward Compatible. I have taken care of it in various places but don’t know if I have introduced it in all the places.

Tony Stark：-是的，所构建的应用程序可能不是向后兼容的。 我已经在各个地方进行了处理，但是不知道是否在所有地方都进行了介绍。

Me:- Yes Tony. You got my point.

我：-是的，托尼。你明白我的意思。

Tony Stark:- So how can we get the crash reports in any device through my Application. Should I go on and check it out in every possible device?

Tony Stark：-那么我们如何通过我的应用程序在任何设备上获取崩溃报告。我应该继续在所有可能的设备中进行检查吗？

Me:- Well that’s a solution but it’s a bad one. We can use Firebase Crashlytics for gathering all the crash reports and displaying all of them into a user-friendly Dashboard.

我：-嗯，这是一个解决方案，但是很糟糕。我们可以使用Firebase Crashlytics收集所有崩溃报告，并将所有报告显示在用户友好的仪表板中。

Tony Stark:- Wow, seems interesting. Tell me more about it. Is it difficult to handle?

托尼·史塔克(Tony Stark)：哇，看起来很有趣。告诉我更多关于它。处理困难吗？

Me:- Actually, It’s one of the easiest things to implement in an Android Application. Let’s discuss it in detail.

我：-实际上，这是在Android应用程序中最容易实现的事情之一。让我们详细讨论它。

FIREBASE CRASHLYTICS控制台 (FIREBASE CRASHLYTICS DASHBOARD)

To solve the above problem, Firebase Crashlytics comes into the picture. Firebase provides a dashboard where we can visualize all the crashes happening to a user using an application.

为了解决上述问题， Firebase Crashlytics进入了图片。 Firebase提供了一个仪表板，我们可以在其中可视化使用应用程序发生给用户的所有崩溃。

In the image we can see, we have a Crash-free statistics graph (crash-free users v/s date), Event trends graph (No. of crashes v/s day). Under the Issues domain, we can get the list of all the crashes along with its meta-data like Version of App affected, No. of Events, and No. of Affected Users.

在图中可以看到，我们有一个无崩溃统计图表 (无崩溃用户v / s日期)， 事件趋势图表 (崩溃数量v / s日)。在“ 问题”域下，我们可以获得所有崩溃的列表及其元数据，例如受影响的应用程序版本，事件数和受影响的用户数。

We see a Filter button at the top, where we can further filter the crashes based on Version-number, OS model, and Android SDK. These can be helpful in filtering in the following ways:-

我们在顶部看到一个过滤器按钮 ，我们可以根据版本号，操作系统模型和Android SDK进一步过滤崩溃。这些有助于通过以下方式进行过滤：-

Version-number:- It will help us to understand which sort of users facing this crash.
版本号：-这将帮助我们了解遇到这种崩溃的用户类型。
OS Model:- Many times, some manufacturer’s phones may restrict from performing a certain action, resulting in a crash. We can sort out the data based on this.
操作系统型号：-很多时候，某些制造商的电话可能会限制其执行某些操作，从而导致崩溃。我们可以据此整理数据。
Android SDK:- It is really helpful for checking crashes regarding backward compatibility.
Android SDK：-这对于检查与向后兼容性有关的崩溃确实很有帮助。

Now let’s analyze what we will get when we click on a crash report. For eg, let us click on the first Crash displayed in the above issues section.

现在，让我们分析单击崩溃报告时会得到什么。例如，让我们单击上述问题部分中显示的第一个崩溃。

In this image, we can see a graph analysis of the number of events of crashes that took place, along with the breakdown of the Manufacturer, Operating System, and State of Device in which it happened.
在此图中，我们可以看到发生的崩溃事件数量的图形分析，以及发生崩溃的制造商，操作系统和设备状态的细分。
At below, we get the Sessions summary containing the whole Stack Trace of the Error. So, developers will get to use this data to trace the error in the code and can fix the error.
在下面，我们获得了Sessions摘要，其中包含Error的整个堆栈跟踪 。因此，开发人员将可以使用此数据来跟踪代码中的错误并可以修复错误。
Apart from the Stack Trace, externally Keys and Logs can be passed to gather more knowledge of the CRASH.
除了堆栈跟踪，还可以从外部传递键和日志，以收集有关CRASH的更多知识。

建筑概述 (ARCHITECTURAL OVERVIEW)

Through this, we can track the crashes happening in various devices. For this, we have to set up the Android Project to Firebase and add the Firebase Crashlytics SDK dependency in the build.gradle(app) file.

通过这种方式，我们可以跟踪各种设备中发生的崩溃。为此，我们必须将Android项目设置为Firebase，并在build.gradle(app)文件中添加Firebase Crashlytics SDK依赖项。

Now we can have two types of crashes reports:-

现在我们可以有两种崩溃报告：

The first one is the general crashes, those crashes which stop the application at once. These are tracked automatically by the Crashlytics along with the whole stack trace, device information, affected users, etc and reported to the dashboard. All the graphs and statistics charts are auto-generated at the server-side.
第一个是一般崩溃 ，这些崩溃会立即停止应用程序。 Crashlytics会自动跟踪这些信息以及整个堆栈跟踪，设备信息，受影响的用户等，并报告给仪表板。所有图形和统计图都是在服务器端自动生成的。
The other being non-fatal-crashes, which don’t stop the application, instead throw an error in a try-catch block. We can introduce it at a specific try-catch block of our code, and if the method throws an exception, we can log its Crash report.
另一个是非致命崩溃，不会停止应用程序，而是在try-catch块中引发错误。我们可以在代码的特定try-catch块中引入它，如果该方法引发异常，则可以记录其Crash报告。

实施方法 (IMPLEMENTATION APPROACH)

General crashes are tracked automatically, with no additional requirement. For the non-fatal-crashes, we can introduce it inside the Exception block of a try-catch.

常规崩溃是自动跟踪的，没有其他要求。对于非致命的崩溃，我们可以将其引入try-catch的Exception块中。

try {

尝试 {

// some code which may result into exception

//一些可能导致异常的代码

}

}

catch (exception: Exception) {

捕获 (例外：异常){

Crashlytics.setUserIdentifier(“user_ID”)

Crashlytics.setUserIdentifier( “ user_ID” )

Crashlytics.log(“Message_To_Identify_this_TryCatch_Block”)

Crashlytics.log( “ Message_To_Identify_this_TryCatch_Block” )

Crashlytics.logException(exception)

Crashlytics.logException(例外)

}

}

Now, these exceptions are not generalized to everyone in nature; i.e can cause trouble to some specific users. So we can receive the user ID by setting a setUserIdentifier. We can log a custom message to identify the appropriate try-catch block. At last, we call the log exception(exception) to log the crash to Crashlytics.

现在，这些例外并不自然地适用于所有人。即会给某些特定用户带来麻烦。因此，我们可以通过设置setUserIdentifier来接收用户ID 。我们可以记录一条自定义消息，以标识适当的try-catch块。最后，我们调用日志异常(exception)将崩溃记录到Crashlytics。

There may be cases in which one of the many ways can throw the exception. So, in this case, we can put keys to further analyze the nature of the exception. We can set String, Int, Float, Double, or Bool values.

在某些情况下，许多方法之一可能会引发异常。因此，在这种情况下，我们可以放置键以进一步分析异常的性质。我们可以设置String，Int，Float，Double或Bool值。

Crashlytics.setString(key_name, “value”)

Crashlytics.setString(key_name， “ value” )

防火墙中的算法Firebase使用 (ALGORITHM FIREBASE USE IN CRASHLYTICS)

According to the flowchart, we have to just introduce the non-fatal-crash (as fatal crashes will be gathered automatically), and firebase will take care of reporting. So the advantage is, it remains offline until and unless it gets uploaded, for a longer period. Also, firebase uses the best possible way to store the data, so storage is not an issue here. The disadvantage it has to offer is that if a user uninstalls the app after the crash, the crash would not get uploaded.

根据流程图，我们只需要介绍非致命崩溃 (因为致命崩溃将被自动收集)，firebase将负责报告。因此，好处是， 它会保持离线状态，直到(除非上载)它的时间更长 。此外，firebase会使用最佳的方式来存储数据，因此此处的存储不是问题。它必须提供的缺点是，如果用户在崩溃后卸载了该应用程序，则崩溃将不会被上传。

测试方法 (TESTING APPROACH)

After the SDK is plugged in and enabled in the Firebase dashboard, it doesn’t require any additional setup. Firebase Crashlytics start observing for crashes. For testing purposes, we can force a crash to check if everything is working as expected or not.

在Firebase仪表板中插入并启用SDK后，不需要任何其他设置。 Firebase Crashlytics开始观察崩溃。出于测试目的，我们可以强制崩溃以检查一切是否按预期工作。

Crashlytics.getInstance().crash()

Crashlytics.getInstance()。crash()

We can now attach the above command on a button click, and on pressing the button would crash the App and we can check about its report in the dashboard.

现在，我们可以在单击按钮时附加上面的命令，按下按钮将使应用程序崩溃，我们可以在仪表板上查看其报告。

结论 (CONCLUSION)

So, as we had seen so far, Firebase Crashlytics comes up with a bunch of features for tracking crashes occurring in different devices. It is very easy to implement and so it is recommended to incorporate it into the Android application before publishing it for production. In this way, we get to know about the run time crashes happening at different devices and we have the chance to fix them. Thus with the next release, our application is more bug-free and users would love using it.

因此，到目前为止，我们已经看到，Firebase Crashlytics提供了许多功能来跟踪发生在不同设备中的崩溃。它非常易于实现，因此建议在发布它以进行生产之前将其合并到Android应用程序中。通过这种方式，我们可以了解在不同设备上发生的运行时崩溃，并且我们有机会对其进行修复。因此，在下一个发行版中，我们的应用程序将更加无缺陷，用户将喜欢使用它。

Cheers. Happy Developing. Thank you :)

干杯。 愉快的发展。 谢谢：)