android对比,android对比度

Android原生和Flutter使用过程的差异对比（二）

1、常用布局的对比

创新互联建站专注于连江网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供连江营销型网站建设，连江网站制作、连江网页设计、连江网站官网定制、微信小程序定制开发服务，打造连江网络公司原创品牌,更为您提供连江网站排名全网营销落地服务。

使用下来其他组件大致还算方便，但是相对布局而言使用便利程度上Android原生完胜，ConstraintLayout内部的所有子View可以设置互相之间的位置依赖关系。

而Flutter的Stack组件内部的Children只能通过外层包裹 Align后 固定位置，比如 Alignment.topLeft、Alignment.bottomRight 等。遇到复杂的堆叠布局需要通过外层包裹 Positioned 组件后设置固定的 top 和 left 距离以达到效果，内部子组件之间无法设置位置关联关系。

2、一些常用属性设置上的差异：

Margin外边距

Android：直接在布局文件对View设置android:layout_marginStart、android:layout_marginTop

Flutter：需嵌套 Container 组件并在内部设置具体的 margin 值

Padding内边距

Android：TextView、ImageView、各种Layout都可以直接在属性上设置android:paddingStart

Flutter：需嵌套 Padding 组件并在内部设置具体的值

组件的可见性

Android：每个view都可以通过setVisibility来设置可见、隐藏或者隐藏但占位

Flutter：没有单独设置组件是否显示的api，只能通过 bool 值控制是否添加该组件

事件监听

Android：常规的setOnClickListener和setOnLongClickListener设置单击和长按事件

Flutter：在需要添加事件监听的组件外层嵌套 InkWell 或 GestureDetector 并设置 onTap 等

3、生命周期

Android：

Activity和Fragment各自有完整的生命周期链路onCreate、onStart、onResume、onPause、onDestroy等

Flutter：

万物皆组件，组件继承 WidgetsBindingObserver 并重写 didChangeAppLifecycleState 函数进行监听

退回桌面依次执行inactive 》= paused，此时界面不可见用户不可操作，从桌面重新进入app执行resumed，状态较少如需在某些条件下触发特定操作可能要找别的方案，比如发通知之类的

Android图片框架对比

对比现在主流图片框架的优势和缺点，在实际项目中如何选择适合自己的框架；

Glide、Fresco、Picasso、ImageLoader

共同优点：

以上名词介绍

在分析他们的差异、优缺点之前，我们先了解图片缓存通用的概念：

以上概念在不同框架之间可能不同，比如Displayer在ImageLoader中叫做ImageAware,在Picasso和Glide中叫做Target。

以上为Glide的总体设计图。

整个库分为RequestManager（请求管理器）、Engine（数据获取引擎）、Fetcher(数据获取器)、MemoryCache（内存缓存）、DiskLRUCache（本地缓存）、Transformation(图片处理)、Encoder（编码处理）、Registry(图片类型以及解析器配置)、Target(目标)等模块。

简单流程： Glider收到加载及显示资源任务，创建Request并将它交给RequestManager,Request启动Engine去数据源获取资源，得到资源后通过Transformation处理后交给Target.

Glide依赖DiskLRUCache、GifDecoder等开源库去完成本地缓存和Gif图片解密工作；

为Bitmap 维护一个BitmapPool对象池, 对象池的主要目的是通过减少大对象的分配以重用来提高性能!

缺点 ：

①图片质量低：因为机制不同，速度快，但是图片的质量降低了RGB565;

②多尺寸缓存导致内存和磁盘占用多：根据ImageView大小来缓存，可能会导致一张图片可能根据展示情况来缓存不同尺寸的几份；

扩展理解参考：

以上为Picasso的总体设计图。

整个库分为Dispatcher、RequestHandler以及Downloader、PicassoDrawable等模块。

简单流程： Picasso收到加载显示图片任务后，创建Request并将它交给Dispatcher，Dispatcher分发任务到具体RequestHandler，任务通过MemoryCache及Handler(数据获取接口)获取图片，图片获取成功后通过PicassoDrawable显示到Target中；

上面Data的File system部分，Picasso没有自定义本地缓存的接口，默认使用http的本地缓存，API19以上使用okhttp,一下使用UrlConnection，所以如果需要自定义本地缓存就需要自定义Downloader;

缺点 ：加载速度没有其他框架快；

特点 ：只缓存一个全尺寸的图片，根据需求的大小在压缩转换；

