iOS应用通常比Android应用大的原因有几个:
1. **架构差异**:iOS应用通常使用Objective-C或Swift编写,这些语言编译后的二进制文件可能比使用Java或Kotlin(Android的主要开发语言)编译的文件大。
2. **资源文件**:iOS应用通常包含为多种设备分辨率优化的图片资源,如@2x和@3x分辨率的图片。这意味着同一个应用可能需要为iPhone、iPad等不同设备提供不同尺寸的资源,导致应用大小增加。
3. **平台特性**:iOS平台的特性,如统一的设计语言和硬件规格,可能使得开发者不需要为不同的设备和版本编写特定的代码。这可能导致应用中包含更多的通用代码,从而增加应用大小。
4. **编译和优化**:iOS应用的编译和优化过程可能更倾向于生成高效的代码,而不是最小化应用大小。这可能导致生成的二进制文件更大。
5. **平台限制**:iOS平台对应用的安装包大小有限制,但这通常足够大,使得开发者更关注应用的性能和功能,而不是大小。
需要注意的是,这些只是一些可能的原因,具体的应用大小取决于多种因素,包括应用的功能、设计、开发语言等。
针对占用应用体积大小的大户图片资源,来尝试回答下这个问题
.1. 一个应用的影响大小因素很大一方面是来自于资源,而非代码,一般应用主要的是图片资料,比如图标,背景,图片等.2. iOS 对于图片资源的要求严格一些、
2.1 从屏幕密度上说: 比如 iOS 上屏幕密度不同,得支持 iPhone 6 Plus (3倍),iPhone 6(2倍) iPhone 3GS(1倍)那么你必须提供三种屏幕密度的图片资源,即: 60x60,40x40,20x20, 如果不提供的话,至少在 iOS 7之前则会显示文件缺失.这方面 Android 的机制复杂但宽松一些:说复杂是因为 iOS 的图片资源主要有屏幕密度作为区别(在 iOS 8中也加入了几个屏幕大小的类别),但是 Android 呢,你可以看到: 根据Android 关于资源的官方文档 Providing Resources上面所列举出来的 Table 2. Configuration qualifier names. 有18大项之多.不仅包含屏幕密度,长,宽,大小,比例,方向,语言,还包含其他 N 多情况. 这是复杂的一面.按理来说,Android 的应用应该比 iOS 的大才对.但是事实并不是这样的.因为 Android 的限制宽松一些.就拿屏幕密度来说,iOS 的屏幕密度现在就三种,(如果不考虑老的设备的话,就算两种了)但是 Android 的设备,你知道千奇百怪,很多种--不过基本也在1倍,2倍,3倍,左右.如1.5倍, 2倍, 2.2倍,2.5倍等等. 屏幕密度很多种,怎么办? Android 在一开始设计的时候就提供了这样一个解决方法:即,如果1.5的设备,对应图片不存在,如果有2倍或以上的倍数的图片就用相应的图片,缩放后使用.上面文档关于屏幕密度的与资源的匹配说明如下:
Note: Using a density qualifier does not imply that the resources are only for screens of that density. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the best match.
这样造成的一种情况就是:很多应用其实都是主要使用一份屏幕密度的图片资源,比如我看微信 Android 版本,有一个版本的资源图片主要集中在3倍上. 这样一来,Android 应用就比 iOS 设置少了两份屏幕密度的资源了.
在这里稍微总结一下:Android 的图片资源查找规则是查找最匹配的一个,最终查找到有就不会出错.而 iOS 在 iOS 7之前呢,则就是查找匹配的资源.对于一般的图片,图标来说,从96x96压缩到72x72对外观应该没有什么影响(具体我没有测试过),所以导致 Android 中提供的资源少一些.
2.2 上面说了屏幕密度,那屏幕大小呢? Android 的屏幕大小也是众多的,反正我是说不清倒底有多少,但是 iOS 呢? 我估计你稍微查找下资源,是可以穷举过来的. 例如 iPhone 从3GS到5S 屏幕的宽度都可以表述为320点宽对设计和实现上有这么一些影响:1. 也许你已经知道,很多设计师一般是以 iPhone 为参考大小来设计的.这个时候举一个例子:假充我需要有一个设计上有一个背景,320x240, 这样设计师,切出来之后,就是320x240再出一份,640x480的, iOS 开发者,放上去直接可用 - 搞定,到面透气去了.Android 开发者,这个时候就苦逼一点了,因为 Android 的屏幕宽度比例众多,怎么搞?一开始 Android 开发工具提供了一个叫 Draw-9-Patch 的软件(我就不具体描述这个软件有多难用了,反正用过的都说坑,--- 后来这个软件可以拖动了,1年成集成进 Android Studio,更好用了),这个软件就是用来画点九(.9.png)图片,点九图片的概念具体我就不解释了(基主要是一个图片四条边,左边和上边可定义可扩展区域,右边和下边可以用来定义内容区域)然后花几分钟,或者补学者,慢一点10多分钟,将一张图片处理好,作为背景来说,可自动根据大小拉伸缩放.(最典型的案例其实是,如聊天用的气泡背景图)上面的问题造成这样的可能:一张背景图在 iOS 因为至少有两份,而且是原图大小可能要10多 K.但在 Android 这边制作成点九格式之后一般是1K 不到.
说明: 在设计上,(主要内容区域)纯色的背景下点九处理是再好不过了,但是有些纹理的就会导致最终的效果差强人意了. 说明2: 在 iOS 中,Xcode 5也加入了制作类似点九图的功能叫 Slicing.(之前也可以在代码中,设置图片的edge 来达到点九的效果,但是一般用的情况不多- 这是由于 iOS 设备尺寸种类有限决定的)说明3: iOS 比 Android 更容易在应用中还原设计. Android 中由于尺寸众多,导致开发者对设计还原的妥协. 所以一般的应用大小反而更低,但是美观上略输(针对现在,以前是输很多),其实从某些方面来说,这也是近年影响扁平化设计的一个因素,纯色远比纹理,阴影,高光处理来得方便.
总结: Android 系统资源宽松灵活,使得 Android 应用体积较小,但是设计上不如 iOS 精致作为开发人员,虽然前几个答案不能说错,但是感觉没有提到点子上
我们做游戏使用unity开发,不管是iOS还是安卓,两个平台使用的资源都是一样的,编译都用IL2CPP,iOS同时支持32位和64位,安卓同时支持arm和x86,打出来的原始包,安卓会大得多。但是iOS上传到App Store后,包体的大小大致要大一倍,为什么?因为 App Store显示的是手机安装后的实际大小 ,而不是开发人员上传的ipa大小,也就是说压缩比越大的app显示出来的大小与ipa本身差别越大。而apk上传Google play后包体大小几乎不会有变化,这就是导致App Store的包要比安卓大很多的根本原因
另外apk是可以优化的,例如只出arm的包可以再小很多,因为现在x86架构基本上只有模拟器在用
例如腾讯的捕鱼来了,在App Store将近800m,但是官网下的apk才200m
苹果这样做的好处,是希望用户不要来问为什么我的手机明明还有200m空间,下载一个80m的应用会一直失败啊…
iphone的ipa可能把应用里面的资源整合到安装包里面去,所以初始安装包较大。 而android的apk可能只把重要文件打包成安装包,而其他资源则在进入应用后再加载,所以安装包相对较小。
题主指的应该是,同一个应用在App Store上标注的APP大小跟Android应用商店上的差别很大吧。
这是因为App Store上标注的APP大小是安装之后的大小,Android应用商店大多只是显示安装文件的大小。 Android安装APP后,占用空间其实和iOS版相差不大。
Android上微信
Android上网易云音乐
iOS上微信
iOS上网易云音乐