iOS 如何调试第三方统计到的崩溃报告

iOS线上版本崩溃调试 背景介绍: 客服接到部分用户反映,好医网患者端在点击浏览“用户订单”功能时,程序发生闪退现象,且用户重新安装程序并更新程序和iOS系统至最新版本后,问题依旧没有解决。 现状:从用户的角度来看,在好医网患者端APP上发生交互,产生订单的用户,应该作为我们的真实有效用户,而解决当前线上崩溃的问题与否,直接关系到这部分真实用户的用户体验。按照线上统计分析,发生该问题的用户数量是2. 阅读详情

有一点要记住,不要指望着复现bug靠断点调试,有些bug,例如多线程引起的,很难复现


核心命令

dwarfdump --lookup 0x0007434d  -arch arm7 uau1.3.0.app.dSYM
  • 1

dSYM文件

XCode中 
Window->Organizer->选择提交到App Store的Archies->右键,showin finder 
右键->显示包内容,在dsym文件件里的就是符号表文件。这里包含着debug信息 

或者window->Orgainzer,直接download dsym


崩溃报告

以我收到的这个为例

-[NSNull length]: unrecognized selector sent to instance 0x198705e70
(null)
(
    0   CoreFoundation                      0x00000001862442f4 <redacted> + 160
    1   libobjc.A.dylib                     0x0000000197a680e4 objc_exception_throw + 60
    2   CoreFoundation                      0x000000018624b3a4 <redacted> + 0
    3   CoreFoundation                      0x0000000186248154 <redacted> + 928
    4   CoreFoundation                      0x000000018614accc _CF_forwarding_prep_0 + 92
    5   Foundation                          0x00000001871b2d98 <redacted> + 212
    6   Foundation                          0x00000001871b2c88 <redacted> + 200
    7   Foundation                          0x00000001871b3014 <redacted> + 52
    8   ?????????                           0x00000001000bf900 ????????? + 358656
    9   ?????????                           0x00000001000bf748 ????????? + 358216
    10  libdispatch.dylib                   0x00000001980b9994 <redacted> + 24
    11  libdispatch.dylib                   0x00000001980b9954 <redacted> + 16
    12  libdispatch.dylib                   0x00000001980be20c _dispatch_main_queue_callback_4CF + 1608
    13  CoreFoundation                      0x00000001861fb7f8 <redacted> + 12
    14  CoreFoundation                      0x00000001861f98a0 <redacted> + 1492
    15  CoreFoundation                      0x00000001861252d4 CFRunLoopRunSpecific + 396
    16  GraphicsServices                    0x000000018f93b6fc GSEventRunModal + 168
    17  UIKit                               0x000000018aceafac UIApplicationMain + 1488
    18  ?????????                           0x000000010007528c ????????? + 53900
    19  libdyld.dylib                       0x00000001980e6a08 <redacted> + 4
)

dSYM UUID: 916F22F5-F3B1-3709-BB7E-5B11267B5D1F
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: ???
Base Address: 0x0000000100068000
  • 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
  • 30

第一部分,看看UUID

916F22F5-F3B1-3709-BB7E-5B11267B5D1F
  • 1

使用命令查看dsym文件的uuid

huangwenchendeMacBook-Pro:Dsym调试 huangwenchen$ dwarfdump --uuid uau1.3.0.app.dSYM/
UUID: EC087835-FA55-36F2-B4D9-430BF6C2BA69 (armv7) uau1.3.0.app.dSYM/Contents/Resources/DWARF/Name
UUID: 916F22F5-F3B1-3709-BB7E-5B11267B5D1F (arm64) uau1.3.0.app.dSYM/Contents/Resources/DWARF/Name
  • 1
  • 2
  • 3

对照可以看到,uuid是一致的,那么这个dsym文件可用


找到?????部分

之所以要找到这部分,是因为crash log中call tree没办法识别的部分,往往就是自己代码的部分。

我的Crash Log中,分别是这三行

    8   ?????????                           0x00000001000bf900 ????????? + 358656
    9   ?????????                           0x00000001000bf748 ????????? + 358216
    18  ?????????                           0x000000010007528c ????????? + 53900
  • 1
  • 2
  • 3
  • 4

然后,用命令定位到代码crash处