以上为Fresco的总体设计图

整个库分为UI:DraweeView(View控件)、Drawable（图片数据）、DraweeController（图片控制器）、DraweeHiierarchy（图片体系）；Core:DataSource（数据源）、ImagePipeline（图像管道）、Producer（生产者）、ProducerFacotry(生产工厂)、Subcriber(订阅)、Supplier(供应者)、Consumer（消费者）；IO/Data:MemoryCache(内存缓存)、Network、DiskCache(磁盘缓存)、Recourse（本地资源）

简单流程： 从上面的结构可以看出，fresco主要采用了工厂+建造者的模式实现功能，逻辑划分比较清楚；Fresco框架整体是一个MVC模式，DrawableView---View用来显示顶层视图、DrawableController---Control控制加载图片的配置 事件的分发、DrawableHierarchy---Model 用于存储和描述图片信息，同时也封装了一些图片的显示和视图层级的方法；ImagePipeline模块负责从网络、本地文件系统、本地资源加载图片

缺点：

①框架大，影响Apk体积；

②一定的学习成本，使用比较繁琐，需要使用内部提供的ImageView控件,使用起来比较复杂；

写给Android开发者看的『微信小程序和Android开发的对比』

微信小程序近期可谓是动作频出，仅最近新增的能力就有：

种种迹象表明，微信对小程序的期望值是很大，所以在它推出的几个月效果没到达预期的情况下，之前的很多『克制』也就逐渐变成『放肆』了 —— 不过不管小程序以后的发展到底怎样，对我们开发者来发，多了解一些总是没有坏处的。

他山之石，可以攻玉。

对于是技术人来说，多了解一些不同的技术、不同的开发模式、不同的架构思想，提高技术『广度』，对于自己的成长是十分必要的。

所以，本文就是从一个 Android 开发者的角度，从项目工程方便切入，来分析一下『微信小程序』跟『Android App』开发上的一些异同。

『微信小程序』开发是一个相对较新的技术，希望通过本文，能让你对它多一些了解。

因为内容是从Android开发的角度来谈的，所以我假设你已经对 Android 开发比较熟悉了。并且对微信小程序的开发也比较感兴趣，如果要是再能有些 javascript、css 的基础的话那就更好了！

Android 开发我们已经比较熟悉——

作为对比，进行微信小程序开发所用的语言是这些——

wxml (WeiXin Markup Language) 基本约等于是 xml。微信之所以没有直接使用 xml ，可能是为了以后扩展方便一些（野心很大）。

同理， wxss (WeiXin Style Sheets) 基本约等于是 css。也是微信扩展了一些功能，比如统一的尺寸单位 rpx 。

对于 Android 来说，对于页面的描述基本上在 xml 中定义的，比如：

这是一个简单的典型的示例，这个文件就是描述了两部分内容：

some.wxss:

很明显可以看出：wxml 是负责了 页面结构 的展示；而 wxss 则负责了对 页面样式 的定义。

这种把结构和样式分离的做法，其实是延续了网页开发中的习惯（html + css）。

这样做的好处起码有两个：

——看起来还是挺简单的结构:

这三个文件用以描述小程序 app 相关的内容，他们的命名是固定这样的，位置也固定是在根目录下。

app.js 基本相当于 Android 中的 Application 类，文件中主要是有一个 App() 函数，来进行小程序的初始化操作。

app.json 的作用跟 Android 中的 AndroidMainifest.xml 文件很相似 —— 都是静态化的配置文件。

app.wxss 定义全局的样式 —— 其定义的样式会作用于每个页面。比如在 app.wxss 中加入：

就可以给所有的 text 控件添加 5px 的 padding 。

当然，页面本身的 xxPage.wxss 可以定义局部样式来覆盖全局样式。

根目录下的 utils 文件夹中有一个 util.js 文件，这个故名思意，是类似于 Java 中的一些工具类的存在。

utils 文件夹其实是一个非必须的结构，而它之所以出现在官方的 HelloWorld 工程中，是作为一个代表，表明了开发者在这里是可以自定义新的文件夹和结构的。微信小程序作为一个使用 js 来开发的平台，是可以使用许多第三方的 js 库的，对于这些第三方库，以及其他的图片资源等，都可以放到自定义的文件夹中。

pages 文件夹下包含两个子目录：index 和 logs ，两个目录的结构都是基本一样的，都是包含四个相同主名称的文件： xx.js、xx.wxml、xx.json、xx.wxss 这几个文件。

