动态库

简介 strace常用来跟踪进程执行时的系统调用和所接收的信号。 在Linux世界，进程不能直接访问硬件设备，当进程需要访问硬件设备(比如读取磁盘文件，接收网络数据等等)时，必须由用户态模式切换至内核态模式，通 过系统调用访问硬件设备。strace可以跟踪到一个进程产生的系统调用,包括参数，返回值，执行消耗的时间。 输出参数含义 root@ubuntu:/usr# strace cat /dev/null execve("/bin/cat", ["cat", "/dev/null"], [/* 22 vars */]) = 0brk(0) = 0xab1000access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f29379a7000access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)...brk(0) = 0xab1000brk(0xad2000) = 0xad2000fstat(1, {st_mode=S_IFCHR|0620, st

linux调用库的方式有三种: 1.静态链接库 2.动态链接库（隐式） 3.动态加载库（显式） 其中1,2都是在编程时直接调用,在链接时加参数-l进行链接 第三种需要在编程时使用dlopen等函数来获取库里面函数的定义,然后进行调 linux readlink dlopen 加载动态库 dlclose 卸载的动态库 dlsym 从动态库获取函数地址 windows GetModuleFileNameA LoadLibrary 加载动态库 GetProcAddress 获取函数地址 FreeLibrary 卸载动态库 extern "C" __declspec(dllexport) 将一个函数声名为导出函数，就是说这个函数要被其他程序调用，即作为DLL的一个对外函数接口 extern "C" __declspec(dllimport) 将dll中的函数声明导入，就是说外部程序要调用这个函数 __cdecl约定函数参数按照从右到左的顺序入栈，并且由调用函数者把参数弹出栈以清理堆栈。因此，实现可变参数的函数只能使用该调用约定 __stdcal约定函数参数按照从右到左的顺序入栈，被调用的函数在返回前清理传送参数的栈，函数参数个数固定。由于函数体本身知道传进来的参数个数，因此被调用的函数可以在返回前用一条ret n指令直接清理传递参数的堆栈 _

