app转静态库 ios
2019-06-06 16:28:00 weixin_34006965 阅读数 14

以腾讯信鸽推送为例子。
1.关键语法spec.prepare_command
2.新建一个XGPush_Swift.podspec,修改XGPush 原来的podspec内容,最后通过“spec.prepare_command”增加新建.m文件
的命令
3.cocoapod会检测库是否含有.m文件还是仅仅含有静态库来决定是否打包成动态库。

Pod::Spec.new do |spec|
  spec.name           = "XGPush_Swift"
  spec.version          = "3.2.4"
  spec.summary          = "腾讯信鸽(XG Push)"
  spec.homepage         = "http://xg.qq.com"
  spec.authors          = "tencent TEG"
  spec.license          = "MIT"
  spec.platform         = :ios, "6.0"
  spec.frameworks       = "CFNetwork", "SystemConfiguration", "CoreTelephony", "CoreGraphics", "Foundation", "UserNotifications"
  spec.libraries        = "z", "sqlite3"
  spec.source         = { :git => "https://github.com/xingePush/XGPush.git" }
  spec.source_files       = "XGPush/*.h","XGPush/Read.m"
  spec.vendored_libraries   = "XGPush/*.a"
  spec.xcconfig            = { "LIBRARY_SEARCH_PATHS" => "\"$(PODS_ROOT)/XGPush_Swift/**\"" }
  spec.static_framework = true

  spec.prepare_command = <<-EOF
    touch XGPush/Read.m
    cat <<-EOF > XGPush/Read.m
    //framework module QQ_XGPush {
    //  header "XGPush.h"
    //  export *
    //  link "z"
    //  link "sqlite3"
    //}
    \EOF
  EOF
end

转载于:https://www.jianshu.com/p/9764f767989f

2015-09-01 16:04:00 weixin_30268921 阅读数 1

 

一、什么是库?

库是共享程序代码的方式,一般分为静态库和动态库。

静态库:链接时完整地拷贝至可执行文件中,被多次使用就有多份冗余拷贝。

动态库:链接时不复制,程序运行时由系统动态加载到内存,供程序调用,系统只加载一次,多个程序共用,节省内存。

三、iOS里静态库形式?

.a和.framework

四、iOS里动态库形式?

.dylib和.framework

五、framework为什么既是静态库又是动态库?

系统的.framework是动态库,我们自己建立的.framework是静态库。

六、a与.framework有什么区别?

.a是一个纯二进制文件,.framework中除了有二进制文件之外还有资源文件。

.a文件不能直接使用,至少要有.h文件配合,.framework文件可以直接使用。

.a + .h + sourceFile = .framework。

建议用.framework.

七、为什么要使用静态库?

方便共享代码,便于合理使用。

实现iOS程序的模块化。可以把固定的业务模块化成静态库。

和别人分享你的代码库,但不想让别人看到你代码的实现。

开发第三方sdk的需要。

八、制作静态库时的几点注意:

1 注意理解:无论是.a静态库还.framework静态库,我们需要的都是二进制文件+.h+其它资源文件的形式,不同的是,.a本身就是二进制文件,需要我们自己配上.h和其它文件才能使用,而.framework本身已经包含了.h和其它文件,可以直接使用。

2 图片资源的处理:两种静态库,一般都是把图片文件单独的放在一个.bundle文件中,一般.bundle的名字和.a或.framework的名字相同。.bundle文件很好弄,新建一个文件夹,把它改名为.bundle就可以了,右键,显示包内容可以向其中添加图片资源。

3 category是我们实际开发项目中经常用到的,把category打成静态库是没有问题的,但是在用这个静态库的工程中,调用category中的方法时会有找不到该方法的运行时错误(selector not recognized),解决办法是:在使用静态库的工程中配置other linker flags的值为-ObjC。

4 如果一个静态库很复杂,需要暴露的.h比较多的话,就可以在静态库的内部创建一个.h文件(一般这个.h文件的名字和静态库的名字相同),然后把所有需要暴露出来的.h文件都集中放在这个.h文件中,而那些原本需要暴露的.h都不需要再暴露了,只需要把.h暴露出来就可以了。

 
 
 

转载于:https://www.cnblogs.com/code-changeworld/p/4775959.html

2016-08-03 20:32:00 weixin_34132768 阅读数 24

把打包好的.ipa文件的后缀改为.zip并解压。右键.appbundle 选择显示包内容。有些情况下,大一点的文件压缩后反而比小一点的文件压缩后的体积小,而我们真正关心的时候解压后的真实体积,所以一定要解压里面的资源文件,看解压后的size。从APP Store下载的.ipa文件要比自己本地打包的要大,因为APP Store对ipa包又做了加密处理。Xcode的Organizer window的Estimate Size功能能估计本地打包文件从APP Store下载时的大小。根据优化的28定律和常识,首先当然是多媒体资源的体积啦。

图片

