• 当我们的 app 开发完成 并切 上线之后, 会被

    当我们的 app 开发完成 并切 上线之后, 会被  很多用户去使用,在他们使用的 过程中 可能会 由于各种原因 导致  程序 崩溃 ,如果我们不关心这个问题, 就不可能 做出 健壮的 app。


    我们可以自己 写 code 来 捕获异常 ,在 app 崩溃之前 将  异常内容 固化成文件 ,在 app 下次 启动时   再将 异常 信息 上传到 我们的服务器  供我们 分析  , 也可以使用  统计平台都  错误分析 功能  ,百度或者 友盟 都有  错误 统计 和分析 功能 。


    具体怎么使用 统计 sdk , 下载完 sdk 后 文档 说的都很清楚,我就不 解释了 。


    下 面说一下 ,获取到 异常 信息后 如何 使用  dwarfdump 工具 在 .dsym文件中 找出  出错的 代码 位置 。

    1、首先 你要 有 dsym 文件才行   ,dsym 文件的位置  由于 打包的方式不同 可能  不同 ,如果你是 直接 build 出来的  ,那么 在 你 对应的  .app 文件相同目录下就可以看到 dsym文件,如果你是  菜单栏中  product -> archive  ,archive 完了 打开 Organizer ->Archives  中 打的包 ,那么你的 dsym 文件将在 对应 的 archive 中的 dsyms 文件夹下 。

    2、获取 异常日志 

    登录友盟统计平台 ,进入制定 app ,点击 左边栏 里的 错误分析 , 这样就可以看到 错误列表 ,

    比如:

    Application received signal SIGSEGV 2.1.5 20865 2014-06-06 15:31:55
    点击该错误 可以看到 详细信息

    Application received signal SIGSEGV
    (null)
    (
    	0   CoreFoundation                      0x2f471f23  + 154
    	1   libobjc.A.dylib                     0x39f38ce7 objc_exception_throw + 38
    	2   CoreFoundation                      0x2f471e4d  + 0
    	3   aaaaaaaa                        0x8aa981 _ZNSt3__113__vector_baseIP10OneRequestNS_9allocatorIS2_EEED2Ev + 1134736
    	4   libsystem_platform.dylib            0x3a55071b _sigtramp + 34
    	5   aaaaaaaa                        0x7439e9 _ZNSt3__113__vector_baseIP9OnePacketNS_9allocatorIS2_EEED2Ev + 3044
    	6   aaaaaaaa                        0x749769 _ZN14BasicHashTable8IteratorD2Ev + 568
    	7   aaaaaaaa                        0x760f93 _ZN12THREAD_MUTEXC2Ev + 12810
    	8   libsystem_pthread.dylib             0x3a554959  + 140
    	9   libsystem_pthread.dylib             0x3a5548cb _pthread_start + 102
    	10  libsystem_pthread.dylib             0x3a552ae8 thread_start + 8
    )
    
    dSYM UUID: 8AA8370C-D292-3051-BF23-B46128B941E2
    CPU Type: armv7
    Slide Address: 0x00004000
    Binary Image: FengYunZhiBo
    Base Address: 0x00025000
    3、使用 dwarfdump 导出 异常信息 

    进入 终端 输入,$dSYMPath  就是 第一步获取的  dsym 文件的路径 ,然后回车,就可以看到 错误信息了


    dwarfdump --arch=armv7 --lookup 0x8aa981 $dSYMPath

    0x0172f6da: Compile Unit: length = 0x00005ec0  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x0173559e)


    0x0172f6e5: TAG_compile_unit [233] *

                 AT_producer( "Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)" )

                 AT_language( DW_LANG_C99 )

                 AT_name( "libavformat/rtpenc.c" )

                 AT_low_pc( 0x008a9e14 )

                 AT_stmt_list( 0x0027eb6a )

                 AT_comp_dir( "/Users/fyzb0/Desktop/ffmpegFastBuild/build/src/ffmpeg-2.1" )

                 AT_APPLE_optimized( 0x01 )


    0x01734bec:     TAG_subprogram [351] *

                     AT_name( "rtp_write_packet" )

                     AT_decl_file( "libavformat/rtpenc.c" )

                     AT_decl_line( 483 )

                     AT_prototyped( 0x01 )

                     AT_type( {0x01730ca0} ( int ) )

                     AT_APPLE_isa( 0x01 )

                     AT_low_pc( 0x008aa37c )

                     AT_high_pc( 0x008aaba4 )

                     AT_frame_base( r7 )

                     AT_APPLE_omit_frame_ptr( 0x01 )


    0x01734c8b:         TAG_lexical_block [51] *

                         AT_ranges( 0x0011e928

                            [0x008aa5b4 - 0x008aab8c)

                            [0x008aab96 - 0x008aaba4)

                             End )

    Line table dir : 'libavformat'

    Line table file: 'rtpenc.c' line 322, column 0 with start address 0x00000000008aa968


    Looking up address: 0x00000000008aa981 in .debug_frame... found!


    0x00036e30: FDE

            length: 0x0000000c

       CIE_pointer: 0x00000000

        start_addr: 0x008aa37c rtp_write_packet

        range_size: 0x00000828 (end_addr = 0x008aaba4)

      Instructions: 0x008aa37c: CFA=4294967295+4294967295









    展开全文
  • IOS 友盟错误分析

    2015-08-02 18:23:11
    IOS友盟错误分析方法总结



    以上为友盟错误信息


    1. 找到当时打包应用发布时的归档文件  *.xcarchive   , 打开里面,找到  dSYMs  文件夹里面的  *.dSYM 文件,将其拷贝出来。(将它拷贝到系统根目录,方便命令行的操作)。

    2. 打开终端,进入到第一步   *.dSYM 文件  所在的文件夹。

    3. 点击友盟错误信息里面的内存地址,会弹出一个提示窗口,如下: 


    4. 拷贝后面的一行命令,例如上图中的:
    dwarfdump --arch=armv7 --lookup 0xe284b "$dSYMPath"


    5. 将4步骤中的命令行复制到终端,将后面的  “$dSYMPath”  替换成当前  *.dSYM 的路径。以下是我的命令行:
    dwarfdump --arch=armv7 --lookup 0xe284b jzm.app.dSYM


    6. 执行命令后,会出来错误结果: 


    7. 根据错误提示,就可以找到错误的地方了。



    提示:
    有些友盟错误信息,有多个错误地址,最好每个都执行命令试一下,这样能够更准确地找到错误地方。













    展开全文
  • 目录(?) [-] ...通常我们都会在系统中接入统计系统,在系统崩溃的时候记录下崩溃日志,下次启动时将日志发送到服务端,比较好的第三方有umeng之类的。今天我们来讲一下通过崩溃日志来分析定位我们的bu

    
    
    目录(?)

    1. 前言
    2. dYSM文件
    3. 崩溃日志
    4. 提取崩溃日志中有用的信息
    5. 开始分析
    6. 查找bug
    7. 结语

    前言

      iOS分析定位崩溃问题有很多种方式,但是发布到AppStore的应用如果崩溃了,我们该怎么办呢?通常我们都会在系统中接入统计系统,在系统崩溃的时候记录下崩溃日志,下次启动时将日志发送到服务端,比较好的第三方有umeng之类的。今天我们来讲一下通过崩溃日志来分析定位我们的bug。

    dYSM文件

      分析崩溃日志的前提是我们需要有dYSM文件,这个文件是我们用archive打包时生成的.xcarchive后缀的文件包。一个良好的习惯是,在你打包提交审核的时候,将生成的.xcarchive与ipa文件一同拷贝一份,按照版本号保存下来,这样如果线上出现问题可以快速的找到你想要的文件来定位你的问题。

    崩溃日志

    崩溃日志都会像下面这样:

    NSConcreteMutableAttributedString addAttribute:value:range:: nil value
    (null)
    ((
        CoreFoundation                      0x0000000185c642f4 <redacted> + 160
        libobjc.A.dylib                     0x00000001974880e4 objc_exception_throw + 60
        CoreFoundation                      0x0000000185c64218 <redacted> + 0
        Foundation                          0x0000000186a9dfb4 <redacted> + 152
        Xmen                                0x10073fb30 Xmen + 7600944
        Xmen                                0x1006bbbf4 Xmen + 7060468
        UIKit                               0x000000018a9a47fc <redacted> + 60
        UIKit                               0x000000018a9a512c <redacted> + 104
        UIKit                               0x000000018a6b2b6c <redacted> + 88
        UIKit                               0x000000018a9a4fd4 <redacted> + 444
        UIKit                               0x000000018a78e274 <redacted> + 1012
        UIKit                               0x000000018a999aac <redacted> + 2904
        UIKit                               0x000000018a785268 <redacted> + 172
        UIKit                               0x000000018a6a1760 <redacted> + 580
        QuartzCore                          0x0000000189fe9e1c <redacted> + 152
        QuartzCore                          0x0000000189fe4884 <redacted> + 320
        QuartzCore                          0x0000000189fe4728 <redacted> + 32
        QuartzCore                          0x0000000189fe3ebc <redacted> + 276
        QuartzCore                          0x0000000189fe3c3c <redacted> + 528
        QuartzCore                          0x0000000189fdd364 <redacted> + 80
        CoreFoundation                      0x0000000185c1c2a4 <redacted> + 32
        CoreFoundation                      0x0000000185c19230 <redacted> + 360
        CoreFoundation                      0x0000000185c19610 <redacted> + 836
        CoreFoundation                      0x0000000185b452d4 CFRunLoopRunSpecific + 396
        GraphicsServices                    0x000000018f35b6fc GSEventRunModal + 168
        UIKit                               0x000000018a70afac UIApplicationMain + 1488
        Xmen                                0x1008cf9c0 Xmen + 9238976
        libdyld.dylib                       0x0000000197b06a08 <redacted> + 4
    )
    dSYM UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85
    CPU Type: arm64
    Slide Address: 0x0000000100000000
    Binary Image: Xmen
    Base Address: 0x000000010007c000

    是不是看的一脸懵逼,下面我来教大家如何结合crash log 与 dYSM文件 来分析定位出代码崩溃在哪一个文件的哪一行代码

    提取崩溃日志中有用的信息

    • NSConcreteMutableAttributedString addAttribute:value:range:: nil value 崩溃的原因是value为nil
    • ” 4 Xmen 0x10073fb30 Xmen + 7600944” 它指出了应用名称,崩溃时的调用方法的地址,文件的地址以及方法所在的行的位置,我们需要的是这一个:”0x10073fb30”。
    • “dSYM UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85”。
    • “CPU Type: arm64”。

    开始分析

    • 打开终端进入到你的dYSM文件的目录下面: 
      cd /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs
    • 验证下崩溃日志中的UUID与本地的dYSM文件是否是相匹配的: 
      “Xmen”为你的app名称 
      dwarfdump --uuid Xmen.app.dSYM 
      结果是:
    UUID: BFF6AE00-8B5F-39BD-AFD0-27707C489B25 (armv7) Xmen.app.dSYM/Contents/Resources/DWARF/Xmen
    UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85 (arm64) Xmen.app.dSYM/Contents/Resources/DWARF/Xmen
    • 1
    • 2
    • 1
    • 2

    发现与我们日志中的:UUID和CPU Type是相匹配的

    • 查找错误 
      dwarfdump --arch=arm64 --lookup 0x10073fb30 /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen
      “arm64”与”0x1008cf9c0”分别对应于上面我们从日志中提取出来的有用信息 
      “/Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen”对应于你本地dYSM文件目录 
      “Xmen”对应于你的app名称 

      dwarfdump --arch=arm64 --lookup 0x1000551ec SP2P_7.app.dSYM/Contents/Resources/DWARF/SP2P_7


      结果像下面这样:
    File: /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen (arm64)
    Looking up address: 0x000000010073fb30 in .debug_info... found!
    0x00219b05: Compile Unit: length = 0x00003dd0 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0021d8d9)
    0x00219b10: TAG_compile_unit [107] *
    AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.42.1)" )
    AT_language( DW_LANG_ObjC )
    AT_name( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
    AT_stmt_list( 0x001272a9 )
    AT_comp_dir( "/Dandy/checkSvn/IOS/xmen" )
    AT_APPLE_major_runtime_vers( 0x02 )
    AT_low_pc( 0x000000010072b8ac )
    AT_high_pc( 0x000000010074e350 )
    0x0021aec5: TAG_subprogram [119] *
    AT_low_pc( 0x0000000100739810 )
    AT_high_pc( 0x000000010074006c )
    AT_frame_base( reg29 )
    AT_object_pointer( {0x0021aee3} )
    AT_name( "-[DSSellerOrderSectionHeaderView updateContentWithOrderData:isEdit:]" )
    AT_decl_file( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
    AT_decl_line( 248 )
    AT_prototyped( 0x01 )
    0x0021af36: TAG_lexical_block [138] *
    AT_ranges( 0x00008640
    [0x000000010073cf90 - 0x000000010073fb88)
    [0x000000010073fbc0 - 0x000000010073fbc4)
    End )
    Line table dir : '/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View'
    Line table file: 'DSSellerOrderSectionHeaderView.m' line 680, column 9 with start address 0x000000010073faf8
    Looking up address: 0x000000010073fb30 in .debug_frame... not found.
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29

    我们来从终端结果来分析出我们想要的结果: 
    这一行告诉我们崩溃的代码所在的文件的目录

    Line table dir : '/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View'
    • 1
    • 1

    这一行告诉我们崩溃代码所在的具体文件

    AT_decl_file( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
    • 1
    • 1

    这一行告诉我们崩溃代码是在哪一个方法里面

    AT_name( "-[DSSellerOrderSectionHeaderView updateContentWithOrderData:isEdit:]" )
    • 1
    • 1

    这一行告诉我们崩溃代码具体在哪一行了

    Line table file: 'DSSellerOrderSectionHeaderView.m' line 680, column 9 with start address 0x000000010073faf8
    • 1
    • 1

    好的,现在我们分析到了崩溃代码在哪一行了,下面我们来找一找bug

    查找bug

      我们的代码都应该有托管平台,每个版本上线都需要打一个tag,这是一个好习惯。下面我拉下我崩溃的对应版本的tag,找到崩溃代码那一行:

      结合崩溃日志中告诉我:崩溃的原因是value为nil,发现是因为receiverTelephone字段中有中文导致转url时为nil导致的,下面的解bug就看各自本领啦。

    结语

      希望对您有帮助,谢谢支持~

    参考文章:

    http://www.cocoachina.com/ios/20150720/12627.html

    http://www.jianshu.com/p/115ef29b2c90

    http://blog.csdn.net/u012072580/article/details/53739688


    附上:

    $ dwarfdump --uuid SP2P_7.app.dSYM UUID: AEE06486-ECFB-3D44-8446-422378ED8399 (armv7) SP2P_7.app.dSYM/Contents/Resources/DWARF/SP2P_7 UUID: 0CEB8AEB-2FA9-3501-A9E9-3FF5D149A763 (arm64) SP2P_7.app.dSYM/Contents/Resources/DWARF/SP2P_7 $ dwarfdump --arch=arm64 --lookup 0x100348fdc /Users/mz/Desktop/111/2017_8.7.4.xcarchive/dSYMs/SP2P_7.app.dSYM/Contents/Resources/DWARF/SP2P_7



    展开全文
  • IOS友盟统计Bug追踪

    2015-05-27 10:12:15
    项目开发之初安卓和IOS都是使用Bugly来统计bug的后期IOS上线过程中被退回提示一个关于Bugly的upload的一个方法冲突,然后IOS就改用友盟的,不过比较头疼的是捕获的IOS问题并不像安卓一样能够清晰,只显示内存地址,...

    项目开发之初安卓和IOS都是使用Bugly来统计bug的后期IOS上线过程中被退回提示一个关于Bugly的upload的一个方法冲突,然后IOS就改用友盟的,不过比较头疼的是捕获的IOS问题并不像安卓一样能够清晰,只显示内存地址,前期没有经验导致IOS打包人员没有保存xcarchive文件,也就无法定位了。最新的版本上线了让其发给我当前版本的xcarchive来定位分析bug,在网上搜索了一下,使用一个工具(dSYM文件分析工具)来分析。

    1、准备内容

    dSYM文件分析工具,当前发布版本的xcarchive文件,当前发布版本的友盟Bug记录

    2、操作说明

    打开dSYM文件分析工具(图1),将xcarchive文件拖到“请将dSYM文件拖拽到窗口中并选中任意一个版本进行分析”,然后点击拖拽的文件,会出现图2会自动填写选中dSYM文件的UUID。


    图1


    图2

    打开友盟选择一个bug记录,如下:

    -[NSNull rangeOfCharacterFromSet:]: unrecognized selector sent to instance 0x197941e70
    (null)
    (
    	0   CoreFoundation                      0x00000001854802f4 <redacted> + 160
    	1   libobjc.A.dylib                     0x0000000196ca40e4 objc_exception_throw + 60
    	2   CoreFoundation                      0x00000001854873a4 <redacted> + 0
    	3   CoreFoundation                      0x0000000185484154 <redacted> + 928
    	4   CoreFoundation                      0x0000000185386ccc _CF_forwarding_prep_0 + 92
    	5   UIKit                               0x000000018a236c44 <redacted> + 104
    	6   UIKit                               0x000000018a3a52c0 <redacted> + 76
    	7   UIKit                               0x000000018a3a5380 <redacted> + 56
    	8   UIKit                               0x000000018a3a5464 <redacted> + 36
    	9   QuartzCore                          0x0000000189800884 <redacted> + 320
    	10  UIKit                               0x0000000189ed1f94 <redacted> + 160
    	11  UIKit                               0x0000000189f973d0 <redacted> + 348
    	12  UIKit                               0x000000018a1b5be8 <redacted> + 3220
    	13  UIKit                               0x0000000189fa1268 <redacted> + 172
    	14  UIKit                               0x0000000189ebd760 <redacted> + 580
    	15  QuartzCore                          0x0000000189805e1c <redacted> + 152
    	16  QuartzCore                          0x0000000189800884 <redacted> + 320
    	17  QuartzCore                          0x0000000189800728 <redacted> + 32
    	18  QuartzCore                          0x00000001897ffebc <redacted> + 276
    	19  QuartzCore                          0x00000001897ffc3c <redacted> + 528
    	20  QuartzCore                          0x00000001897f9364 <redacted> + 80
    	21  CoreFoundation                      0x00000001854382a4 <redacted> + 32
    	22  CoreFoundation                      0x0000000185435230 <redacted> + 360
    	23  CoreFoundation                      0x0000000185435610 <redacted> + 836
    	24  CoreFoundation                      0x00000001853612d4 CFRunLoopRunSpecific + 396
    	25  GraphicsServices                    0x000000018eb776fc GSEventRunModal + 168
    	26  UIKit                               0x0000000189f26fac UIApplicationMain + 1488
    	27  ?????????                           0x00000001000450c4 ????????? + 200900
    	28  libdyld.dylib                       0x0000000197322a08 <redacted> + 4
    )
    
    dSYM UUID: 95B2009C-C988-****-****-8393E7003FA8
    CPU Type: arm64
    Slide Address: 0x0000000100000000
    Binary Image: ???
    Base Address: 0x0000000100014000
    首先对应bug中的dSYM UUID跟dSYM文件分析工具中的UUID是否一样。

    在Bug记录中一般带有项目名称的或者由于乱码导致???的那行代码就是项目错误行拷贝内存地址

    0x00000001000450c4
    Slide Address: 0x0000000100000000
    dSYM文件分析工具中,点击分析按钮,在有可能错误的地方就会显示当前内存地址对应的代码行。



    最后到项目中找到对应的行查找问题就可以了。


    展开全文
  • 相信有很多开发者在项目中加入了友盟统计,其中一个最主要的功能就是查看线上版本统计到的错误。但是当你看到这样的信息时: 会不会有这样的想法: 这尼玛到底是什么鬼?!! 此时你可能会百度...

    0.jpg

    作者:@__weak_Point 授权本站转载。

    First

    相信有很多开发者在项目中加入了友盟统计,其中一个最主要的功能就是查看线上版本统计到的错误。但是当你看到这样的信息时:

    1.jpg

    会不会有这样的想法:

    blob.png

    这尼玛到底是什么鬼?!!

    此时你可能会百度(干得漂亮!),我相信你“闪闪”的双眼肯定会看到这篇文章的:dSYM文件分析工具。具体用法我就不重复了,博主写的很详细,而且这个工具真的真的很好用!

    Second

    但是,友盟还统计到了这么一堆错误:

    wrongMessage2.jpg

    blob.png

    这尼玛又是什么鬼?!!怎么会这么多!

    点进去看到是这样的:

    wrongMessage3.jpg

    用咱们上面说的工具:

    AnalysisTool.jpg

    这、这、这让我怎么玩,还能不能愉快的玩耍了…T_T

    当然,这并不只在“Application received signal SIGSEGV (null)”这种情况下才发生,这时怎么办呢?不要捉急,少年请看这里: 解析iOS崩溃日志(crash Log)

    Third

    上面这两种方法应该就可以解决大部分友盟统计到的错误了,这时你要说了,这两种方法都解决不了的怎么办?少年,此次此刻我要传授你一招江湖失传很久的绝学秘笈:把那些无法解决的错误全部勾选上,然后选择把状态标记为“处理中”,然后再标记为“已修复”,怎么样,骚年,是不是解决了!2333,但是少用为好,原因你懂的。

    At last

    最后感谢 answer-huang 和 裂云野 的博文分享。

    展开全文
  • 登陆友盟官网找到友盟统计,找到你iOS平台下你所属的APP(图1) 图1 点击进去会出现当日错误列表,选择你发生错误的日期(图2) 图2 我们可以看到,这一天中出现了两个错误,每个...
  • react native 友盟统计的Android端集成可参考 :https://www.jianshu.com/p/1c41d4b66312 希望大家少走些弯路吧。 下面介绍下IOS 端的集成: 步骤 ios端的sdk集成 ios 和rn 的交互类 工程的相关配置 (初始化sdk)...
  • 具体友盟官方解释的很清楚。只是文档东西太多不太好找,如下: http://bbs.umeng.com/thread-6383-1-1.html Q:为什么一直没有自定义事件的数据? A:1.统计自定义事件的数据首先需要在后台添加...
  • 好记性不如烂笔头,之前一直使用的友盟统计APP线上崩溃日志,今天研究了腾讯下的Bugly,发现比友盟更简单(单纯的收集崩溃日志),之所以这么说,个人觉得有两点:1、继承简单;2、定位到具体代码简单(可能是因为...
  • 友盟统计中,其中有一个错误统计板块,可以自动上传错误统计,或者上传自定义的错误统计,不过友盟中的这一部分,只是说了这么几句话,没有详细的说明怎么使用 **************************************************...
  • 转自:http://www.xmsdn.net/iso/ios-crashanalyze/CrashAnalyze查找友盟统计提交的闪退日志,代码具体位置的方法:一,通过命令行查找 1, 将打包的Archives 文件中dSYM 目录下TaQu.app.dSYM 文件 和 Applications ...
  • 之前也有用过这个方法,现在来系统的总结一下,当app上线之后,通过第三方(比如友盟)收集bug后,如何定位到具体的错位代码。1.使用dsym工具定位bug 1.1在友盟中得到如下的崩溃日志 1.2下载dsym分析工具, 下载...
  • iOS 友盟统计的bug分析

    2019-07-25 12:31:29
    前提:保留打包发布时的 myapp.xcarchive文件(注:在xcode-window-Organizer-Archives 中可以找到,通过命令打包需要...2、找到一条该版本app 在友盟bug统计中崩溃日志的,在其中可以找到崩溃时的地址信息如:0x1...
  • 项目经理决定在关键模块进行友盟统计的埋点。 之前我们的App已经集成了友盟SDK,主要是为了利用友盟的自动化收集机制,收集程序崩溃信息。这次利用SDK提供的功能,决定进行更细致的埋点统计,主要是为了解决出现...
  • 一、集成友盟统计友盟统计平台查看集成文档 二、错误处理 1.打开前往文件夹输入 "~/资源库/Developer/Xcode/Archives/" 前往; 2.找到对应打包的时间文件夹下的 "项目名 2018-4-24 14.34.xcarchive" 文件;...
  • 项目中集成了友盟统计,自然Crash日志已经在友盟的统计之中,点击错误分析可以看到相关的错误列表,以及简单的crash日志。 如果想看详细的crash详情则需要使用友盟的错误分析工具:umcrashtool 下载友盟Crash分析...
  • 友盟统计与崩溃日志

    2019-10-03 01:10:49
    友盟统计与崩溃日志 友盟统计,包含:用户分析: 新增用户、活跃用户、启动次数等;留存统计:留存用户、用户新鲜度,用户活跃度;用户参与度:使用时长,使用频率统计,访问页面,使用间隔等。在友盟统计中默认...
  • 崩溃问题是日常开发中亟需解决的问题之一,线上的问题更是如此,应用中经常嵌入第三方统计平台,如友盟也提供了不错的日志收集能力,以下就介绍下对于友盟统计收集到的应用崩溃信息,如何基于符号表.dSYM文件进行...
  • 一般项目中集成统计功能随因产品类型不同而使用功能不同,但大多数统计一般只有一个目的,就是记录用户习惯,研究用户习惯,从而为用户带来更好的体验。...这里记录一下之前在项目中使用友盟统计时的过程和踩过的坑。
  • IOS友盟统计功能 集成步骤: 去友盟官网注册账号,并且添加应用: http://www.umeng.com/apps/63b400d599e85e76ec565655/appkey 下载IOS版本的SDK。 导入SDK 请在你的工程目录结构中,右键选择Add->...
1 2 3 4 5 ... 20
收藏数 1,605
精华内容 642