之前一篇《 记一个链接库导出函数被覆盖的问题 》中，描述了这样一个问题：动态库若想使用自己的符号，不受可执行程序（或其他动态库的影响），可以使用-Wl,-Bsymbolic链接参数或version_script来让动态库的符号自我解决，而不必通过全局符号表来动态解决。 之前的文章也提到，使用-Wl,-Bsymbolic这样的方法是存在隐患的。最近又遇到这样的例子，动态库使用了私有的符号导致dynamic_cast、throw可能达不到程序预想的效果。 另外，除了显式的使用-Wl,-Bsymbolic、version_script这样的方法之外，通过dlopen打开的动态库也可能会使用到自己私有的符号。这种情况的发生，有如下条件： 1、可执行程序在链接的时候没有使用-Wl,-E选项。则链接器在生成可执行程序的时候默认不会将其符号导出到全局符号表； 2、在链接生成可执行程序的目标文件中没有列举将要dlopen的动态库（通常都是这样，静态链接的时候并不知道运行时需要dlopen什么样的动态库）。否则的话，就算没有-Wl,-E选项，可执行程序也会将目标文件中的动态库所需要的符号导出到全局符号表； 满足这两个条件的话，动态库在通过dlopen加载的时候，可能就看不到可执行程序中的相同符号，而使用自己私有的符号。 例： [class.h] class AAA { public: virtual

之前一篇《 记一个链接库导出函数被覆盖的问题 》中，描述了这样一个问题：动态库若想使用自己的符号，不受可执行程序（或其他动态库的影响），可以使用-Wl,-Bsymbolic链接参数或version_script来让动态库的符号自我解决，而不必通过全局符号表来动态解决。 之前的文章也提到，使用-Wl,-Bsymbolic这样的方法是存在隐患的。最近又遇到这样的例子，动态库使用了私有的符号导致dynamic_cast、throw可能达不到程序预想的效果。 另外，除了显式的使用-Wl,-Bsymbolic、version_script这样的方法之外，通过dlopen打开的动态库也可能会使用到自己私有的符号。这种情况的发生，有如下条件： 1、可执行程序在链接的时候没有使用-Wl,-E选项。则链接器在生成可执行程序的时候默认不会将其符号导出到全局符号表； 2、在链接生成可执行程序的目标文件中没有列举将要dlopen的动态库（通常都是这样，静态链接的时候并不知道运行时需要dlopen什么样的动态库）。否则的话，就算没有-Wl,-E选项，可执行程序也会将目标文件中的动态库所需要的符号导出到全局符号表； 满足这两个条件的话，动态库在通过dlopen加载的时候，可能就看不到可执行程序中的相同符号，而使用自己私有的符号。 例： [class.h] class AAA { public: virtual

完整的Demo下载 做了以下几个实验 验证 Swift 和 OC 的项目可以使用任意语言开发的动态库 1 、创建了一个 Swift 语言的动态库 2 、创建了一个 OC 语言的动态库 3 、创建了一个 SwiftApp 项目，在项目中同时使用 Swift 和 OC 的动态库 4 、创建了一个 OCApp 项目，在项目中同时使用 Swift 和 OC 的动态库 验证同一项目中 (OC/Swift) 同时使用 Swift 类和 OC 类 1 、在 Swift 项目中创建 OC 的类并正确使用 2 、在 OC 的项目中创建 Swift 的类并正确使用 验证同一动态库中 (OC/Swift) 同时使用 Swift 类和 OC 类 1 、在 Swift 动态库中同时使用 Swift 类和 OC 类，并在 (OC/Swift) 项目中正确调用 2 、在 OC 动态库中同时使用 Swift 类和 OC 类，并在 (OC/Swift) 项目中正确调用 上述实验，在 iOS7-iOS9 设备上调试通过 下面开始分享实验的详细过程以及遇到的坑。 1、首先创建一个工作空间 2、创建一个Swift动态库 3、 添加一个 Swift测试文件。 这里需要注意public关键字的使用。动态库中的文件想要对外可见，OC和Swift的做法有区别。OC中把类的.h文件拖到public区域，就可以了。Swift没有

iOS签名类型有Development、AD-Hoc、In-House与App Store，而打包过程中又涉及到各种证书、Provision Profile、entitlements、CertificateSigningRequest、p12、AppID......各种概念一大堆，本文将从打包签名的原理说起，并梳理完全签名的整体流程，最后讲解重签名的实现以及签名机制中有哪些需要注意防护的要点。 为了保证App的分发平台是可控的，以及保证所有安装到iOS设备上的App都是经过苹果官方允许的，苹果建立了iOS签名打包机制。要了解iOS签名机制的实现，我们首先从签名机制的原理说起。 1. 签名原理 1.1 不对称加密 网络数据的传输可以使用对称加密以及不对称加密的方式进行安全防护，对称加密是指数据发送者（A）和接收者（B）双方进行加解密的密钥是一致的，但这样会增加密钥自身分发的不安全性：比如要如何保证密钥在传递过程中不被泄露。 而不对称加密则由A、B持有一对公私钥进行加解密，公私钥钥匙是成对出现的。对于一个私钥，有且只有一个与其对应的公钥，私钥保密、公钥公开，但是不能通过公钥推导出私钥，使用私钥加密的文件可用公钥解密，反过来公钥加密的文件也只能用私钥进行解密。加密过程如下： 发送方（A）首先生成一对公私钥钥匙对，私钥自己保管，公钥则任意分发出去

一、App启动优化 1.App的启动可以分为2种 冷启动(Cold Launch):从零开始启动APP 热启动(Warm Launch):APP已经在内存中，在后台存活着，再次点击图标启动APP APP启动时间的优化，主要是针对冷启动进行优化 通过添加环境变量可以打印出APP的启动时间分析(Edit scheme -> Run -> Arguments) DYLD_PRINT_STATISTICS设置为 1 如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS_DETAILS设置为1 2.App 冷启动分为四大阶段 dyld 加载可执行文件，动态库(递归加载) runtime main() 函数执行后 首屏渲染完成后 一个开发者，有一个学习的氛围跟一个交流圈子特别重要，这是一个我的iOS交流群：1012951431， 分享BAT,阿里面试题、面试经验，讨论技术， 大家一起交流学习成长！希望帮助开发者少走弯路。 2.1关于dyld 在Mac 、iOS中，是使用了/usr/lib/dyld程序来加载动态库 dynamic link editor，动态链接编辑器 dynamic loader，动态加载器 dyld 的源码 https://opensource.apple.com/tarballs/dyld/ initializeMainExecutable 方法开始的

1、Dll类库 一般是包含函数（方法），很少包含控件，因为如果你包含控件的话，在使用时，还不如使用自定义控件使用的方便 可参考的简单使用操作连接 https://blog.csdn.net/liuqinghui1990/article/details/76943922?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task 1.概述 动态链接库(Dynamic Linked Library)：将写好的函数存在库中，以供其他程序开发调用，调用方式为“动态的”。 Windows为应用程序提供了丰富的函数调用，这些函数调用都包含在动态链接库中。其中有3个最重要的DLL，Kernel32.dll，它包含用于管理内存、进程和线程的各个函数； User32.dll，它包含用于执行用户界面任务(如窗口的创建和消息的传送)的各个函数；GDI32.dll，它包含用于画图和显示文本的各个函数。 静态库(Static Library)：函数和数据被编译进一个二进制文件(通常扩展名为.LIB)。在使用静态库的情况下，在编译链接可执行文件时，链接器从库中复制这些函数和数据并把它们和应用程序的其它模块 组合起来创建最终的可执行文件(.EXE文件)。 2.动态库与静态库的区别

从链接中 https://www.speex.org/downloads/ 下载Speex 1.2.0、SpeexDSP 1.2rc3。 编译和安装 下载以后解压，然后点击INSTALL，根据其中的命令进行安装，具体的安装方式也可以看解压后 doc目录中manual.pdf 的第3章。 % ./configure [--prefix=<install-path>] %make %make install 其设置支持是通过Speex配置脚本的，这些命令选项跟在 ./configure设置 ： -prefix=<path> 指定Speex安装其本路径（如 /usr） -enable-shared/-disable-shared 是否编译共享库 -enable-static/-disable-static 是否编译静态库 -disable-wideband 取消Speex的宽带部分（典型的节省空间） -enable-valgrind 为调试目的启用额外valgrind的命中率 -enable-sse 启用SSE指令（只在 x86/浮点） -enable-fixed-point 编译Speex为无浮点单位（FPU）处理器 -enable-arm4-asm 启用汇编指定为ARMv4架构（只在gcc ） -enable-arm5e-asm 启用汇编指定为ARMv5E架构 （ 只在gcc ）

gcc生成静态库和动态库 一、库文件简介 简单地说，库（Library）就是一组已经写好了的函数和变量、经过编译代 码，是为了能够提高开发效率和运行效率而设计的。库分为静态库（Static Library）和共享库（Shared library）两类。 静态库文件的扩展名是.a，共享库文件的扩展名是.so （在CYGWIN环境下，分别叫做.o和.dll）。共享库现在常常被叫做 动态库，是由于很多人借用了MS Windows的DLL（Dynamic Linked Library）这个词。 （1）静态库 静态是指每个用到该库的应用程序都拥有一份自己的库拷贝；应用程序运行的时候，即使将库删除也没有问题，因为应用程序自己已经有了自己的拷贝。 （2） 共享库 一个共享库有可能被多个所有应用程序共享。因此，对每个应用程序来说，即使不再使用某个共享库，也不应将其删除。此外，应用程序需要正确的环境变量设置 （LD_LIBRARY_PATH），从而找到共享库所在的位置，否则，应用程序运行时会报告找不到这个库。 二、关于使用库的问题 如果库是已经编译好的，那么如何在开发、运行应用程序时使用呢？头文件和库文件所在的路径，必须通过适当的方式通知给编译器、链接器和相关的应用程序。 对于静态库来说，主要涉及开发工具，如gcc。例如，用gcc编译、链接时，需要通过适当的路径找到头文件和静态库文件；