压缩图片 不重要的图片可适当采用 8bit PNG图片
1.什么是矢量图 矢量图是由计算机的算法产生的,可以无限放大或缩小,不会有任何损失,通常由矢量软件制作。
2.什么是位图 位图是由一个一个的小色块组成,放大后会看到那些小色块,同一面积内小色块越多,分辨率就越高。
3.矢量图的优缺点 可以无限放大或缩小,不会影响图像素质,文件体积较小,编辑灵活。缺点是表达的色彩层次不清,整体观感效果不如位图
4.位图的优缺点 不能放太大,减少文件分辨率后会影响图片质量,图片战胜空间较大,优点是能很细腻地表达图片的效果,图片表达效果非常好
5.什么情况下用位图,什么情况下用矢量图 一些对图片要求高的用位图,例如照片。其他的尽量用矢量图。例如文字、表格、卡通图片等

  • 去掉无用的图片

  • 用代码绘制简单的纯色图片 用Sketch和PaintCode快速得到绘制代码

  • 如果不需要使用透明,可以用jpeg代替PNG。jpeg减少了些效率但更加小。需权衡性能,大小。

  • 对32位的图片,尽肯能的使用高压缩率,使用PS的“Save For Web”功能,可以有效的减小JPEG和PNG图片的尺寸。 默认情况下,在build时,PNG图像就被pngcrush压缩。

音频

视频

  • 视频也可以使用类似于音频的处理方法,音视频的压缩可以很大程度的压缩,但是要注意压缩的格式,是不是会增加编解码的负担,这要权衡考虑。

Assets

  • 检查bundle中的无用文件,不要打包到app或者静态库中。可以点击文件,在右侧的file inspector里面的target membership中取消勾选;或者在build phase里面的Copy Bundle Resources中去掉。
  • 确定 dead code(代码被定义但从未被调用)被剥离,build setting 里 DEAD_CODE_STRIPPING = YES。 去掉冗余的代码,即使一点冗余代码,编译后体积也是很可观的。

编译设置

  • Optimization Level设置为Fastest, Smallest [-Os]Strip Debug
    Symbols During Copy设置为YES (COPY_PHASE_STRIP = YES)
    这样会减小接近一半的体积,但是在release版本,这些貌似是默认的配置,但是不妨也检查一下。 此外在debug版本最好在完成开发测试后,设置成这种模式,重新测试一遍,因为不同的编译设置可能会掩盖一些bug。

  • 设置IOS_DEPLOYMENT_TARGET 为想要运行系统的最低版本

  • 设置需要的arm 架构,设置 ARCHS = arm64可以消除armv6架构,潜在的减少近一半的容量。
    iOS Devices: ARM,尺寸,像素一览表
    1,如果想自己的app在各个机器都能够最高效率的运行,则需要将Build Active Architecture Only改为NO,Valid architectures选择对应的指令集:armv7 armv7s arm64。这个会为各个指令集编译对应的代码,因此最后的 ipa体积基本翻了3倍,Release版本必须NO。
    2,如果想让app体积保持最小,则现阶段应该选择Valid architectures为armv7,这样Build Active Architecture Only选YES或NO就无所谓了

其他

  • 将应用的中一些数据,如长字符串、表格等移到外部文件中,不要放在代码里面,这样能减小一些体积,因为外部文件的压缩率要比应用中的数据压缩率高。

编译选项

  1. 编译器优化级别
    Build Settings->Optimization Level有几个编译优化选项,release版应该选择Fastest, Smalllest,这个选项会开启那些不增加代码大小的全部优化,并让可执行文件尽可能小。
  2. 去除符号信息
    Strip Linked Product / Deployment Postprocessing / Symbols Hidden by Default 在release版本应该设为yes,可以去除不必要的调试符号。Symbols Hidden by Default会把所有符号都定义成”private extern”,详细信息见官方文档
    这些选项目前都是XCode里release的默认选项,但旧版XCode生成的项目可能不是,可以检查一下。其他优化还可以参考官方文档—CodeFootprint.pdf

第三方库统计

项目里会引入很多第三方静态库,如果能知道这些第三方库在可执行文件里占用的大小,就可以评估是否值得去找替代方案去掉这个第三方库。我们可以从linkmap中统计出这个信息,对此写了个node.js脚本,可以通过linkmap统计每个.o目标文件占用的体积和每个.a静态库占用的体积,详见这里(需翻墙)。

ARC->MRC

有人提出用ARC写的代码编译出来的可执行文件是会比用MRC大的,原因大致是ARC代码会在某些情况多出一些retain和release的指令,例如调用一个方法,它返回的对象会被retain,退出作用域后会被release,MRC就不需要,汇编指令变多,机器码变多,可执行文件就变大了。还有其他细节实现的区别,先不纠结了。
那用ARC究竟会增大多少体积?我觉得从汇编指令的增多减少去算是很难算准确的,这东西涉及细节太多,还是得从统计的角度计算。做了几个对比试验,统计了几个同时支持ARC/MRC的开源项目在开启/关闭ARC的情况下__TEXT代码段的大小对比。只对比__TEXT代码段是因为:
ARC对可执行文件大小的影响几乎都是在代码段
可执行文件会进行某种对齐,例如有些段在不足32K的时候填充0直到对齐32K,若用可执行文件大小对比结果可能是对齐后的,不准确。