这样的一个典型结构表明它是一个小程序的页面，四个文件的作用分别是：

在视图的动态显示上，微信小程序使用了 数据绑定（data-binding） 的方式。

如果你之前使用过 AngularJS 或者 Vue.js 等这些流行的 js 框架，那么你肯定对 数据绑定 并不陌生。它是一种把一个控件的属性绑定到某个数据对象（view-model）的属性的方法，这样在改变数据对象属性的时候，所对应的控件属性也就会相应变化 —— 在开发中，这种方式会使得对 View 层的显示控制变得十分简单、自然。

基于此，软件工程的流行架构方式也在之前的 MVC 、 MVP 之外，又多了一个 —— MVVM（Model-View-ViewModel） 。

数据绑定 这种方式现在是如此的流行，以致于 Android 官方都出了一个 [Data Binding Library] ( ) 来支持数据绑定，但是由于成熟度等原因，目前还并没有成为主流，Android 中的主流视图显示方式，还是通过开发者手动给每个控件 set 数据。

—— 单从这一点上看，微信小程序的开发模式是比原生 Andorid 要『先进』一些的~ ????

小程序虽然是和前端 H5 页面一样是用 js 来开发，但是由于它最终运行的平台不再是浏览器，而是和 App 的表现几无二致，所以页面的生命周期也是和 App 差不多的。

一个小程序页面的典型生命周期如下：

对比一下 Android 的 Activity 生命周期 ：

微信小程序的页面生命周期稍微简单一些，但主要的思想跟 Activity 生命周期基本是一致的。

小程序的官方 IDE 是微信自己出品 微信Web开发者工具 ，它内置了一个小程序的运行环境，本质上是基于 Chrome 内核的一个浏览器框架，算是一个模拟器了。

——它虽然跟 Android 的各种高大上的模拟器相比起来略显简陋，但是基本该有的功能也基本都有（断点、Log、网络监控等），而且由于是基于浏览器内核的页面 DOM 解析，所以运行的速度也是像浏览器打开网页一样流畅，不会像 Android 模拟器那样对系统资源要求很高。

另外，在绑定了开发者账号之后，也可以用手机进行真机调试来调试小程序，所以也能在上线前用不同的机器来进行充分的兼容性测试。

总体来说，小程序作为一个新的形态，从开发的角度，它可以算作是一个【Native开发】和【H5开发】的结合，它吸收了原生开发和 H5 开发的优点。对于前端开发人员和原生开发人员来说，都可以在微信小程序中找到许多熟悉的东西。再细节的许多点这里就不在赘述了，大家如果有兴趣，可以自己上手去体验一下。

综上，自然也就有两种人特别适合去做小程序的开发——H5的前端开发人员，以及之前的 Android/iOS 原生 App 开发者。

微信小程序的开发总体来说是很简单的。

—— 对于前端开发者来说，了解一下原生 App 的一些相关思想即可，这些工作其实只要读一遍小程序的开发者指南基本就差不多了。

—— 而对于原生开发者来说，只要稍微补一下 js 的相关知识（html/css），也基本就差不多可以上手去做了。如果你之前恰好已经有过一些 js 的使用经验，那就不用多说了，花半个小时看一下小程序的文档，直接上！

关于作者 :

Android、iOS历史版本对比

本文按时间顺序，试着梳理Android和iOS诞生以来的各重要版本以及其特点，看看这两个系统各自的发展速度和重点。

划时代的iOS第一代发布，可以说最核心的智能手机应用在这个版本已经有了，包括地图、浏览器、itunes、全屏幕触摸操作，这也可以理解当第一代iphone出现时带给所有人的震撼。

2.0最重大的改变是开放了AppStore，可以开发和使用第三方应用了，这几乎是整个移动互联网生态的基石。

iOS2.0之后2个月，Android横空出世，全球第一台Android设备是HTC Dream。Android在1.0时基本也把完整的智能手机体验带给了广大用户，当然也包括了AndroidMarket。

各功能的优化，包括支持了早该有的文本剪切、复制、黏贴等功能

主要添加了对iPad的支持

显著的变化是支持了多任务，尽管并不同桌面系统中真正的多任务处理，但这是苹果理解的在移动设备上用户所需要的多任务。随着多任务支持，双击home键的效用由原来的截屏操作，变为显示最近运行的应用。

