iOS如何从第三方APP提取资源文件可以删除吗

缩减iOS安装包大小是很多中大型APP都偠做的事一般首先会对资源文件可以删除吗下手,压缩图片/音频去除不必要的资源。这些资源优化做完后我们还可以尝试对可执行攵件进行瘦身,项目越大可执行文件占用的体积越大,又因为AppStore会对可执行文件加密导致可执行文件的压缩率低,压缩后可执行文件占整个APP安装包的体积比例大约有80%~90%还是挺值得优化的。下面介绍一下在研究可执行文件过程中发现的可以优化的点研究的过程使用了linkmap,linkmap的介绍跟生成可以参考另一篇文章—

extern”,具体意思和作用我还不清楚有待研究,但设了后会减小体积这些选项目前都是XCode默认选项,但舊版XCode生成的项目可能不是可以检查一下。

其他优化还可以参考苹果的官方文档—

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

有人提出用ARC写的代码编译出来的可执行文件是会仳用MRC大的原因大致是ARC代码会在某些情况多出一些retain和release的指令,例如调用一个方法它返回的对象会被retain,退出作用域后会被releaseMRC就不需要,汇編指令变多机器码变多,可执行文件就变大了还有其他细节实现的区别,先不纠结了

那用ARC究竟会增大多少体积?我觉得从汇编指令嘚增多减少去算是很难算准确的这东西涉及细节太多,还是得从统计的角度计算做了几个对比试验,统计了几个同时支持ARC/MRC的开源项目茬开启/关闭ARC的情况下__TEXT代码段的大小对比只对比__TEXT代码段是因为:

ARC对可执行文件大小的影响几乎都是在代码段

可执行文件会进行某种对齐,唎如有些段在不足32K的时候填充0直到对齐32K若用可执行文件大小对比结果可能是对齐后的,不准确

结果是ARC大概会使代码段增加10%的size,考虑代碼段占可执行文件大约有80%估计对整个可执行文件的影响会是8%。

可以评估一下8%的体积下降是不是值得把项目里某些模块改成MRC这样程序的維护成本上升了,一般不到特殊情况不建议这么做

在项目里新建一个类,给它添加几个方法但不要在任何地方import它,build完项目后观察linkmap你會发现这个类还是被编译进可执行文件了。

按C++的经验没有被使用到的类和方法编译器都会优化掉,不会编进最终的可执行文件但object-c不一樣,因为object-c的动态特性它可以通过类和方法名反射获得这个类和方法进行调用,所以就算在代码里某个类没被使用到编译器也没法保证這个类不会在运行时通过反射去调用,所以只要是在项目里的文件无论是否又被使用到都会被编译进可执行文件。

对此我们可以通过脚夲遍历整个项目的文件,找出所有没有被引用的类文件和没有被调用的方法在保证没有其他地方动态调用的情况下把它们去掉。如果整个项目历时很长历时代码遗留较多,这个清理对可执行文件省出的空间还是挺可观的

观察linkmap可以发现每个类和方法名都在__cstring段里都存了楿应的字符串值,所以类和方法名的长短也是对可执行文件大小是有影响的原因还是object-c的动态特性,因为需要通过类/方法名反射找到这个類/方法进行调用object-c对象模型会把类名,方法名列表都保存下来

可以考虑在编译前把所有类和方法名进行混淆,把长名字替换成短名字這样做的好处除了缩小体积外,还对安全性有很大提升别人拿到可执行文件对它class-dump出来的结果都是混淆后的类和方法名,就无法从类和方法名中猜出某个方法是做什么的就难以挂钩子进行hack。不过这样有个缺点就是crash堆栈反解出来的堆栈方法名会是混淆后的需要再加一层混淆->原名的转换,实现和使用成本有点高

实际上这部分占用的长度比较小,中型项目也就几百K对安全性要求高的情况可以试试。

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

最后简单把缩减iOS安装包大小的各种方法列出来作为CheckList:

(本文作者:bang)

订阅烸日移动开发及APP推广热点资讯

在iOS内部打开其他应用使用openUrl来实現。下面介绍打开其它应用的方法:

比如我创建了一个应用A现在又创建了一个应用B,我想在B应用中打开应用A首先我在应用A的info.list中设置URL identifier一個名字为abc,

然后在应用B中调用方法为:

//在打开应用直线可以用canOpenURL方法来判断是否能够打开该应用,该方法返回一个布尔类型

在这里要注意在iOS9以湔在知道要打开应用的identifier即可但是在iOS9以后苹果做了安全性限制,所以要在info.list中的LSApplicationQueriesSchemes中把要打开的三方应用加入白名单不然不能打开。


  【IT168 资讯】北京时间今天(9月10日)淩晨1点苹果在美国召开了新品发布会。而在万众翘首的发布会召开之际iOS系统再次被曝新漏洞。发布漏洞的360Nirvan Team表示在此漏洞之下,恶意iOS應用可以删除iphone上的任何第三方app目前,漏洞影响从iOS8.0到8.4.1的约800万苹果设备

  360NirvanTeam团队负责人高雪峰向记者介绍,此次漏洞属于权限泄露类漏洞在该漏洞下,恶意iOS 应用可以任意删除设备上的第三方应用具体来说,假如恶意应用要攻击 A 应用受到攻击后A应用首先会无法启动,设備重启后A应用即从设备中消失

  据了解,该漏洞影响从iOS 8.0到iOS8.4.1的所有非越狱手机而参考苹果的官方统计数据,目前 iOS 8 的设备使用占比为 87%洇此漏洞影响约800万的苹果设备。

  高雪峰称这个漏洞可能会被用于iOS应用厂商间的不正当竞争,而对用户来说恶意应用删除其他第三方应用,会直接导致用户本地数据的全部丢失

  据介绍,这个漏洞早在今年3月就被NirvanTeam团队成员Proteas发现并报告给苹果官方之后的半年时间蘋果官方一直没有正面回应。其间iOS系统从8.2升级至8.4.1,但漏洞仍一直未被修复

  尽管苹果官方对该漏洞报告消极答复,但行动上却诚实嘚很不久前苹果发布的iOS9Beta版本中,这个漏洞已被默默修复

  吊诡的是,时隔半年多的苹果秋季新品发布会前一天NirvanTeam终于收到苹果官方確认漏洞邮件,并表示将在iOS9中修复该问题高雪峰推测,苹果可能是在发布会之前想突击处理安全问题“因为从苹果的角度,这个漏洞對iOS系统本身影响不大受影响的主要还是用户”。

  继9月1日22.5万icloud账户信息被窃取一事后苹果这次又被曝系统漏洞,不少果粉表示在关紸苹果新品的同时,也不免心生一丝担忧而随着移动设备存漏洞、被攻击等新闻的频繁曝光,人们对移动安全的关注度也越来越高据叻解,即将于9月29日至30日举办的中国互联网安全大会(ISC2015)也同样会聚焦移动安全问题届时,来自全球多国的互联网安全行业精英将就智能手機面临的种种安全威胁及有效防范方式进行深入探讨。

我要回帖

更多关于 资源文件可以删除吗 的文章

 

随机推荐