huangwenchendeMacBook-Pro:Dsym调试 huangwenchen$ dwarfdump --lookup 0x000000010007528c  -arch arm64 uau1.3.0.app.dSYM
  • 1
  • 2

看到Log

Looking up address: 0x000000010007528c in .debug_info... found!

0x000ada5c: Compile Unit: length = 0x00001139  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x000aeb99)

0x000ada67: TAG_compile_unit [99] *
             AT_producer( "Apple LLVM version 7.0.0 (clang-700.1.76)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp/UAUOneStampMarketInfo.m" )
             AT_stmt_list( 0x0003647f )
             AT_comp_dir( "/Users/huangwenchen/Desktop/nativeios/StampApp" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x0000000100074674 )
             AT_high_pc( 0x000000010007597c )

0x000adf2d:     TAG_subprogram [106] *
                 AT_low_pc( 0x0000000100075278 )
                 AT_high_pc( 0x0000000100075298 )
                 AT_frame_base( reg31 )
                 AT_object_pointer( {0x000adf50} )
                 AT_name( "-[UAUOneStampMarketInfo insitutionName]" )
                 AT_decl_file( "/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp/UAUOneStampMarketInfo.m" )
                 AT_decl_line( 122 )
                 AT_prototyped( 0x01 )
                 AT_type( {0x000adcd1} ( NSString* ) )
                 AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp'
Line table file: 'UAUOneStampMarketInfo.m' line 123, column 12 with start address 0x0000000100075288

Looking up address: 0x000000010007528c 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
  • 30

其中,这两行

  AT_name( "-[UAUOneStampMarketInfo insitutionName]" )
                 AT_decl_file( "/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp/UAUOneStampMarketInfo.m" )
  • 1
  • 2

基本上定定位到了UAUOneStampMarketInfo.m,中的insitutionName方法。 
再结合

[NSNull length]: 
这个错误,也就定位到了是因为后台返回了NSNull对象,自己没做检查


这个命令还有很多用法

hangwenchendeMacBook-Pro:Dsym调试 huangwenchen$ dwarfdump --help

NAME
    dwarfdump -- dump DWARF debug information.

SYNOPSIS
    dwarfdump [options] file1 file2 ...