这是一个相当成熟的系统，导致一个很长的时间内国产机一直保持在这个系统版本上。

专为Android平板设计的操作系统，但却是个短命的版本，因为他不兼容phone

重点功能是增加了siri，虽然当时很惊艳，但现在基本是个鸡肋功能。

无明显亮点，槽点是把之前一直使用的GoogleMap换成了苹果自己的Map

各种功能的优化，虽然没有明显的亮点，但稳定性较高，很长一段时间国内Android系统的主流版本，甚至到4年后的今天，仍然占有了约5%的市场

加强了开放，给与开发者更多的框架接口，比如支持小插件，通知可自定义更多操作，支持第三方键盘，开放指纹识别等。

还是一些新特性，如iPhone 6s/6s plus支持3D-Touch等

-TensorFlow Lite

TensorFlow Lite是谷歌机器学习工具TensorFlow的精简版，新工具可帮助低功耗设备跟上当今高强度任务处理，利用新的神经网络API帮助底层芯片加速数据处理。

可以看出，从一开始两个平台的高歌猛进，版本频发（特别是Android系统，当初的版本真的是满天飞，记得还有个中移动定制的android版本），到现在基本上是一年一个版本。两个系统都从野蛮成长阶段过度到了平稳发展的阶段。

同时两个平台也显示出了高度的同质化，从拍照、音乐、App市场、地图之类的基本功能，到语音助手（siri、now）、支付的高阶功能，再到现如今的AI、AR等，两个系统虽然你追我赶，但基本还是保持了步调的一致。随着Android系统性能的不断优化，如今的Android高端机至少在系统层面已经不差iOS了。

可以预见，未来2个系统也注定会越来越像，无论是功能还是性能，甚至随着三星、华为、oppovivo、小米等厂商的发力，Android系统在某些细节层面肯定会超过iOS。细节+性价比，也许是用户从iOS转向Android的理由之一，而用户维持iOS的理由则是已经习惯了iOS的生态，怕做出改变。

无论如何，这两个系统恐怕还得长期共存，他们互相恐怕是无法打败对方的，更有可能的是一起被新出现的更高层次的系统打败，毫无还手之力的那种。

iOS与Android系统优势对比

其实，文章的观点并没有错，但事实上iOS同样有Android目前无法企及优势，例如本文中所列举的九大方面：(本文只讨论iOS与Android系统级，并不涉及手机外观、工业设计和其他部分)

一、流畅性碾压性优势

由于Android系统采用了虚拟机的运行机制，这就需要消耗更多的系统资源了运行App，即便升级到Android 4.X，甚至Android 5.X，系统流畅性还是不如iOS。iOS无论是桌面滑动、App的内部操作，屏幕与指尖都似乎带有“粘性”一般，这就使得手指触控到哪里，屏幕就会马上指向哪里，而Android呢?看似已经媲美了iOS的流畅，但只是媲美，多数还是不及iOS流畅，即便Android的触控延迟只有0.1秒其实就已经分出胜负了。

这里的流畅并不是指手机应用的打开速度、关机速度。流畅指的是运行速度、触控速度，因为这才是最直观的影响用户体验部分。

二、iOS系统的软件App多优先升级

并不是软件升级快就代表好用，但至少软件升级可能会为我们带来额外的功能体验，拿最近的微信举例，苹果iOS系统优先升级并推出了朋友圈的“小视频”功能，而Android系统则多等了几个星期的时间。绝大多数主流的应用软件都以iOS系统开发升级为优先级，只有少数未通过苹果审核上架、或特殊应用才会在Android先放出。

说到软件App方面为何iOS系统升级快，这得益于苹果有一套独特的与开发者分享收入的计划，有了利益关系，这能够让开发者更加有动力、更积极的开发和升级应用。而谷歌虽然也为Android开发了专属的应用商店，但在国内的环境下国人使用的并不多，况且升级速度并不快，体验尝鲜还要遥遥无期的等待。

三、iOS游戏不要数据包，Android玩大型游戏很麻烦

iOS的游戏直接通过官方App Store或在越狱后通过各种第三方助手安装即可，这期间除了部分老旧设备可能出现不兼容的游戏外，其它均完美被支持，没有游戏数据包一说。而Android玩家，如果要下载一个大型的游戏，必须要通过安装游戏主程序+额外下载几百MB不等的数据包才行，如果是主流的高通CPU还好，但凡碰到非主流的CPU的话，那游戏数据包可能就遥遥无期了，开发者心情好的话会为CPU做适配，否则就只有无限等待或移植的命运。

