debug dsym ios_ios debug excutble dsym - CSDN
  • Build Setting Debug Information Format -> DWARF with dSYM File Generate Debug Symbols -> YES 在 Products 文件夹内 Show In Finder xxx.app

    Build Setting

    • Debug Information Format -> DWARF with dSYM File
    • Generate Debug Symbols -> YES

    Products 文件夹内 Show In Finder xxx.app


    打包脚本

    https://github.com/xjh093/iOSAutoPacking

    展开全文
  • iOSdebug包时生成DSYM

    2016-02-23 17:57:59
    debug 项改成DWARF with dSYM File即可

    把debug 项改成DWARF with dSYM File即可

    展开全文
  • iOS通过dSYM文件分析crash日志 平常在开发的过程中,遇到到了Crash可以很容易的通过Xcode去定位Crash的位置,但是当我们的App发布以后,遇到闪退就不可以通过Xcode去调试了。当然现在也有很多产品可以在线分析,例如...

    iOS通过dSYM文件分析crash日志
    平常在开发的过程中,遇到到了Crash可以很容易的通过Xcode去定位Crash的位置,但是当我们的App发布以后,遇到闪退就不可以通过Xcode去调试了。当然现在也有很多产品可以在线分析,例如腾讯的bugly与友盟的错误分析。这些分析工具的最基本的地方还是通过dSYM去分析Crash日志,符号化Crash日志。

    准备工作
    分析崩溃日志需要三个东西:1、crash文件 2、symbolicatecrash文件 3、dYSM文件。我们拿到这个三个文件后,一般新建一个文件夹,把这三个文件放一起。至于crash文件和dYSM文件在哪里找,出门左转,度娘谢谢。

    1、如何查找symbolicatecrash文件?

    打开终端,输入 find /Applications/Xcode.app -name symbolicatecrash -type f,我用的是Xcode9,返回的结果如下:

    如果是iPhone设备,选择红框中的路径,这样就可以找到symbolicatecrash文件

    2、检测dYSM文件和crash文件是否对应
    从终端进入到刚刚创建的crash文件中,输入dwarfdump --uuid xxx.app.dSYM(xxx是工程名)。如果输出的uuid和crash文件中的一致,则可以解析出正确的crash文件。crash文件中的uuid位于Binary Images中的第一行尖括号内。

    3、解析crash文件
    在终端中输入./symbolicatecrash crash.crash xxx.app.dSYM >crashLog.text,(xxx是工程名)。这样就可以在你的文件中看到解析后的崩溃文件。

    注意,一般情况下,第一次使用symbolicatecrash会产生一个error,如下的错误信息
    Error: "DEVELOPER_DIR" is not defined at /usr/local/bin/symbolicatecrash line 53.

    解决办法是输入export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer
     

    symbolicatecrash位置:

    /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

     

    找到.app文件和.app.dSYM文件:
    在桌面创建一个crash文件夹,然后Xcode->Window->Organizer找到Archives找到App->右击Show in 
    Finder

    复制.app和.app.dSYM到crash夹文件:右击.xcarchive文件->显示包内容 
    在dSYMs文件夹中找到.app.dSYM 
    在Products->Applications文件夹中找到*.app

    xcode中直接运行的:

    /Users/用户名/Library/Developer/Xcode/DerivedData/项目名/Build/Products/Debug-iphonesimulator/项目名.dSYM

    如果打包的此文件在/Users/用户名/Library/Developer/Xcode/Archive下面

    crash文件获取:

    xcode->window->device and simulator->view device logs中找到crash log文件,下载即可以得到。

     

     

    展开全文
  • iOS 减少编译时间

    2020-03-31 11:34:19
    iOS 减少编译时间 编译操作 每次在Xcode中写完代码,我们可能都需要按CMD + B 编译一下,或者直接按CMD + R运行,但是还是有需要先编译再运行。 显示编译时间设置 显示总编译时间 打开终端,执行命令defaults write ...

    iOS 减少编译时间

    编译操作

    每次在Xcode中写完代码,我们可能都需要按CMD + B 编译一下,或者直接按CMD + R运行,但是还是有需要先编译再运行。

    显示编译时间设置

    显示总编译时间

    打开终端,执行命令defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES重启Xcode即可查看每次编译总时间

    在这里插入图片描述

    显示每个函数编译时间

    对于Swift项目来说,在项目的Build Setting中,在Other Swift Flags中添加-Xfrontend -debug-time-function-bodies就可以查看编译过程每部分耗时

    你甚至都可以设置代码编译限时警告,如果超过时间,编译器就会提示警告⚠️

    -Xfrontend -warn-long-function-bodies=100 (100 means 100ms here, you should experiment with this value depending on your computer speed and project)
    
    -Xfrontend -warn-long-expression-type-checking=100
    

    Tips: 建议只给Debug添加上面flag

    在这里插入图片描述

    项目设置优化

    1. Debug Information Format改为DWARF

    可以设置Debug模式可以不生成符号表dSYM,只在release生成。一般默认就是这样的,但是还是应该检查下和看下pod和子项目有没有设置。

    选择Targets应用 , Build Setiing搜索 Debug Infomation Format,检查Dubug模式下是否为DWARF

    2. Build Active Architecture Only改为Yes

    是否生成全架构版本,Debug时不需要生成全架构,默认为Yes。但是Release情况下必须为No,否则有些机器不能运行应用。

    3. Header Search Paths 路径设置为non-recursive

    避免设置路径递归引用。当然一般默认值也是non-recursive

    4. 关闭Enable Index-While-Building Functionality

    默认打开,作用是Xcode编译时建立代码索引,影响编译速度。关闭了项目就会在空闲时间生成,避免编译时生成。

    代码习惯

    其他配置

    Podfile配置

    第三方库编译速度顺序:静态库 > 动态库 > 源码

    由于使用Swift的库只能使用动态库,所以配置文件需要添加use_frameworks!,同时我们不应该在桥接文件中导入OC库,这样相当于引入源码,会使编译速度降低。正确做法是像使用Swift库一样在使用的文件import

    Swift项目编译优化

    Swift编译优化,主要在于平时编码习惯上,原则就是确定类型,避免偷懒给编译器确定。

    避免使用类型推导

    众所周知,Swift有个美滋滋的特性,就是可以进行类型推导,根据情况确定值类型,但是Swift同时又是类型安全的,需要明确类型,那这个过程谁来做了,自然就是编译期间编译器在操作。

    var value1: Int = 10  // 编译时间约 0.10ms
    var value2 = 10       // 编译时间约 0.14ms
    

    虽然只是毫秒级差别,但是集少成多,随着项目变大,编译总时间差别越大。

    所以建议,写代码时应该明确类型,尽量减少类型推导。

    推荐

    var stringValue: String = "This is String"
    var dic: [String: String] = ["key1": "value1", "key2": "value2"]
    var arr: [String] = ["1", "2", "3"]
    

    不推荐

    var stringValue = "This is String"
    var dic = ["key1": "value1", "key2": "value2"]
    var arr = ["1", "2", "3"]
    

    字符串append 替换 +

    let str1: String = "string1"
    let str2: String = "string2"
    // 推荐
    let newStr: String = str1.append(str2)
    // 不推荐 会花费更长编译时间
    let newStr = str1 + str2
    

    同理,集合操作也应该减少直接使用 +

    避免使用 ?? 添加可选默认值

    ??操作符,在进行可选值操作非常方便,可以有效避免空指针应用奔溃。但是实际情况是,这个操作符编译是if let 操作好几倍,而且运行时间也多一点,但是毕竟是语法糖,从使用上来说方便许多,相信苹果团队以后也会优化解决这个问题的吧?

     /// 使用 ?? 添加默认值 使用 + 连接 编译57.57ms 运行平均值0.0108ms
        func defaultValueAdd() -> String {
            var s1 = str1 ?? "string1"
            return s1 + (str2 ?? "String2")
        }
        /// 使用 ?? 添加默认值 使用append连接字符串 编译21.48ms 运行平均值0.0090ms
        func defaultValueAppend() -> String {
            var s1 = str1 ?? "String2"
            s1.append(str2 ?? "")
            return s1
        }
        /// 使用 if let 中转方法添加默认值 使用append连接字符串 编译0.56ms + 0.13ms(扩展方法编译) 运行平均值0.0079ms
        func useIfLet() -> String {
            var s1 = String.optional(str1, "string1")
            s1.append(String.optional(str2, "String2"))
            return s1
        }
    

    使用if let 解包

    extension String {
        static func optional(_ optional: String? , _ placeholder: String) -> String{
            guard let value = optional else {
                return placeholder
            }
            return value
        }
    }
    

    在这里插入图片描述

    懒加载实现部分单独定义

    懒加载的实现部分放在单独方法中。

    方法尽量指定参数

    // 推荐
    func method(param1: String, param2: Int) {}
    // 不推荐
    func method(_ param1: String, _ param2: Int) {}
    

    但是Swift 标准库方法中,很多时候省略第一个参数

    Objective-C项目

    原则: 减少无效引用

    优化pch文件

    PCH(Precompile Prefix Header File)文件,也就是预编译头文件,其文件里的内容能被项目中的其他所有源文件访问。通常放一些通用

    的宏和头文件,方便编写代码,提高效率。另外 PCH 文件预编译完成后,后面用到 PCH 文件的源文件编译速度也会加快。缺点是 PCH

    文件和 PCH 引用到的头文件内容一旦发生变化,引用到 PCH 的所有源文件都要重新编译。所以使用时要谨慎

    检查pch文件,删除引用较少的。 pch应该保持尽量少原则, 对应的应用在对应的.m文件中添加(同时应该避免在 .h 中引入)。

    避免在.h文件引入

    可以在.h文件使用前置声明(@class 类;),在.m文件中实际引入(#import “类.h”)。

    .h

    #import <UIKit/UIKit.h>
    //#import "A.h"
    //类的前置声明
    /** 告诉编译器,暂时把这个字符串当做一个类型来使用,以后会定义这个类型的*/
    @class A;
    @interface B : NSObject
    
    @property (nonatomic, strong)A *a;
    @end
    

    .m

    #import "B.h"
    #import "A.h"
    
    @interface B ()
    

    混编项目

    如果是混编项目,在Other Swift Flags中添加-enable-bridging-pch可以减少混编30%编译时间。

    参考

    iOS开发—优化编译时间[外文翻译,有很多指南文章]

    一分钟大幅度降低iOS编译时间

    设置other swift flags – Swift官方建议

    https://zhuanlan.zhihu.com/p/34963792?hmsr=toutiao.io

    优化iOS项目编译时间

    如何将iOS工程打包速度提升十倍以上

    iOS编译与app启动

    如何将iOS项目编译速度提升5倍 CCache
    iOS 微信编译速度优化分享
    为什么Debug Infomation Format 改为DWARF可以提高编译速度

    展开全文
  • ios 打包未生成dsym

    2020-06-28 10:31:02
    ios 打包未生成dsym Project -> Target -> Build Setting -> Build Option -> Debug Information Format 设置为 DWARF with dSYM File Project -> Target -> Build Setting ->Generate Debug ...
  • 在build setting中输入debug,找到Debug Information Format这一项,你会在它下面看到Debug和Release两个子选项,打包属于release,看看release后面是不是显示DWARF,选中这一项,切换到DWARF with dSYM File后重新...
  • 符号表文件.dSYM实际上是从Mach-O文件中抽取调试信息而得到的文件目录,实际用于保存调试信息的文件是DWARF,其出身可以从这篇文章了解。 这个是我T9项目导出的文件路径 /Applications/Xcode.app/Contents/...
  • xcode8 中 dsym 文件位置

    2017-04-05 21:33:11
    xcode8 中 dsym 文件位置是:/Users/用户名/Library/Developer/Xcode/DerivedData/项目名/Build/Products/Debug-iphonesimulator/ 项目名.dSYM如果你没有生成 dsym.可能是没有设置好。 参考: ...
  • 发布程序后,我们会通过crash log进行错误分析,我们需要用到dsym文件。 Xcode Archive 不生成dsym文件的解决方法如下: 选择Project -> Target -> Build Setting 找到 Build Option -> Debug Information ...
  • 原文链接:http://blog.csdn.net/openglnewbee/article/details/38824139 ... 重点是dwarfdump --uuid命令 ...我们在ios开发中会碰到的很多crash问题,如果Debug调试模式的话,我们可以往往很容易的根据
  • 好久没写博客了,真的不是忙没有时间。就是懒!闲话少说,言归正传。事件起因,群里一个朋友说自己的app被拒了,苹果给的被拒原因是AppStore审核指南条例2.1,说是app存在崩溃。还附带上了Crash日志文件。...
  • 摘要:在iOS App开发过程中,开发者会利用Xcode打包生成.xcarchive的包文件,并通过Organizer工具可以管理、导出发布文件。本文作者从本文开始,详细剖析了打包之后的dSYM文件的结构。 CSDN移动将持续为您...
  • dSYM的简单介绍

    2018-04-16 11:15:41
    在XCODE编译项目之后,会在app旁看见一个同名的dSYM文件.(rd称之为 符号文件)他是一个编译的中转文件,简单说就是debug的symbols包含在这个文件中.二、dsym有什么作用?当release的版本 crash...
  • dsym文件分析工具

    2020-07-30 23:32:03
    在XCODE编译项目之后,会在app旁看见一个同名的dSYM文件. 他是一个编译的中转文件,简单说就是debug的symbols包含在这个文件中. 他有什么作用? 当release的版本 crash的时候,会有一个日志文件,包含出错的内存地址, ...
  • iOS开发-dSYM文件

    2020-04-04 10:40:16
    文章目录dSYMxcode的符号化解析每个架构的符号Bitcode相关定位你的dSYMBuild UUID对比恢复隐藏的符号表文件符号化解析操作命令 dSYM 根据 苹果官方文档,当编译器将源代码转为机械码时,会生成调试符号(debug ...
  • iOS App开发过程中,我们会利用Xcode打包,生成.xcarchive的包文件,通过Xcode的Organizer工具可以管理、导出发布文件,相信iOS开发对于这些过程都相当的熟悉,这里就不再赘述。主要想说的是,打包之后的dSYM文件...
  • dSYM文件缺失通常有两种情况**: 情况一:配置错误导致打包时没有生成dSYM文件 针对这种情况,通常是因为Project -> Build Settings下的Debug Information Format的值被设置为DWARF。需修改为DWARF with dSYM ...
1 2 3 4 5 ... 20
收藏数 1,120
精华内容 448
关键字:

debug dsym ios