https://www.jianshu.com/p/a49d59b01669 项目打包之后.ipa包的大小是118.9M,上传到App Store后iPhone6s上显示85.5M,下载时间太长,所以找了一些优化方法,下面这些都是别人写的自己试了一下确实好用,不是原创,只是记录一下. 1.配置编译选项 (Levels选项内)Generate Debug Symbols  设置为NO,这个配置选项应该会让你减去小半的体积.注意这个如果设置成NO就不会在断点处停下     2.舍弃架构armv7 a

在我们提交安装包到App Store的时候,如果安装包过大,有可能会收到类似如下内容的一封邮件: 收到这封邮件的时候,意味着安装包在App Store上下载的时候,有的设备下载的安装包大小会超过100M.对于超过100M的安装包,只能在WIFI环境下下载,不能直接通过4G网络进行下载. 在这里,我们提交App Store的安装包大小为67.6MB,在App Store上显示的下载大小和实际下载下来的大小,我们通过下表做一个对比: iPhone型号 系统 AppStore 显示大小 下载到设备大小

1.iOS瘦身之armv7 armv7s arm64选用 机器对指令集的支持是向下兼容的,因此armv7的指令集是可以运行在iphone5S以上的,只是效率没那么高而已~ 但是由于苹果要求必须支持arm64,因此这个架构是必须存在的.在xcodeTARGETS里边Architectures: tup.png Architecture : 指你想支持的指令集. Valid architectures : 指即将编译的指令集. Build Active Architecture Only : 只是否

工程在经过多人后,往往会出现较多的垃圾,导致打包出来的ipa文件偏大,有时候我们会通过清理代码来给程序瘦身,而瘦身ipa效果明显的,主要通过清理程序里的无用图片. 推荐一个清理图片的应用 https://github.com/tinymind/LSUnusedResources 直接打开运行,点击Browse..选择工程目录,再点击Search 搜索出该搜索工具认为工程里没有用到的图片,当然那些没搜出来的就都是有使用的图片了,不用理会 注意:这里所说没有用到的图片不是真的没有用到,因为这个工具他

前沿 很早之前写过一篇相关文章,不过博客主机上跑路了之后数据没了,凭着记忆补了下相关资料 ipa安装包瘦身 清理无用图片,图片压缩(PNG换WebP和JPG),处于某种不可抗拒的原因,导致有部分3X图没有被App Thining处理,这部分3x图是否可以删除只用2x图.(这一条一般收益很小,因为大部分团队都会注意) 特殊字体文件 如果有自己封装的库,检查下静态库和动态库情况,不要该打静态库的不注意输出的是动态库,这个我们之前犯过错 App Code重构,找出无用代码(这个工作量大,但是对下面te

1.Bitcode 随着 Xcode7 的发布,Apple 提供了一项新的技术来支持 App 瘦身功能,那就是 Bitcode. 1.BitCode 是什么 Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the store. Including

iOS9 发布后,产生了一个使 App Thinning 无法正常运行的 bug.在iOS9.0.2 版本中,这个 bug 已经被修复,App Thinning 已经可以正常使用.当你从应用商店(App Store)下载应用时,请注意这点. iOS9 推出之后,大受欢迎.仅仅数周,已经有超过半数的 iOS 设备安装了这一新系统.这是 iOS 历代版本中采纳速度最快的-甚至打破了 2013 年 iOS7 创下的记录. 关于 iOS9,笔者最近发表了一篇名为Search APIs and SFSaf

iPhone经过这几年的发展,已经发生了很大的变化,例如屏幕变得更加多样,尺寸更多,内存变得更大,CPU的架构也在变化.伴随着iPhone的变化,iOS也在变化,例如AutoLayout.size classes.split view controller等.这些技术及设备的变化给我在开发的过程中也造成了许多的问题,不仅如此苹果通过不断推出新的技术,努力在帮助我们使用同一套代码开发适应多个设备的Universal的App.另一方面Universal App虽然在开发的过程中,方便了我们开发人员,

本文来自网易云社区 作者:饶梦云 1. 安装包组成 谈到 App 瘦身,最直接的想法莫过于分析一个安装包内部结构,了解其每一部分的来源.解压一个 ipa 包,拿到其 payload 中 app 文件的数据,整理归类后其大致如下: Exectutable: 可执行文件 Resources:资源文件 图片资源:Assets.car/bundle/png/jpg 等 视频/音频资源:mp4/mp3 等 静态网页资源:html/css/js 等 视图资源:xib/storyboard 等 其他:文本/字

本文来自网易云社区 作者:饶梦云 2.4. 清理无用代码 2.4.1. Dead Code Stripping Activating this setting causes the -dead_strip flag to be passed to ld(1) via cc(1) to turn on dead code stripping. Remove functions and data that are unreachable by the entry point or exported

1 分析当前ipa的组成 一般一个ipa会包含: 1) 资源文件 本地文件:数据.配置.数据库等等 字体文件 图片资源 2)  源代码 通过生成linkmap文件,分析源代码生成的编译文件的大小.在Build Settings中Write Link Map File设置为Yes (记住release时候不要设置为Yes). 编译之后会在build目录中生成两个LinkMap文件: XXX-LinkMap-normal-i386和XXX-LinkMap-normal-x86_64,分别代表在模拟器