*注：Android系统的大型游戏，需要在安装游戏之后再下载数据包，数据包会针对手机的处理器以及GPU专门优化，如果选择了没有经过优化的数据包，可能出现无法运行或者贴图错误等情况。

iOS系统则是在下载游戏的时候一同下载数据包，不存在单独下载的情况。所以相同的一款游戏，Android系统可能只有几十M的大小，而iOS则达到了1G以上，这就是因为Android没有数据包而iOS包含了数据包。

再者，iOS目前的分辨率只有5种左右，而Andorid则大大小小的包含了近10种左右，再由于盗版或开发者利益关系原因，开发者更倾向于对iOS优先适配。同时，游戏的质量(包括画面精美程度、触控流畅性等等)整体也要高于Andorid系统。或许有同学说Android打开游戏的速度要快于iOS。但玩游戏是比打开的速度吗?

四、小偷即使偷走也不会泄露隐私

自从iOS7系统之后，苹果增加了安全保护机制，即如果进行二次刷机或强行开启手机的锁屏密码，必须要输入原有的Apple ID的密码进行解锁才行。我们不能防止手机被偷，也不指望被偷后能够找回(虽然可以定位，但是否可以找回完全凭自己本事。)，但至少可以保证我们手机内的资料或隐私不被居心不良者窃取。小偷拿走手机后最多当配件廉价的卖掉。

Android系统虽然同样有密码保护机制，但相比苹果而言就要逊色一些，稍微懂点的人只要进入Recovery后，就能刷机或清理数据，手机的密码形同虚设了。虽然有少部分手机做到了二次加密，但大多数的Android系统在这方面还是比较脆弱。

注：Recovery模式指的是一种可以对安卓机内部的数据或系统进行修改的模式，也叫工程模式(类似于windowspe)。在这个模式下我们可以刷入新的安卓系统，或者对已有的系统进行备份或升级，也可以在此恢复出厂设置。

五、更省电、功耗控制好

系统机制的不同导致了Android会占用更多的资源来支撑系统运行，官方宣称的3000毫安时电池实际使用也不过一天的时间，而iOS系统的iPhone虽然看似电池容量不高，但得益于精心优化，它在待机耗电大约只有Android系统的30%左右，使用耗电更是只有25%-75%。

iOS系统采用独立唤醒技术，以及为处理器量身定制的芯片，在待机时更省电，使用时的耗电详情呈“线性”趋势。虽然有部分Android手机续航强，但多为高容量的电池，并且使用长时间后，由于系统或电池的原因，更是会出现“跳电”的现象。

六、没有强迫症根本不用清后台

“不清理后台会很费电”、“不清理后台会很卡”......反正也不知道什么时候起，手机清理后台就成了必须要做的了，至于原因就为了亮点，不卡、省电。不过这只对Android系统有效，iOS系统完全没有清理后台的操作，同样耗电、流畅性也不会被影响。

怀疑笔者说的不对?自己试试看就知道了。至于有些同学说两大系统真假后台的问题，这个就仁者见仁了，没有人敢说Andorid的后台机制最好，也没有人保证iOS的后台机制更适合。

七、iOS更稳定不易死机

许多问题我们虽然不想承认，但却是客观存在的事实，下至低端入门、上至旗舰顶配，Android系统在长时间使用后，都会或多或少出现些不稳定现象，比如最不能忍的死机现象，可换电池的手机还好，扣个电池就恢复了，但不可拆卸的电池手机就只能等待重启或长按关机键恢复了。

iOS也会死机，但相比较之下出现死机的几率要少很多。

八、综合实力最好的影像系统

目前搭载iOS系统的设备最高规格的摄像头为800万像素，但即便是这样，凭借iOS系统的精心优化，它仍是目前智能手机中综合体验最好的手机之一(包括对焦速度、成像速度、成片速度、成片率、多场景拍照等综合而定)。而搭载Android系统目前已经达到了2070万像素级别，感光原件甚至更好，但拍照的综合体验来看，iOS的优势依旧明显。

最新的iPhone6 Plus搭载了光学防抖特性，并且采用了先进的相位对焦技术，拍照体验更是有明显的'提高。iOS在视频拍摄方面也同样具有优势，尤其对视频拍摄时的防抖处理的十分到位，再搭配iMovie等专属视频处理软件，让它比Andriod更具有优势。