DESCRIPTION
    For each operand that names a mach-o or 32 bit ELF file, dwarfdump
    disassembles the DWARF data found within the file. Only the .debug_info
    section is disassembled unless one of the --debug-XXXX or --all options
    are specified.

    The following options are available:

    -a, --all
        Dump disassembly of all DWARF sections -- by default only the
        .debug_info section is disassembled, or individual sections can be
        specified by using the --debug-XXXX options.

    --arch=ARCH
        Dump DWARF debug information for the specified CPU architecture.
        Architectures may be specified by name or by number.  This option
        can be specified multiple times, once for each desired
        architecture. All architectures will be disassembled by default.

    -c, --show-children
        Show a DIE's children when using the --debug-info=OFFSET, --find,
        and --name options.

    --eh-frame[=SECTION]
        Dump exception handling frame information from the optional SECTION
        parameter. The __eh_frame section will be dumped by default.

    -e, --english
        Print dwarf tags and attributes in a more readable format instead
        of using the DWARF TAG_ and AT_ definitions.

    --file-stats[=size]
        Show file composition statistics for any input files. Each file's
        contents are analyzed and broken down into byte counts for the
        following categories: symbol table, string table, text and code,
        DWARF debug information, STABS debug information, and other. When
        multiple files are specified, byte count totals for each category
        will be displayed at the end of the table.  Specify the optional
        'size' argument to show all byte count results using unit suffixes:
        Byte, Kilobyte, Megabyte, Gigabyte, Terabyte and Petabyte. This
        option can be useful in tracking the size and makeup of mach-o
        binary files, and also allows easy comparison between DWARF and
        STABS built binaries and related object files.

    -f PATTERN, --find=PATTERN
        Search for the exact text PATTERN in the .debug_pubnames section
        and print the matching debug information entries. Use the --regex
        option to have PATTERN become a regular expression for more
        flexible pattern matching.

        When there is no .debug_pubnames section or the name of the DIE you
        are looking for is not found in the .debug_pubnames section, try
        using the slower but more complete --name option.

    -F, --show-form
        Show DWARF form types after the DWARF attribute types.

    -h, -?, --help
        Show help and usage for this command.

    -i, --ignore-case
        Ignore case distinctions in when finding by name using strings or
        regular expressions.

    -n PATTERN, --name=PATTERN
        Find and print all DIE entries whose name (DW_AT_name attribute)
        matches the exact text in PATTERN. Use the --regex option to
        have PATTERN become a regular expression for more flexible pattern
        matching.

    --lookup=ADDRESS
        Lookup ADDRESS in the debug information and print out any available
        file, function, block and line table details.

    -o PATH, --out-file=PATH
        Redirect output to a file specified by PATH.

    -p, --show-parents
        Show a DIE's parents when using the --debug-info=OFFSET, --find,
        and --name options.

    -r N, --recurse-depth=N
        Only recurse to a child depth of N when displaying the DWARF
        information.

    -u, --uuid
        Show the UUID for each architecture.

    -x, --regex
        Treat any PATTERN strings as regular expressions when searching
        instead of just as an exact string match.

    -v, --verbose
        Display verbose information when dumping. This can help to debug
        DWARF issues.

    --verify
        Verify the structure of the DWARF information by verifying the
        compile unit chains, die relationships graph, and address ranges.

    --version
        Display the current version and build date of the dwarfdump binary.

    --debug-abbrev
    --debug-aranges
    --debug-frame[=OFFSET]
    --debug-info[=OFFSET]
    --debug-inlined
    --debug-line[=OFFSET]
    --debug-macinfo[=OFFSET]
    --debug-pubnames[=PATTERN]
    --debug-pubtypes[=PATTERN]
    --debug-str
    --apple-names[=PATTERN]
    --apple-types[=PATTERN]
    --apple-exttypes[=PATTERN]
    --apple-namespaces[=PATTERN]
    --apple-objc[=PATTERN]
        Dump the specified DWARF section by name. Only the .debug_info
        section is disassembled by default. Some entries support adding a
        '=OFFSET' as a way to provide an optional offset of the exact entry
        to dump within the respective section. When an OFFSET is provided,
        only the entry at that offset will be dumped, else the entire
        section will be dumped. Some options support an optional '=PATTERN'
        parameter that will search the section for an entry with a matching
        name. Children of items at OFFSETs can be dumped by also using the
        --show-children option where applicable.
iOS 崩溃日志 收集与发送服务器 iOS开发中我们会遇到程序抛出异常退出的情况,如果是在调试的过程中,异常的信息是一目了然,我们可以很快的定位异常的位置并解决问题。那么当应用已经打包,iPhone设备通过ipa的包安装应用后,在使用过程发现crash,那么如何获取crash日志呢?对于保密性要求不高的程序来说,也可以选择各种一条龙Crash统计产品,如 Crashlytics,Hockeyapp ,友盟,Bugly 等等,不过IOS 阅读详情

相关推荐

iOS崩溃总结

一、捕获iOS Crash 1、设置异常断点并运行 设置异常断点.png 说明:设置Xcode异常断点后运行程序,发生Crash时,断点会定位到出错的代码行,但仅适用于开发阶段。线上APP的Crash还需要通过收集Crash机制来捕获Crash并记录在日志中。 2、Mach异常 和 Unix信号

YCM1101743158的博客 2579

RunLoop 四: RunLoop源码学习

一、前言 因为RunLoop的源码涉及到C语言,所以比较抽象。 在苹果网站上下载 RunLoop 的源码,地址为:https://opensource.apple.com/tarballs/CF/ 找到 CFRunLoop.c 文件,进行学习。 需要找到RunLoop 的入口文件,也就是上个笔记上写的 ‘通知Observers:进入Loop’ 这句话。 二、如何找到 RunLoop 的入口 ...

M316625387的博客 610

iOS崩溃日志分析工具dSYM.zip

dSYM文件分析工具、用于崩溃日志分析、~/资源库/Developer/Xcode/Archives路径下 找到对应的dSYM文件,然后根据崩溃平台的日志信息、根据工具、输入后得出崩溃结果。系统10.15可用、版本1.0.3

使用工具分析iOS奔溃日志

