首页 > 最新公告 > 免SDK集成 360加固保推出应用“崩溃日志分析”服务

免SDK集成 360加固保推出应用“崩溃日志分析”服务

日期:2016-03-23
      在移动应用发展趋近红海的今天,一款APP想要脱引而出,除了产品本身的创新外,APP的良好的兼容性一定是提高竞争力的重要方面,而应用崩溃问题无疑是衡量兼容性好坏的关键。

      应用崩溃问题的现状和影响
      由于Android智能手机种类繁多、系统版本各异,使Android生态系统的碎片化问题严重。这意味着开发者不得不花费更多时间,使应用适配更多种设备和系统,即使在模拟器上运行良好的应用程序,安装到某款手机上说不定就出现崩溃问题。很显然,开发者不可能购买所有设备逐个调试,这也注定了Android应用无法逃避崩溃的命运。
      直接受到应用崩溃问题影响的就是用户,应用程序在运行过程中出现崩溃,打断了用户正在进行中的操作,这无疑是用户体验中最糟糕的现象。而对于开发者而言,则要承受由于崩溃问题带来的ARPU下降、用户流失、差评、口碑降低等一系列等风险问题。

      开发者如何获取应用崩溃信息?
      开发者及时、精准的获取应用崩溃信息,对产品兼容性提升、性能优化起着至关重要的作用。通常,开发者获取应用崩溃信息的途径有三种。
      第一种,用户通过电话、邮件等反馈渠道,主动向开发者提供应用崩溃信息,这类用户基本属于APP的忠实用户,但这类获取崩溃信息的方式属于极少数,且崩溃问题已经发生,影响了忠实用户的使用体验。
      第二种,开发者通过用户在应用市场上的评论来发掘崩溃问题。但由于用户描述的信息不全面,通常开发者很难追踪和定位到问题所在。通常,如崩溃问题发生在应用使用过程中,70%的用户会给予差评!一款APP出现大量差评,势必会影响它的口碑和下载量。
      第三种,开发者使用第三方SDK来获取应用崩溃信息。开发者通过在自己的APP源码中集成、配置SDK,然后根据SDK文档来调用相关接口,从而完成崩溃信息的收集。很显然,使用SDK这样的方式需要开发者花不少心思,提高了开发者的开发成本。除此以外,有些开发者可能会选择自己开发崩溃信息收集的功能,这样一来,开发者的成本将会大大提升,首先开发者要维护崩溃信息收集的代码,其次必须搭建服务器来收集和存储APP从用户处收集的崩溃信息,而且要对崩溃信息进行统计分析、归类等,即便如此,自己开发的崩溃信息收集功能也不能保证高质量的工作,因为有些情况下的崩溃信息可能无法收集上来。

      Android应用崩溃的分类
      应用崩溃即Crash,Android Crash主要分为两类,Java Crash和Native Crash。Java Crash在用户使用时的表现形式是,应用程序运行时异常退出,在用户手机上弹出提示框,这类一般是由Java层代码错误引起的。Native Crash的表现形式是在应用程序异常退出时,没有任何提示,程序直接闪退到系统桌面,这种是由Native层错误代码引起的。但无论是Java Crash,还是Native Crash,一旦出现了,应用程序就出现直接闪退、程序黑屏、程序白屏,有的甚至直接使手机死机、重启等问题,严重影响用户体验。

      360加固保应用“崩溃日志分析”服务特点
      1. 免SDK集成
      目前有不少第三方Crash Report SDK,开发者需要在自己的apk源码中集成SDK,那么作为一个开发者,他的开发成本就相应的增加了很多。
      首先,开发者必须学会如何使用SDK,阅读SDK文档,了解其中的API接口,之后才能调用SDK中的API。除此之外,开发者必须得在Android Studio或者eclipse等IDE中配置好SDK的一些使用参数等,但是,这有时并不是一件简单的事,需要一定开发成本。
      再次,由于SDK本身也会存在一些问题(比如Bug,需要优化等),所以必然需要升级更新,那么开发者为了能够使用更优质的服务,就必须紧跟SDK的版本升级,不断在自己的源码中更改SDK,这其实是比较麻烦的事。
      为了免去开发者的开发成本,360加固保推出免SDK应用崩溃日志分析服务。无需任何开发过程,只需上传APP进行应用加固,2分钟左右,即可掌握最全面的应用崩溃信息。同时,APP具备了防反编译、防破解的能力,轻松提升APP安全性。
      2. 提供Native层崩溃日志收集功能,且兼容性强
      由于Native层崩溃日志收集的功能涉及Android系统较低层的一些系统机制,其内容较复杂,实现难度较大。所以目前市场上能够提供针对Native层的崩溃收集功能的厂商并不多。即使能够提供Native层的崩溃日志收集,在兼容性方面也存在各种问题。
      360加固保可以针对Java层和Native层的崩溃日志进行全面收集,且无论是 ARM32,X86_32还是ARM64的架构,都能收集到崩溃信息。
      360加固保自己实现了一套收集崩溃日志的接口,并不依赖系统本身提供的崩溃日志相关接口。这样,即便某款手机上的Android系统是基于手机厂商特殊定制的,不提供崩溃日志相关接口,360加固保也能正常收集到此款手机上面的崩溃信息。
      3. Native层收集的崩溃数据更加全面
      与其他第三方应用崩溃信息厂商相比,360加固保收集的Native层崩溃日志数据更全面,更方便开发者根据这些崩溃信息进行Bug追踪和修复。360加固保收集的崩溃日志信息见图1至图5。

图1加固保收集的应用崩溃信息

图2加固保收集的应用崩溃信息

图3加固保收集的应用崩溃信息

图4加固保收集的应用崩溃信息

图5 360加固保收集的应用崩溃信息
      4. Native层崩溃日志模拟Android系统收集的崩溃日志,开发者阅读时更方便
      Android系统本身自带崩溃日志收集功能,图6至图8是Android系统为崩溃进程收集的崩溃日志详情:

图6 Android系统收集的崩溃日志详情

图7 Android系统收集的崩溃日志详情

图8 Android系统收集的崩溃日志详情
    通过与360加固保收集到的崩溃信息对比,可以发现,360加固保提供的崩溃日志详情和Android系统收集的基本没有区别,甚至比某些手机系统上面收集的崩溃日志还要详细。由于开发者在平时调试Native层代码时,习惯看到的是Android系统打出来的Log,所以如果与Android系统收集上来崩溃日志详情的相似,可以说开发者看上去会非常亲切,免去开发者重新学习如何查看的烦恼。
      5. 所需要获取的apk权限最少
      因为收集到的应用崩溃日志需要上传至服务器,所以APP必须有一些网络相关权限。图9是360加固保所需获取的apk权限,只有三个。更少的权限对用户来讲,就意味着少了很多的安全风险;对于开发者来讲,也不必因为收集崩溃信息而添加过多的apk本身并不使用的权限。

图9 360加固保所需获取的apk权限
      6. Native层支持多进程的崩溃日志收集
      360加固保提供的崩溃日志分析服务,无论是Android中动态链接库so中fork出来的进程,还是Service组件的进程,凡是Native层出现了崩溃,都会被Native层崩溃信息收集功能察觉,并生成相应的崩溃信息。