实验数据:

------- MBProgressHUD SDWebImage FMDB
开启ARC 19532 24424 29056
关闭ARC 17648 22575 25848
对比 ↓9.6% ↓7.5% ↓11%

结果是ARC大概会使代码段增加10%的size,考虑代码段占可执行文件大约有80%,估计对整个可执行文件的影响会是8%。
可以评估一下8%的体积下降是不是值得把项目里某些模块改成MRC,这样程序的维护成本上升了,一般不到特殊情况不建议这么做。

无用代码

在项目里新建一个类,给它添加几个方法,但不要在任何地方import它,build完项目后观察linkmap,你会发现这个类还是被编译进可执行文件了。
按C++的经验,没有被使用到的类和方法编译器都会优化掉,不会编进最终的可执行文件,但object-c不一样,因为object-c的动态特性,它可以通过类和方法名反射获得这个类和方法进行调用,所以就算在代码里某个类没被使用到,编译器也没法保证这个类不会在运行时通过反射去调用,所以只要是在项目里的文件,无论是否又被使用到都会被编译进可执行文件。
对此我们可以通过脚本,遍历整个项目的文件,找出所有没有被引用的类文件和没有被调用的方法,在保证没有其他地方动态调用的情况下把它们去掉。如果整个项目历时很长,历时代码遗留较多,这个清理对可执行文件省出的空间还是挺可观的。

类/方法名长度

观察linkmap可以发现每个类和方法名都在__cstring段里都存了相应的字符串值,所以类和方法名的长短也是对可执行文件大小是有影响的,原因还是object-c的动态特性,因为需要通过类/方法名反射找到这个类/方法进行调用,object-c对象模型会把类/方法名字符串都保存下来。
对此我们可以考虑在编译前把所有类和方法名进行混淆,跟压缩js一样,把长名字替换成短名字,这样做的好处除了缩小体积外,还对安全性有很大提升,别人拿到可执行文件对它class-dump出来的结果都是混淆后的类和方法名,就无法从类和方法名中猜出某个方法是做什么的,就难以挂钩子进行hack。不过这样做有个缺点,就是crash堆栈反解出来的堆栈方法名会是混淆后的,需要再加一层混淆->原名的转换,实现和使用成本有点高。
实际上这部分占用的长度比较小,中型项目也就几百K,对安全性要求高的情况可以试试。

冗余字符串

代码上定义的所有静态字符串都会记录在在可执行文件的__cstring段,如果项目里Log非常多,这个空间占用也是可观的,也有几百K的大小,可以考虑清理所有冗余的字符串。另外如果有特别长的字符串,建议抽离保存成静态文件,因为AppStore对可执行文件加密导致压缩率低,特别长的字符串抽离成静态资源文件后压缩率会比在可执行文件里高很多。

CheckList

最后把缩减iOS安装包大小的各种方法列出来做了张CheckList图:

2076247-dde8e96bdd40396b.png

参考文献:http://blog.cnbang.net/tech/2296/

附上我的博客链接:oragekk'Blog 欢迎留言-不过评论系统换成了disqus需要搭梯子哦

2013-08-06 09:43:00 weixin_33936401 阅读数 1
iOS开发中,经常需要对静态库进行操作,以下是几个常用的静态库操作命令。
 

合并模拟器库文件和真机库文件 
lipo -create -output lib.a lib-armv6.a lib-i386.a
其中lib.a是合并后的输出文件,lib-armv6.a和lib-i386.a分别对应真机静态库和模拟器静态库文件。
 

查看静态库中包含哪些架构
lipo -info lib.a
该命令可以查看静态库中包含哪些架构,如armv7和i386。
 

解压出指定架构的静态库
lipo -extract_family armv7 -output lib-armv7.a lib.a
或者
lipo lib.a -thin armv7 -output lib-armv7.a
以上命令可以从lib.a静态库中解压出armv7架构的静态库lib-armv7.a,可以以同样的方式解压出针对模拟器的架构库文件(如i386)。
 

将a格式的静态库解压为o文件
ar -x lib.a
以上命令可以解压出lib.a中的所有o文件。
 

将o文件合并为a文件
libtool -static -o lib.a *.o
与上一个解压命令相反,这个命令将所有o文件合并为一个a文件,这两个命令常用于多个项目中引用的a库存在冲突时(duplicate symbol)解决冲突的一种方式。

转自http://www.apkbus.com/android-127500-1-1.html

转载于:https://www.cnblogs.com/ipinka/p/3239910.html

IOS的静态库

阅读数 546

iOS 静态库

阅读数 352

iOS之静态库

阅读数 387

iOS 静态库

阅读数 3

没有更多推荐了,返回首页