Android XML shape 标签使用详解   一个android开发者肯定懂得使用 xml 定义一个 Drawable,比如定义一个 rect 或者 circle 作为一个 View 的背景.但是,也肯定也有人在能使用 Drawable 的地方选择使用一张 png 图(或者是一张 .9 图)作为 View 的背景,因为后者把问题交给 UI 设计人员去了,省事.当然,使用图片这种在项目中也很常见,如果不考虑 apk 大小,内存占用问题的话,是没有任何问题的.如果要给 apk 瘦身,减少内存

******** ******** 第一部分: 瘦身内容介绍 ******** ******** 项目新版本的迭代接近尾声, 因为历史累积问题, 导致有很多无效的资源让已经臃肿的APK变得更肿, 因此公司决定做一次Android APK的资源瘦身. 这次瘦身使用的是Lint审查工具,  用Android Studio的Generate Signed APK打包, 瘦身前APK为17.3M, 瘦身后为15.7M.  瘦身结果为APK大小减少了1.6M(9.x%) 1. 完全相同的一张图片, 在项目

[直播]APP全量混淆和瘦身技术揭秘 近些年来移动APP数量呈现爆炸式的增长,黑产也从原来的PC端转移到了移动端,通过逆向手段造成数据泄漏.源码被盗.APP被山寨.破解后注入病毒或广告现象让用户苦不堪言. 为了解决安卓APP容易被逆向的问题,除了对产品进行加固处理,代码混淆技术是对抗逆向攻击最有效的方式之一.本直播会分享阿里聚安全带来的APP全量混淆技术.此外越来越多的新特性正在啃蚀着大型APP的用户体验,APP瘦身减肥也成了亟待解决的问题,如何能在使用安全功能同时瘦身,也将是本期主题所带来的内

作者:非戈@阿里移动安全 1.我是怎么思考这件事情的 APK是Android系统安装包的文件格式,关于这个话题其实是一个老生常谈的题目,不论是公司内部,还是外部网络,前人前辈已经总结出很多方法和规律.不过随着移动端技术近两年的飞速发展,一些新的思维方式和优化方法也逐渐涌现和成熟起来.笔者在实践过程中踩过一些坑,收获了一些经验,在这里做个思考和总结,所以随笔给大家,希望对大家从事相关工作的时候有所帮助和参考,同时也是抛砖引玉,希望大家共同探讨这个开放性的话题. 关于为什么APK要瘦身,这个不多说,

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

前言 古老的MVC架构是容易被iOS开发者理解和接受的设计模式,但是由于iOS开发的项目功能越来越负责庞大,项目代码也随之不断壮大,MVC的模糊定义导致我们的业务开发工程师很容易把大量的代码写到视图控制器中,行业中对这种控制器有个专业词汇Massive ViewControler(臃肿的视图控制器).代码臃肿导致可读性可维护性差,而且这种不清晰的设计还有许多的副作用,比如代码重用性差.作为架构师需要关注项目的代码质量.指导业务开发工程师写出高质量,高健壮性,高可用的代码也是很重要的工作.因此需要

http://devyang.me/blog/2014/11/11/li-yong-android-gradleshou-shen-apk/ apk瘦身一般有两条线, 去除无用的代码,例如引用一个比较大的lib,只使用了其中很少的功能.其他无用的代码可以想办法去掉 去除无用的资源文件,可能是第三方lib中的,也有可能是开发中引入了无用的资源 去除无用代码 当然是Proguard了! gradle plug 0.14.0, runProguard 更名为minifyEnabled 去除无用资源 A

Orchard CMS是针对CMS开发的,对于很多开发需求来说,内容管理这块儿可能并不需要,而需要它的模块式开发模式.所以我这里通过对OrchardCMS进行瘦身,去除 内容管理部分的内容,保留简单的运行环境和基础的模块.需要做的工作: 去除Orchard Framework的内容管理部分,同时去除Orchard Framework依赖内容管理的相关内容. 去除Orchard Core部分的部分module,只保留Sharpe和Setting两个模块. 去除内容管理和博客管理的相关模块,只保留支

如何给UIViewController瘦身 随着程序逻辑复杂度的提高,你是否也发现了App中一些ViewController的代码行数急剧增多,达到了2,3千行,甚至更多.这时如果想再添加一点功能或者修改现有逻辑变得让人无比头疼.如果你遇到了这类问题,那是时候停下来了,思考一下如何更好地组织代码,给VC瘦身.本文将会阐述如何结合MVC的思想帮你的VC瘦身同时提高复用和可扩展性. 一.开发中常见的现象和缺点 iOS中最常见的一种设计模式就是MVC,但在实际开发过程中,我们因为这样.那样的原因让单纯

首发地址:http://www.jayfeng.com/2015/12/29/APK%E7%98%A6%E8%BA%AB%E5%AE%9E%E8%B7%B5/ 因为推广的需要,公司需要把APK的大小再"减小"一下,4M以内! 当达到4M以内之后,公司建议说,能否再压压?2M如何? 瘦身前 因为平时就考虑到大小的限制,所以很多工作已经做过了,如下列举现在的状态: 7.3M(Debug版本)和6.5M(Release版本) 开启minifyEnabled 开启shrinkResources