九、双核战8核

由于iOS高度整合、优化、封闭性，让它无论是在各方面的表现十分优异，其中最值得欣慰的一点目前的iOS系统有着自己的一套生态体系，即便是使用双核处理器，配合定制的GPU处理单元，在综合表现来看同样不输Android，要知道现在8核处理器已经不足为奇。

总结：

虽然本文列举了9项iOS相比Android的优势，但同时也并不否认iOS还存在许多可以学习改进的地方。而对于许多功能性的东西，本文也同样没有将越狱的范畴考虑在内，如越狱后iOS能实现比现在更多更好的功能体验。

其实，争了几年了，都说自己的系统好用，但事实上两大系统各有优劣势，谈不上哪个系统最好。iOS系统优势慢慢的被追赶，Android的多样性逐渐被整合，这一切都是时间的问题而已，好与不好这都是相对的。对于我们普通使用者来说，哪个系统最好不重要，适合自己最重要。但至少从目前来看，iOS系统的系统级体验，还是需要Android来积极学习的。

iOS与Android系统介绍

其实，文章的观点并没有错，但事实上iOS同样有Android目前无法企及优势，例如本文中所列举的九大方面：(本文只讨论iOS与Android系统级，并不涉及手机外观、工业设计和其他部分)

一、流畅性碾压性优势

由于Android系统采用了虚拟机的运行机制，这就需要消耗更多的系统资源了运行App，即便升级到Android 4.X，甚至Android 5.X，系统流畅性还是不如iOS。iOS无论是桌面滑动、App的内部操作，屏幕与指尖都似乎带有“粘性”一般，这就使得手指触控到哪里，屏幕就会马上指向哪里，而Android呢?看似已经媲美了iOS的流畅，但只是媲美，多数还是不及iOS流畅，即便Android的触控延迟只有0.1秒其实就已经分出胜负了。

这里的流畅并不是指手机应用的打开速度、关机速度。流畅指的是运行速度、触控速度，因为这才是最直观的影响用户体验部分。

二、iOS系统的软件App多优先升级

并不是软件升级快就代表好用，但至少软件升级可能会为我们带来额外的功能体验，拿最近的微信举例，苹果iOS系统优先升级并推出了朋友圈的“小视频”功能，而Android系统则多等了几个星期的时间。绝大多数主流的应用软件都以iOS系统开发升级为优先级，只有少数未通过苹果审核上架、或特殊应用才会在Android先放出。

说到软件App方面为何iOS系统升级快，这得益于苹果有一套独特的与开发者分享收入的计划，有了利益关系，这能够让开发者更加有动力、更积极的开发和升级应用。而谷歌虽然也为Android开发了专属的应用商店，但在国内的环境下国人使用的并不多，况且升级速度并不快，体验尝鲜还要遥遥无期的等待。

三、iOS游戏不要数据包，Android玩大型游戏很麻烦

iOS的游戏直接通过官方App Store或在越狱后通过各种第三方助手安装即可，这期间除了部分老旧设备可能出现不兼容的游戏外，其它均完美被支持，没有游戏数据包一说。而Android玩家，如果要下载一个大型的游戏，必须要通过安装游戏主程序+额外下载几百MB不等的数据包才行，如果是主流的高通CPU还好，但凡碰到非主流的CPU的话，那游戏数据包可能就遥遥无期了，开发者心情好的话会为CPU做适配，否则就只有无限等待或移植的命运。

*注：Android系统的大型游戏，需要在安装游戏之后再下载数据包，数据包会针对手机的处理器以及GPU专门优化，如果选择了没有经过优化的数据包，可能出现无法运行或者贴图错误等情况。

iOS系统则是在下载游戏的时候一同下载数据包，不存在单独下载的情况。所以相同的一款游戏，Android系统可能只有几十M的大小，而iOS则达到了1G以上，这就是因为Android没有数据包而iOS包含了数据包。

再者，iOS目前的分辨率只有5种左右，而Andorid则大大小小的包含了近10种左右，再由于盗版或开发者利益关系原因，开发者更倾向于对iOS优先适配。同时，游戏的质量(包括画面精美程度、触控流畅性等等)整体也要高于Andorid系统。或许有同学说Android打开游戏的速度要快于iOS。但玩游戏是比打开的速度吗?