写在前言 基本上我们每个app发布之后都要拿到线上的崩溃日志来收集起来,线下来根据崩溃日志来进行修改代码,或者直接热更新修复。 最近我们公司在实施这个的时候,碰到了一个问题,那就是我们抓取的崩溃日志有些具体定位不到哪个文件,哪行。然后经过在网上的一番搜索,找出了方法,来分享给大家。 一个普通的崩溃日志: -[UITableViewCellScrollView selectedB

老谭编程 2095

Python介绍与安装

Python介绍与安装

acegi13579的专栏 3218

软件项目质量管理

识别项目中涉及质量管理的不同角色,如项目经理、质量经理、测试人员等,明确每个角色的职责和任务,包括负责哪些质量管理活动和决策。1、编制软件项目的质量管理计划,包括确定项目的质量标准和要求,以及制定质量控制和质量保证策略等。2、编制软件项目的质量管理计划,包括确定项目的质量标准和要求,以及制定质量控制和质量保证策略等。测试用例表是质量控制过程中的关键工具,确保所有功能和场景都被验证,减少项目中的缺陷。1、理解项目质量管理的基本过程,包括质量计划、质量保证、质量控制和质量改进;明确质量管理活动中的角色和职责。

weixin_51996255的博客 1258

[原创](现代Delphi 12指南):[macOS 64bit App开发]: [1]如何使用原生NSAlert消息框 (runModal模式)

在使用现代 Delphi 12开发macOS 64bit应用时, 经常需要向用户展示信息、确认对话或警告提示. 虽然FireMonkey自带的对话框在跨平台场景下已能满足大部分需求, 但当追求与系统一致的原生体验时, 借助macOS原生的Cocoa框架就显得尤为重要. NSAlert是Cocoa中用于显示模态对话框的类, 其外观和行为都与系统其他应用保持一致. 借助Delphi提供的 Objective-C桥接能力, 可以直接创建并调用NSAlert, 实现与macOS原生消息框无缝集成. 

其实我不是代码教父,我只是猪头三 1419

保姆级教程:用Docker快速部署mpromonet/webrtc-streamer实现WebRTC直播(附常见问题解决)

本文提供了一份详细的Docker部署mpromonet/webrtc-streamer的实战指南,帮助用户快速搭建WebRTC直播服务。内容涵盖从环境准备、基础部署到进阶配置与性能调优的全过程,并针对容器网络、视频流配置、跨网访问等常见问题提供了解决方案,旨在实现低延迟的流媒体传输。

dell8的博客 177

iOS崩溃调试的使用和技巧总结

在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。 现在网上有很多关于解析崩溃信息的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天写一篇博客总结一下我对崩溃调试的使用和技巧,如果有哪些错误或遗漏,还请指点,谢谢! 获取崩溃信息 在iOS中获取崩

fhh_love的专栏 569

零基础入门Simulink——基于Simulink的MIMO-OFDM系统仿真建模示例

MIMO概述MIMO技术利用多个天线进行信号发送和接收,通过空间复用来提高数据传输速率,或通过空间分集来增强信号的可靠性。OFDM概述OFDM是一种将高速率数据流分成多个低速数据流并行传输的技术,每个子载波都采用调制方式(如BPSK、QPSK),并通过IFFT/FFT变换实现串并转换。MIMO-OFDM优势结合了MIMO的空间分集增益与OFDM对抗多径效应的能力,适用于宽带无线通信系统。提供了更高的数据速率和更好的频谱效率,是现代无线通信标准(如4G LTE、5G NR等)的核心技术之一。

amy_mhd的博客 888

msfvenom制作windows/linux/android/ios木马

msfvenom选项如下 -p, --payload<payload> 指定 payload(攻击荷载)。如果使用自定义payload,请使用'-'或者stdin指定。 -l, --list [module_typel列出指定模块的所有可用资源。模块类型包括:payloads, encoders, nops, all -n, --nopsled <length>为payload预先指定一个NOP滑动长度。 -f, --format <format>指定输出格式(使

Cwillchris的博客 2732

【iOS】崩溃收集和解析

背景 在日常开发中,app难免会发生崩溃。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。 获取崩溃信息方式 在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟、云测、百度等第三方分析工具,或者自己收集崩溃信息并上传公司服务器。 下面列举一些我们常用的崩溃分析方式: 使用友盟、云测、百度等第三方崩溃统计工具。 自己实现应用内崩溃收集,并上传服务器。 Xcode-Devices中直接查看某个设备的崩溃信息。 使用苹果提供的Crash崩

BestpayTech的博客 2089

《低功耗方法学》翻译——第一章:介绍

第一章:介绍

记录所学,分享知识,结识挚友 2067

iOS崩溃调试

在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。 现在网上有很多关于解析崩溃信息的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天写一篇博客总结一下我对崩溃调试的使用和技巧,如果有哪些错误或遗漏,还请指点,谢谢! 获取崩溃信息 在iOS中获

TernenceWei的博客 709

数据分析案例-2024年裁员数据集可视化分析

本实验数据集来源于Kaggle,原始数据集为2020-2024年裁员数据,共有3577条,12个变量,该数据集提供了不同公司的裁员信息。它包括以下几栏:Company:裁员发生的公司名称。Location_HQ:公司总部位置。Industry:公司所属的行业或部门。Laid_Off_Count:公司解雇的员工数量。Percentage:公司员工被解雇的百分比。Date:裁员发生的日期。Source:信息来源网址。Funds_Raised:公司募集资金的信息。

m0_64336780的博客 1万+

① Django手把手从零开发个人博客-前言

手把手教你从零开始玩转手把手教你从零开始玩转Django,全面学习并了解django的运行机制、开发全流程及线上部署。Django,全面学习并了解django的运行机制、开发全流程及线上部署。 专栏介绍 本套教程遵循Django的设计思想,开门见山,快速切入主题,拒绝拖沓,在实战中学习每一个知识点,提高学习的趣味性以及个人成就感,并且能快速将所学运用到实际项目中。 将从零手把手带着你一步步完成博客的每一个功能,通过实现博客文章列表页、文章详情页、作者页面等功能来学习和了解django的视图查询模块相关知.

轻编程的博客 513

iOS 崩溃调试

在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。 现在网上有很多关于解析崩溃信息的博客,但是大多质量参差不齐,或者有些细节没有注意到。如果有哪些错误或遗漏,还请指点,谢谢! 获取崩溃信息 在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟、百

疯狐狸的博客 809

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

iOS中崩溃调试的使用和技巧总结 韩俊强的博客

在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。 现在网上有很多关于解析崩溃信息的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天写一篇博客总结一下我对崩溃调试的使用和技巧,如果有哪些错误或遗漏,还请指点,谢谢!

韩俊强的博客 2620

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

Firebase崩溃根因定位:深入解析iOS应用崩溃分析与符号化技术

在iOS应用开发中,崩溃(Crash)是最令人头疼的问题之一。传统的崩溃日志往往只提供十六进制地址信息,缺乏具体的函数名、文件名和行号,让开发者难以快速定位问题根源。Firebase Crashlytics通过先进的符号化(Symbolication)技术,将晦涩的内存地址转换为可读的代码位置,极大提升了崩溃分析的效率。 ## Crashlytics核心架构解析 ### 崩溃数据收集机制 F...

gitblog_00976的博客 1005

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

MacSymbolicator:iOS崩溃调试的终极符号化工具指南 [特殊字符]

对于iOS和macOS开发者来说,崩溃日志分析常常令人头疼——那些难以理解的内存地址和十六进制代码让人望而却步。MacSymbolicator作为一款专业的**符号化工具**,能够将混乱的崩溃报告转换为可读的代码位置信息,成为开发者的**调试助手**利器。无论是处理用户反馈的崩溃问题,还是在开发阶段进行错误定位,这款工具都能显著提升工作效率。 ## 为什么你需要崩溃报告符号化工具?🔍 在移动

gitblog_00841的博客 847

iOS 崩溃调试的使用和技巧总结

在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。 现在网上有很多关于解析崩溃信息的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天写一篇博客总结一下我对崩溃调试的使用和技巧,如果有哪些错误或遗漏,还请指点,谢谢!获取崩溃信息在iOS中获取崩溃信息的方式有很多,比

zhouwenchun 1994

ios崩溃日志收集_iOS分析崩溃日志

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

weixin_28955629的博客 392
上一篇: [译]关于iOS和OS X废弃的API你需要知道的一切
下一篇: iOS编译过程的原理和应用
lin_transform
博客等级 码龄9年 3粉丝 22原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值