Android 的屏幕滚动操作不如 iPhone 流畅顺滑，是什么原因导致的？
来源：zhihu.com
【如题，比如刷微博时上下滚屏明显不如iPhone跟手(即便是13，14年的旗舰机，拖动起来也没有10年的iPhone4跟手)，这是安卓系统底层跟iOS的差距，还是说安卓手机的屏幕反应速度都不如iPhone的？】
几个高票答案说的都是现象而非原因。对 @劉長曦 专栏提到的 g+ 讨论做了个摘要，出处在此首先，安卓不缺硬件加速的支持。从安卓 1.0 开始，安卓就支持硬件加速。菜单的显示/隐藏、提醒的滑动渐变、Activity 之间的过渡以及对话框的显示/隐藏等都是经过硬件加速的。但硬件加速与安卓「窗口」的概念有关。比如以下这张截图，就包含四个窗口： 状态栏窗口 / 壁纸窗口 / 壁纸上的启动器窗口 / 菜单窗口安卓一开始的设计目标是「提供开放的应用平台」，在这种设计思路下，安卓通过许多个独立的 UI 元素来分享屏幕：比如输入法窗口和应用窗口就是两个不同的窗口。而同一个安卓应用，也由许多 Activity 组成（比如联系人列表是一个 Activity，联系人详情是另一个 Activity），每个 Activity 又有自己的窗口。发现了吗？安卓 UI 一切皆窗口：从主屏打开联系人应用，你看到的是主屏窗口和联系人列表窗口的动画；按下联系人查看详情，是联系人列表窗口和联系人详情窗口的动画；显示输入法，是键盘窗口的动画...早期的安卓使用软件来渲染窗口内的内容：在 2.3 前，窗口内容由软件渲染，而窗口的组合 / 移动则通过硬件加速绘制。安卓 3.0 起，改进了对硬件加速的支持，可以用硬件加速绘制一些窗口内的内容，（感谢
指正，还是有些绘图的API没有完全用硬件加速实现，需要开发者手动选择渲染方式。老应用跑在新版系统上强制开启硬件加速有可能出现异常，就是因为系统的某些绘图 API 没有完全实现硬件加速，而强制使用可能就会出现问题。）随着安卓版本更新，窗口内容对硬件加速的支持一直在改进，可以参考这里 。但为什么即便支持了硬件加速，也不能完全保证流畅度呢？事实上，安卓的这个多窗口设计，意味着 GPU 需要同时支持不同进程的多个活动 GL 上下文。而即便到现在，多数移动 GPU 执行上下文切换的代价还是相当高的。虽然安卓有堆硬件这一说，但硬件加速的资源也很容易被安卓的渲染机制吃光。比方说，Tegra 2 足够在 60 帧下把
屏幕的每个像素点渲染 2.5 次。但安卓 3.0 中，光是打开「所有应用」的视图，就需要绘制许多不同的窗口：需要对所有像素绘制一次背景；（往少了说）需要对一半的像素绘制一次 shortcut 和 widget 层；需要对一半的像素绘制一次图标和标签；也需要对所有像素绘制一次「所有应用」视图的黑色背景，还有「所有应用」视图的图标和标签...还不算对这些窗口做最后的组合，就把 GPU 的资源吃光了。当然，安卓对这个机制也有优化，比如把壁纸做成一个比屏幕大的窗口，这样在主屏滚屏时就不需要重绘，只要移动窗口就行。而这个绘制好了的窗口，就不需要额外的 GPU 计算量了。另一方面，OpenGL 硬件加速绘图也不是万能的，Nexus S 和 Galaxy Nexus 中，每个 OpenGL 应用会占用 8MB 内存。要知道 2MB 的进程开支都是个不小的代价。这 8MB 内存可能从后台进程那里分配而来，造成应用切换速度的下降。为了提升流畅度，还需要许多其他方面的努力：安卓 1.6 对前后台进程调度的优化、2.3 中对输入系统的重写、 加入并发的垃圾收集等。举一个流畅度不由硬件加速决定的例子：对滚屏操作，Nexus S 在 ICS 上的流畅度比在 2.3 中要低。这其实是因为计时机制发生了变化，有时在 ICS 中，当应用接收触摸事件并绘图时，可能在尚未准备好的情况下就获得了下一个事件，从而导致跟踪手指移动时可能错过一帧，但这时帧率仍然是 60fps （这个 bug 已经修复了）。@Julius 提到的是关于浏览器的渲染情况。在这方面，安卓和 iOS 的主要差别并非来自硬件加速绘图。早期安卓在渲染网页时做了与 iOS 不同的折衷：将网页以序列方式连续显示，而非贴片方式。这样在滚屏和缩放时不会出现 Safari 那样的占位符，但渲染的帧率不够快。安卓 3.0 后改用了贴片方式，改善了滚屏和缩放的体验。但不论是安卓还是 iOS，贴片都是由 CPU 渲染的。还有，「安卓后台应用太多吃资源」的说法也有问题。安卓的 UI 线程以默认优先级运行，后台线程以后台优先级运行。切换到后台的应用强制以后台优先级运行。而后台优先级利用了 Linux 的 cgroup 机制，它将所有的后台线程放进一个特别的调度组中，它们满打满算也无法占用超过 10% 的 CPU 资源。「安卓的触摸事件不像 iOS 那样优先」的说法也是错的。你可以架梯子看看安卓进程的优先级设定总的来说，根据 Dianne 的说法，多窗口设计对屏幕绘制的开销，是影响安卓的流畅度的已知因素之一。但决定「流畅」的因素还有很多，抓住某个特定技术细节不放的说法都是有失偏颇的。以上。
目前绝大多数主流Android手机性能都是过硬的，以Nexus 5为例，刷了Android L以后在Art环境和硬件加速的双重作用下，Google+列表也是极为跟手的，但对比iOS上相同应用，你或许还是会觉得iOS更为流畅。我认为主要原因是列表滚动的算法的差异，滑动流畅是一种视觉上的感觉，受到阻尼，动画曲线等各方面影响，并不是帧率能说明问题的（现在还写不出60帧列表的程序员该打板子好吗），Android scroller算法虽然一直在优化，但就目前的效果来看也就是刚好能work并不能实现非常自然的滚动效果，举个栗子：当你以极快的速度滚动列表时，在Android上列表会加速到一个超出预期的滚动速度，视觉上会觉得非常生硬，而iOS列表会保持一个合理的滚动速度，每一帧都如丝般顺滑。
日更新：上次主要针对题主说的具体问题“刷微博在苹果和Android手机上的差异”在具体的设备上做实验后进行了分析。今天我对“Android的流畅性”做个更进一步的讨论。加在后面。===============================================================我来说下我所知道的事情。我不知道iOS为什么流畅，但我知道一些Android为什么不流畅的原因。首先，就题主所说的问题，我用iPad和小米Pad对比了一下微博滑动滚屏这件事情（日目前微博app最新版本，打开的是“首页”和“发现”栏）。正如题主所说，直观感受上明显感觉iOS要流畅、舒服。在这件事情上我认为主要是这三个原因：速度曲线。当你滑动界面然后松手，这时界面会继续滑动，然后速度减小，直到速度为0时停止。iOS下速度减小的这个过程比较慢，尤其是快要停的时候是慢慢停的，视觉上有种很顺滑的感觉；Android下则从松手到停要快很多，相比之下有种戛然而止的感觉。从数据/技术角度来看这个事情，我们滑动界面的最终目的不是为了“动”，而是为了“停”，因此只要平滑的到达目的地，似乎越快完成这个过程越好，所以Android的选择是理所当然的。但事实是，大家普遍更喜欢iOS的方式，这样做显得更顺滑、更优雅。帧率。绝大部分时间两者都能保持60FPS左右的满帧率。但都会有偶尔的掉帧。并且Android上要比iOS上严重很多。（好吧，比起前两年，已经好太多了。）我前前后后滑动了几十次，iOS在前面遇到1次掉帧，后面就很稳定了。而Android几乎每滑动一次都会伴随一次掉帧。这完全就是真真实实的卡顿，用户必然会感觉到那一刻的不流畅。Android掉帧的原因我后面再详细分析。触摸响应速度。从手指碰到触摸屏，到屏幕上显示处理这次触摸产生的画面，是需要时间的。时间越短感觉越跟手。据说iOS的触摸屏的处理时间要比一般的Android手机快，这不是我的专长，不知道怎么验证。但在软件系统层面，Android的显示机制是app--&SurfaceFlinger--&Display，这比传统的app--&Display多了一步，主要基于这个原因，画面最终输出到屏幕要比传统的方式慢一帧(16.7ms)。我觉得第1点造成的影响最大，恰恰却是最技术/设备无关的。如果微博app或者Android系统要改变，很容易就可以调得跟iOS一模一样。但正是由于这是产品形态上的差别而不是纯粹技术上的优劣，反倒成了Android最不太可能改变的。第2点的影响其次，当然是指在目前这个大部分时候都能满帧的情况下。这方面是Android从早期到现在进步最明显的方面，使用了很多方法来优化帧率。但就算现在Android进化了很多，硬件性能也进化了很多，却仍旧不可能彻底消灭掉帧的情况。第3点通俗的讲就是跟手性，跟手性的重要性不言而喻，但现在的差别比较细微，且具体数据我也不清楚。我想过一个办法让桌面、微博这种内容和手一起动的应用绘制到屏幕的速度快一帧（16.7ms），其实就是抵消之前提到的慢的那一帧，需要framework层和app层一起配合改动，目前已申请了专利但代码还没进，将来有时间了应该会进到MIUI。感兴趣的可以看看专利：。===============================================================最后我来用专业技术分析一下微博app在Android里掉帧的原因。非编程人员可以跳过。（这个过程我使用的是小米3高通版+最新版微博app。）最初，我认为这种现象很像GC（垃圾回收）导致的，于是打开logcat观察每次卡顿的时候有没有GC发生。结果发现并没有。停下来的时候才会有GC，这说明微博app在滑动过程中控制得不错，在停下来的一刻才去分配内存，使GC不影响帧率。然后我打开“开发者选项”-&“GPU呈现模式分析”-&“在屏幕上显示为条形图”（好像是4.4才有这个选项，之前的只能在dumpsys里看），这会在屏幕上直观的显示每帧绘制花费的时间。屏幕上有条基准线大概是16ms，如果超过这条线则很有可能掉帧了。如果下面的蓝色部分很长则说明是软件draw的部分太费时，那么可以通过traceview来继续分析draw的java代码。（我假定了现在的app都是硬件加速的方式。）如果中间红色部分很长则说明是OpenGL ES绘制过程太费时。可以用gltrace来分析OpenGL ES的调用过程。打开选项后使用微博app，发现虽然偶尔有超基准线，但并不严重，并且卡顿的时候并没有明显异常。于是我开始使用systrace，这下就很明显了：可以发现每隔几帧，就会有一次大间隙，图中我圈了红圈圈的两个地方都明显超过正常的耗时时间。现在问题是，这些地方的代码在干什么呢？是什么花费了这么长时间？可以发现每隔几帧，就会有一次大间隙，图中我圈了红圈圈的两个地方都明显超过正常的耗时时间。现在问题是，这些地方的代码在干什么呢？是什么花费了这么长时间？放大后发现都是这两个：obtainView和setupListItem。它们都是在draw之前调用的，这也解释了通过上一步的方法（“GPU呈现模式分析”）为什么没有显示出来，因为那个方法只展示draw里面的时间消耗。放大后发现都是这两个：obtainView和setupListItem。它们都是在draw之前调用的，这也解释了通过上一步的方法（“GPU呈现模式分析”）为什么没有显示出来，因为那个方法只展示draw里面的时间消耗。通过在源码里搜索obtainView和setupListItem，可以发现是AbsListView的obtainView方法和ListView的setupChild方法打下的这个log。接下来，我们用traceview来看看这两个方法里面究竟调用了什么代码导致耗时过长。跟踪obtainView最终到了这里：代码混淆了，看不太出来了，也懒得再跟下去了。但随便点了点然后看到：代码混淆了，看不太出来了，也懒得再跟下去了。但随便点了点然后看到：TextView.setText用了挺多的时间。感觉Android团队应该优化优化这个方法。TextView.setText用了挺多的时间。感觉Android团队应该优化优化这个方法。然后再来跟踪setupChild方法：都是measure占用的时间，并且调用次数比较多。这应该说明了View的数量不少。用hierarchyviewer看了下，的确不少，一条微博有50多个View：都是measure占用的时间，并且调用次数比较多。这应该说明了View的数量不少。用hierarchyviewer看了下，的确不少，一条微博有50多个View：结论：我们最终大致找到了耗时的代码及部分原因。这两个耗时方法应该都是有可能减下来的，但应该不那么容易。===============================================================具体问题分析完了，这里讲讲整体Android的流畅问题。先聊聊目前最高票数的答案 邑封：。总的来讲，前面的内容都没问题：Android从最初就对Window级别的动画用了硬件加速（在SurfaceFlinger用OpenGL ES绘制）。3.0开始View也可用硬件加速来绘制。随后这个答案里说多个窗口的不同进程中的GL上下文切换代价很高。首先，现在的GPU一般都有MMU，可以方便的切换上下文。其次，大部分的情况下，Android都只有一个需要GL绘制的窗口，就是当前使用的app窗口。其他显示的窗口如状态栏，在没有内容更新的时候是不需要绘制的，SurfaceFlinger上已经存储着上一次绘制的结果。答案里提到了窗口内容“最后的组合”，这个是每帧都要做的，只是，SurfaceFlinger在大部分情况下是用的Hardware Composer以overlay的方式来合成的，并不需要OpenGL ES，在不满足Hardware Composer合成条件的情况下才会用OpenGL ES合成。Hardware Composer比OpenGL ES的方式性能更好、耗电更低。（我们有过测试，我们的数据是耗电大概少20%）。这里再说一下究竟哪些情况是可以用Hardware Composer来合成的，Android对厂商的建议是有虚拟键的应支持4层合成（常规的桌面：壁纸+桌面+状态栏+虚拟键），没有虚拟键的是3层。这可以看出在桌面上放一个第三方app的悬浮窗口对性能及耗电是有不小影响的。随后答案提到渲染2.5次的数据。是的，我曾在某Google工作人员博客或是官方文档里看到这样的说法，建议我们每个窗口渲染的像素数不要超过窗口大小的2.5倍。于是我写了个程序测试每帧绘制全屏图片N次时的帧率。测试程序：源码：大家都可以下载这个程序测试自己手机的表现结果。主要测试像素渲染性能、纹理加载性能。（点击“开始测试”后，中间的数字是最近1秒绘制的帧数，通常越大越好。）我的测试结果是在米2上可以绘制18次全屏图像仍然满帧率。在米4上绘制21次仍然是满帧率。可以看到现在的GPU渲染性能是非常好的。单纯的渲染像素数量不会是瓶颈。（当然，可以的话还是渲染内容越少越好。）最后答案说：后台程序优先级低，它们满打满算也无法占用超过 10% 的 CPU 资源。于是我又写了个测试程序：源码：（点击“启动线程”后按HOME键退出，看其他app是否使用流畅。按Back退出也行，不过会有内存泄露。）测试结果发现后台进程的CPU占用的确被限制了，对其他app的UI流畅性影响很小。不过可惜，Android的设计一直是本着开放的态度，它允许我们自己把自己声明为前台进程（测试程序中点击“启动前台服务”），虽然被切换到后台了，可还是按前台进程来对待。经测试，这时候其他app的界面卡得一塌糊涂。桌面滑动非常卡。顺便说一下，这种把自己声明为前台进程的程序，第三方app没ROOT的话是杀不死它的。在MIUI里，则可以被“最近任务”界面的上划图标或一键清理给杀死的。（想到了MIUI 6安全中心的一句台词：系统级的安全）对于Android系统的流畅性，Android确实为之做了很多努力，如：窗口级动画早就是硬件加速，Android3.0开始View级绘制也支持硬件加速，Android4.1使用VSync和3缓冲，SurfaceFlinger的overlay机制，等等。但Android的坑也很多：垃圾回收时会暂停所有线程，碰到几乎必然卡帧。（最近改善：4.4允许图片在不同大小时重用；ART改善垃圾回收。）上面说了渲染像素是非常快的，可是纹理加载则是非常慢的。上面提到米2可以绘制18次全屏图像保持满帧率，可如果每帧都修改则只能承受一张的全屏图像，当有2张全屏图像每帧都修改的话就达不到满帧率了。（测试程序选上“每帧修改图片”可以测试这个。）基于这个原因，频繁修改的软件层View慎用。设置View的alpha会导致每次发生离屏缓冲。（最近改善：大概是4.2开始可以设置为alpha不导致离屏缓冲）Canvas的saveLayer不加CLIP_TO_LAYER_SAVE_FLAG则会有个Texture Copy方法非常耗时。某些情况下设置alpha等也会碰到。某些情况下碰到quickReject失效时会尝试绘制不在屏幕上的元素。等等。总之，在Android上实现功能比较容易，但如果默认实现有了性能问题，要想解决就不好说了，有时候要绕很远，有时候甚至绕不过去。===============================================================注：第一个测试程序里“图片数量”大于一定值（我的米2是13）的时候帧率会大幅降低，这是因为超过了纹理缓存最大值。相关链接：Android图形架构（绘图慢一帧的事情这里有说）：Android Performance Case Study：
我是来告诉暂时排名第一的
，数据陈旧是要不得的。具体看原文：觉得不跟手是屏幕响应时间问题为主还是软件优化问题为主，应该可以判断了。
=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=写了这个回答，是为了指明当时排第一的
的回答中，作为论据的客观测试数据太过陈旧，无法支撑其论点。那时
的答案在众多不带思考的赞同下扶摇直上，甩所有答案一大截，我觉得对大家的误导过大所以写了这个没有真正回答题主问题本身的回答。就问题本身而言，推荐各位看
其实我觉得最主要还是开发者对于应用的优化不够，太多的Overdraw和Layout方面的问题，Android开发者本身为了适配屏幕分辨率和解决其他一些兼容性问题已经耗费很多精力了，很少有开发者会花很多精力去做细致的性能优化，有的甚至连优化的方向都不知道。现在的官方微博客户端要我看在Overdraw方面还是很严重，然后在异步加载图片的时候帧率也不够稳定，算不上流畅。再则由于Android平台本身机能没有强大到优化烂的应用也能跑的非常流畅暴露了优化不够的事实，特别是手机厂商的定制ROM相比原生系统都一定程度牺牲了一些流畅性导致这个问题显露的更加明显，所以在Android上面作出流畅的应用要付出比iOS更多的精力。其实Google这些年一直在系统层面作出努力提升系统的UI性能，从硬件加速到Project Butter到Reorder&Merge绘图操作等等，但是我感觉Google对于Android开发最佳实战宣传不够，国内有多少开发者上Youtube看过I/O大会上面的Android Session？几乎每年都有讲关于系统图形性能方面的Session。所以这里面也有国内开发者开发水平和眼界的问题。综上所述：一是受限于Android平台本身性能不够强大做出相同流畅度的应用比iOS更加困难，二是国内开发者对于Android开发性能优化方面的最佳实践知之甚少。update：某些答案中说屏幕触摸反应速度是影响流畅度最大问题的回答并不靠谱。我本身是做Android应用程序开发的，我举一个例子就能质疑这个结论：为什么原生系统（比如运行Android4.4的Nexus5）上面自带的App能运行得丝般顺滑而第3方开发的应用（特别是国内应用）就普遍比较卡？他们的运行环境是一样的吧？屏幕也是一样的吧？为什么流畅度就硬是差一些呢？原因就是SystemApp是Google开发的，他们的开发人员了解如何做出性能优秀的应用，了解Andorid开发的最佳实践。而第3方的开发者水平参差不齐，优化经验不如Google开发人员，导致写出的应用运行效率也不如SystemApp，站在同一个系统和运行环境里面讲，这就是最主要的原因。 上面的一些测试，能反映的最多也只是当手指触摸到屏幕的那个瞬态反应的延迟，并不能完全说明Android不如iOS流畅的原因。我觉得流畅性主要表现再2个方面：一个是触摸反应延迟，一个是渲染的帧率，而且后一个的重要性更大。可以想象一下从手指开始触摸屏幕到UI开始滑动的那100ms的延迟给你造成的不流畅感觉大，还是在滑动过程中不稳定帧率造成的卡顿感觉大？其实Google这些年的Android版本更新也一直致力于改善屏幕触摸延迟(找了个4.4的更新介绍有兴趣的可以看看：)，虽然可能还是比不上iOS，但是我觉得在这方面的差距已经很微小，带来的感受上的差异也是很微妙不容察觉。更多的不流畅性还是体现在优化烂的应用运行不稳定的帧率上面，比如在某个瞬态后台线程异步加载图片完成后在UI进程执行某个callback方法要显示，如果图片太大就需要根据ScaleType实时缩放到适合的尺寸显示到ImageView上面,这个时候如果图片太大缩放操作时间太长就有可能造成主线程阻塞较长时间，影响了系统UI进程在单位时间片内的渲染，导致掉帧。我再举一个例子也能反驳屏幕触摸反应速度是影响流畅度最大问题的观点：为什么在滑动显示单行文字的列表项一般不会觉得卡，而显示比较复杂布局的列表项（如微博）会比较卡？他们的屏幕和运行环境是一样的吧？触摸延迟都存在吧？为什么呢？这是由于列表项的布局过于复杂，UI控件在整个绘制的过程中(onMeasure()测量大小-&onLayout()分配位置-&onDraw()绘制)会花费更多的时间，比如各UI控件之间的相对位置和大小可能是互相影响的，这就导致在渲染每一帧的时候需要更多的时间来计算大小和确定位置，然后绘制阶段也需要多执行一些绘图操作来画完所有的UI控件。面对复杂的界面，有经验的开发者会尽量去避免界面的Overdraw(过渡绘制),减少UI层级，选用性能更好的ViewGroup(比如FrameLayout性能比LinearLayout好，LinearLayout性能比RelativeLayout性能好，但是布局能力最强大适应性最好的是RelativeLayout,在功能实现和性能优化中平衡达到最优需要经验)，避免图片实时缩放，避免在调用频繁的关键的路径创建对象减少gc频率，合理的管理Bitmap大对象（LruCache）等等（当然还有其他一些优化技巧不在此一一列举了）。还有讲什么进程优先级问题的答案说的也不是最主要的原因，Android的UI渲染进程的优先级可能不是最高但也是比较高的，不会说他UI渲染优先级设置到比后台线程还低的情况，这点不用过度讨论，Google也没蠢到那种地步，不服自己去看Android SDK源代码。我不否认屏幕触摸延迟也是造成Android滑动感觉不流畅的原因之一，但是站在一个开发者看到的角度来讲，我觉得在现有Android最新版本的系统优化下，他的影响远没有应用优化烂带来的影响大，优化好的Android应用跑在最新的Android版本上基本可以运行的跟iOS应用一样流畅。
我所知道的有两方面问题：1、Android是个设计比较现代的系统，所有程序都运行在独立的沙盒中，以保证安全性和系统的稳定性。比如我现在在打字这个屏幕中，显示着状态栏这个程序，知乎这个程序以及虚拟键盘这个程序。用户看到的每个界面都是系统把所有需要显示的程序的界面合成之后呈现的。这个过程比传统操作系统复杂，因此延迟较高，而且早期手机GPU还不支持多目标2D加速故不能有效地使用GPU，因此卡顿。即使到4.4的今天，动画帧数仍然是个话题，所以屏幕合成还是比较消耗性能的。这一点
的答案比较准确详实2、Dalvik VM的垃圾回收存在卡顿现象，而Android单个进程允许的内存比较小，所以滚动列表需要不停地释放内存和加载新内容，也就格外容易感到卡。ART显著降低垃圾回收内存消耗，应该是值得期待的。WP对程序内存使用也有较多限制，所以有各种“加载中”，并且早期列表滚动很卡。
Draco Leo:
你们只看到了开发者，忽视了手机。大多数手机的屏幕调教决定了不可能跟手。不信去开发者选项勾选显示触摸操作，然后快速在屏幕上乱画，你看那个圆点的运动轨迹。大多数都不跟手。这种手机应用再好也会有影响的。
试了一下，iOS和Android下上下拖动网页感觉不出来明显的不同，倒是两指缩放，iOS明显要快一些，能达到跟手的频率至少比Android高1/2。不过还是要看不同的应用的，应用写不好怎么都白搭，比如最近搜狐视频iOS客户端就卡得要命，每次点击都需要2分钟的时间才有反应。
pinkman jesse:
iOS优先反应屏幕，Android优先处理程序框架
晚上看文档看到一点东西，供参考。原网址：The key to a smoothly scrolling
is to keep the application’s main thread (the UI thread) free from heavy processing. Ensure you do any disk access, network access, or SQL access in a separate thread. To test the status of your app, you can enable .======================================================================对于不跟手的现象，我觉得是因为触摸屏响应慢了点，不是有测试说iPhone的触摸屏响应速度最快么？对于流畅，我觉得与GPU渲染有关，我手上的手机是Moto G，运行Android 4.4.4，GPU渲染是开着的，使用知乎客户端的时候，怎么滚动，都是流畅的，还有一台电信送的华为机，GPU渲染没有开，使用知乎客户端时，上下滚动会有卡顿。
不鳥萬如一:
這不是性能問題，是設計問題。「跟手」和「流暢」不是可測量的參數，而是人的心理感覺。光看觸屏響應時間不能說明哪個更流暢，正如 1300 萬像素的攝像頭拍出的照片不一定比 800 萬像素的攝像頭好。
咱觉得这版微博优化还行，硬件加速、图片延迟加载都有，我手边三年前的机器都能跑到满帧。题主可以去下个 FPS Meter（测帧数的，需要 ROOT 权限，MIUI 需要允许悬浮窗），然后再去刷你的微博，滚动时右上角接近 60FPS 的话， 的答案就很可能是最符合你的提问的 —— 问题在于手机屏幕调教，而不在 App 开发者。其实只要是触屏，都肯定会有轻微的延迟。可以尝试在开发者选项里把「显示触摸操作」打开，然后手指在屏幕上画圈，不需要很快 —— 如果完全没有延迟的话，圆点就应该可以一直被手指遮住 —— 但实际上，无论是什么 Android 设备，一定可以看得到指示触摸的圆点。以及，在满帧情况下的这种「滑动不跟手」，还有可能是软件本身就是这么设计的滚动算法 —— 比如有几个版本的 Sense 里自带相册的缩放和滑动都不跟手得很夸张；比如在 GO 桌面的设置里，你可以把滑动速度调到最慢，就会发现虽然流畅依旧，但明显不跟手；又比如 Wacom 的「卷动」，也是可以按个人喜好，使滚动视图完全不跟手（更快或者更慢）。对于电容屏而言，屏幕采集到手的「轨迹」，其实是一系列连续的点。如果在 Android 的开发者选项里打开「指针位置」，快速地在屏幕上划一下（划完后手指离开屏幕），在末端会看到有轨迹不止一条：蓝色那个就是屏幕采集的实际轨迹（可以看到是几个点连接成的），紫色的是推算的「手指离开屏幕」过程的平滑轨迹。// （由于看不出轨迹随时间的变化过程，这个并不能解释滚动视图不跟手的现象。）显然，无论是哪个次元的算法，不经过几个采集周期，就无法得到红色的平滑曲线。滚动要做到平滑流畅，也是要对多个采集点上的速度做平均，所以某种意义上，完全的「跟手」是不存在的 —— 只不过是 iOS 设备的软硬件都足够优秀，这一过程处理得足以让人的感官认为是「跟手」的。类似这样的「考虑到硬件采集的触摸轨迹本身不平滑，于是延迟一段时间来算平滑轨迹」的设计还有——
你手指一接触iPhone屏幕，内存基本就让给了UI，再加上单线程能力极强的A6、A7，无比流畅的感觉就产生了 。
硬件：iPhone的屏幕响应速度比绝大多数Android手机都要快应用：由于Android对第三方应用限制宽松，一些应用使用了非官方控件，代码优化不好会严重影响反应速度。这方面国产应用最多系统：Android手机厂商大都对系统进行了定制，如果只是改改颜色、按钮样式对应用影响不大，但很多定制ROM会改变一些系统底层文件，从而影响第三方应用运行，比如smartbar。版本：Android手机有多个版本分布，虽然Google play services能为低版本系统提供最新API支持，但国内手机大都不带Google apps，新版本应用对低版本系统的支持度肯定不好。说这么多，其实我想说的是，手机硬件发展到今天，除非你买了个四五百块钱的Android手机，不然流畅性已经不会影响你使用Android手机的体验了，普通用户也感觉不出来那几十毫秒差别的响应速度。
额，回答好多人啊，看来我程序员屌丝大军还是很可观的。回答一下吧，你的旗舰机的分辨率不知道要比10年的小苹果大多少了，一点可比性都没有。虽然代码效率有一定关系，但主要还是分辨率。
我认为肯定跟硬件有关系！在我的ZTE V880上玩飞机大战时，飞机跟手非常快速流畅，和iPhone同等级，而在MX3上的时候，跟手明显慢半拍。
这是应用设计水平问题。Android里面什么渣应用都能过审核都能上架，所以开发商通常不自觉的降低了对Android应用性能的优化。实际上只要用心优化，Android应用一样可以很跟手，只不过大多数产商没动力做而已。亲儿子装google原生应用是很称手的，一部分对Android很认真的开发者也开发出了在Android下体验很好的应用。…………只不过这些开发者一般就没怎么在意iOS版本而已。开发者的能力是有限的，倾向性是明显的，ios版做得好的应用，Android版本经常不认真做，而Android版做得好的应用，iOS版很可能没有或者很简陋。
Van Bruce:
iOS解决卡顿问题的两大绝技：一个是延长动画时间，让人感觉如德芙般丝滑的同时忘记其实是个Loading过程，只不过比Android的转圈圈processbar好看多了。另一个就是切回程序时先显示上次退出的截图，偷偷再加载程序，让人觉得卧草好屌啊瞬间秒开有木有！
因为题主的Android手机太渣了。Nexus4用了一年多依旧流畅
我自己用的nexus5，很流畅，微博这个软件就可以看出，用weico和fuubo很流畅，Google+更是如此，但是换成官方的，呵呵。所以我觉得还是app不用心和一些第三方rom自带软件太多导致的
举个相机的例子，ip的相机点击对焦后，屏幕上很快出现对焦的符号，但是对焦声音却是在后面，说明什么，说明ip为了让人感觉良好做了点小动作，至于这样做好不好，不好说，强迫症患者估计不会这么认为。
Federico Mo:
更新：请说某某比某某卡的，某某比某某流畅的，仔细看看问题，继续纠缠流畅的，直接拉黑。继续纠缠流畅的，直接拉黑。————————————————————这不是嘴里说说是“应用水平设计问题”就一定是“应用水平设计问题”的。首先看一段视频，iPhone 4（2010年）与Nexus 4的（2012年）的scroll test。抱歉没有找到更新机型的用高速摄影机拍摄然后慢速回放的对比。youtube原地址优酷地址（密码123456）
Nexus 4 vs iPhone 4 Scroll test
http://v.youku.com/v_show/id_XNzQzMzgwNDc2.html
明显可以看出，从手开始上下滑动到页面开始滚动，Nexus 4上手指移动的距离更大，比iPhone 4晚一拍。这就是楼主说的不跟手现象。这是主观感受。再来看看客观测试是不是与主观感受一致。请看和可以看出，即使是2010年的iPhone 4，也比2013年的Android和Windows Phone旗舰机屏幕反应速度快，而iPhone 5更是快了1.5倍。iPad mini和iPad 4，更是比Nexus 7 2013版快了1.5至近2倍。可以看出，即使是2010年的iPhone 4，也比2013年的Android和Windows Phone旗舰机屏幕反应速度快，而iPhone 5更是快了1.5倍。iPad mini和iPad 4，更是比Nexus 7 2013版快了1.5至近2倍。关于为什么更快，该网站给出的原因可能有两个：Apple’s touchscreen hardware is better optimized or more sensitively calibrated for capturing and processing touch. 苹果对触摸屏的优化更高，对于捕捉和处理触摸更敏感。While the Android and WP8 code are running on runtimes (Dalvik and CLR respectively), the iPhone code is written in closer-to-the-metal Objective-C, which may reduce some latency. 虚拟机和更接近底层原生的对比。不管原因如何，给消费者的体验就是“the best written apps on iPhones will simply feel more responsive than similar apps on the current gen of Android devices”，相似的app（前提是编写良好）在iPhone上的表现就会比在Android机器上更灵敏。
不请自来尼玛看错了……原来问的是屏幕反应……害得我打了几百字又删掉……用的是手机啊！1 因为安卓的屏幕反应机制是 Application--Framework--Library--Kernal 其中 library才涉及到屏幕，再来看看ios呢 Touch--Media--Service--Core 我去！ 只要你触摸了就立马给反应……真是机智！2 ios这货用的是GPU加速，就是说平常的什么过度啦动画啦光影啦这些都是gpu的工作，而我们的傲娇CPU就可以专心致志的响应用户的操作了～随时随地～ 苦逼安卓——什么都是CPU来，gpu表示游戏的时候才会用到——平时闲的X疼……3 Android的编程语言是JAVA，而iOS的则为Objective-C。Objective-C的优势是效率高但比较“唯一”，而JAVA的优势则是跨平台不过运行效率相对偏低，其实这两个编程语言所带来的机制不同，就已经造成了各自系统之间的流畅性差异化。这才是根本原因！ 这也是为什么iOS封闭，安卓开放的根本原因。4 APP的质量 Apple的手机一年不过两三部，开发者们有大把时间来进行开发，优化，适配，而且苹果官方也会提供帮助。来看看安卓……卧槽印传单吗一周几部手机！ 如此快的速度开发者们根本没时间来进行优化好不好！╮(╯▽╰)╭答完了，手机码字果然好累T^Tupdate
知乎里的人……好可怕……被找到好多问题，我是不是应该把这个答案删了免得误导别人呐？
请不要拿 Nexus 系列以外的机器来跟 iPhone 对比。还有题目是 iPhone 跟 Android 比？为什么不是 iOS 跟 Android 比？
感觉是系统的问题。iOS中滑动用的是UIScrollView的子类，苹果给UIScrollView提供的API也没有可以让开发者自己控制响应时间和滚动速度的…而且，引入了ARC后开发者也不太需要关心内存释放什么的…在Xcode里建一个空的模版，让它视图是scrollView，初始化后其它各种属性值不去设置，delegate也不设置（就是除了初始化后啥都不干），然后放机器上跑，上下滑动照样好好的。而且关于触摸响应（UITouch，UIResponder）以及手势（gesture）苹果封装的比较好，开发者自己基本不需要再做修改，除非有特别的需要才去自己写一些和相对底层一点的东西打交道的类。所以并不觉得是开发者的问题，或者说，大部分还是系统的原因吧。--------------------------------------------在做iOS开发，自己用的iOS系统。所以只能单方面从iOS的角度来说。偶尔也玩下安卓（同学的），也感觉到了滑动某些时候的问题。
硬件上说一条很关键的，iOS设备的CPU单线程性能对Android设备真是默秒全
用一点点个人感觉作答1 部分受限于系统机制IOS不开放，所以不大清楚IOS的底层机制很难用IOS和安卓进行比较。但原生APP和安卓基于JVM的差异还是很显然的。前阵子编译过安卓4.3的系统，在较高性能的PC上足足用了数个小时。这是我接触过的所有嵌入式系统中耗时最长的。过去不论是编译Windows还是Linux系统都没能让我产生这种无法忍受的感觉。当然系统并未经过裁剪和适配。在机制上，安卓和过去的Linux内核+J2ME扩展应用的模式并没有太大的区别。这种模式降低了应用开发的门槛，丰富了应用数量，但是确实难以在运行效率上有所作为。而引入图形硬件加速，堆硬件等做法，跟过去用硬件加速J2ME程序又有什么区别呢。当年搞不好的事情现在又怎么能搞好。2 图形界面构架或尚有待完善前面也有答友提到了与GUI的有关的部分。确实图形界面的构架也会大大影响程序运行的流畅度。可以说一旦加入了GUI，用户交互会变得丰富，前后台处理会变得异常复杂。这本身就是一个非常难解决的问题。3 碎片化导致应用欠缺优化这个也不用多说了。再好的平台也需要应用开发者有针对性的优化。
FelixWong:
机器问题，请用Nexus5测试
就iOS、安卓两大终端触控等级分析：iOS面板触控等级是系统等级权限第二高的等级，即L2，而安卓面板触控等级是L3，这是iOS比安卓流畅的原因之一。
现在主要是应用优化不够，系统问题不大。
这是两个系统对触摸屏的优先级先后差异造成的。iphone的屏幕或者是说ios系统认为手指触摸屏幕拥有很高的优先级，系统会先执行一些操作来响应你的滑动屏幕这一操作。而安卓系统把这一行为优先级放的很低，你用手指触摸了屏幕，系统却先做别的事情，然后再来进行屏幕的变化。当然，还有其他方面的原因。具体参见这里讲的比较好。你可以看看，我觉得很有道理。
回答里里关于什么苹果触控响应级比Android高的回答无非是照搬几年前一个文或者随便看了Android的入门资料就发言，一点帮助没有。========================================其实楼主这个问题是问的android的绘图响应速度怎么有点慢，而不是流畅性。虽然程序写不好也会导致响应慢，不过这种我们先不提。关于设备响应速度的已经有人发过数据了，所以我也不说这个话题了，我想简单说说我所知道的在系统层面影响流畅性的问题。一个是如所说的硬件加速的关系，很多现在流畅的应用你关掉硬件加速一样很不流畅。一个是WebView的问题，不少应用其实是H5写的套在WebView的壳子里，但是过去Android的WebView不够好，各方面表现都不如iOS上的Safari内核的WebView。Android的WebView的内核直到API19才换成了Chromium，但是表现如何还不清楚。还有一个是GC的问题。流畅性其实就是绘图要有足够的帧率，android在4.1以后绘图帧率提高到了60fps，但是这个在当时有一个问题还是没完全解决，就是垃圾回收。android是使用java语言编程的，无论是过去的dalvik还是以后的art都是使用主动垃圾回收机制的，GC线程会扫描内存把从根节点不可达的对象回收掉。然而在2.x时代，GC线程是不支持并发的，GC进行时会挂起虚拟机的其他线程，标记垃圾并进行回收。GC的标记和回收过程占据了几十到上百ms，挂起其他线程时就会造成UI绘图动作的中断，也就形成了掉帧。这是2.x时代android卡的一个原因。到了4.x，GC线程是部分并发的，只有在标记时才会挂起其他线程，标记的过程极短，这样显著改善了掉帧。然而编写不良的应用频繁触发gc仍然会让系统变得响应缓慢。到了Android L，ART声称完全解决了这个问题，GC是完全并发的。
先把你在街边贴的1角成本“保护膜”撕掉再说。还不行的话，用你买iphoe的钱买一个同价位的wp或安卓。上面提到的回答的响应等级有道理------------有种你别updata啊------------我最讨厌的就是你这种人，和我那那个《岗位认知》课却在说自己是用了mbr做的ppt然后同学们来看看苹果的文化通篇没说过岗位二字却让我写了个课后感想然后我说不知道岗位认知是什么直接让我挂科的讲师一副吊样！-----------------------------
songbird44:
NEXUS 5 已经没有这问题了,买了半年多了,装了一堆app,还是没有迟延现象,想当年nexus s 装4.0系统 卡成狗
是系统问题，在系统设计的取舍上，ios选择优先响应屏幕事件，andorid则机制更复杂所以屏幕响应不是最高优先级的。
浏览过全部答案和评论，我只是发现一个很好玩的现象开发者基本都承认是系统问题。系统优先度，和API调用处理都不一样。即使是直接调用系统API完成的应用，也跟IOS相差一些。请问我该怎么优化？然而回答被反对。而使用者大多指责说是开发者的问题，优化不够，市场不对，或者价格问题。对于说市场的，别把谷歌商店吹的太神了。我就想指教一件事，同样是QQ在google appstore下载跟我在豌豆荚下载有什么区别么？
你用过nexus5（注意开art模式），你就没有这个感觉了。我用了art之后，除了5s和5，别的我都觉得不够流畅。nexus5绝对性价比神器。期待4.4.4以后的L
滑动机制不同，ios是阻尼滑动，安卓是匀速滑动，如果这算不流畅的话，电脑上的windows也不如ios流畅
作为一个外行，我只想说在价格区间相同的手机相比较才有可比性。5000的ios就该跟5000的android比。我个人觉得，5000以上的安卓手机触控不滑顺的感觉不明显啊。
你随便拿款旗舰安卓机器，选个安卓原生控件的应用再试试，你会发现流畅度丝毫不输 iPhone 5s原因是采用非原生控件的安卓应用重绘 UI 消耗了大量的 GPU 资源，再加上原本安卓旗舰的GPU配置就赶不上 iPhone 5s（毕竟苹果把双核 A7 做的比人家四核骁龙还大），所以导致用于滑动动画的 GPU 资源减少，所以才显得卡顿。
就是个代码水平的问题，iOS的App也有一划就卡的要死的。代码优化过之后Android的App也可以非常流畅，你可以试试Google的原生应用和国外那些知名的Android应用，用着都很舒服。国内厂商只是懒，又舍不得花钱花精力罢了。
牛奶不好喝:
都没有德芙的牛奶巧克力顺滑…
因为苹果操作是触控优先，只要当你手指触控屏幕开始，它的所有后台程序都暂停运作，把所有资源给指尖。而安卓系统是一直任何时间都带有后台程序，所以触控资源被分拨。苹果之所以可以这样做因为它是软硬自己设计，软件能更好的让硬件为他工作。而安卓系统面对的是多硬件平台，当然配合上不如苹果的匹配
做过两年手机研发人员，iOS和安卓都用过，说说我对这个问题的理解吧。我做研发的时候是07到09年，当时正好参与了一个在我们的开发平台上添加一个touch功能的项目，我们用的是典型的2.5G模拟平台，原本只支持按键操作。其实当时底层硬件能够提供相应的接口，包括长短按，拖拉等简单动作。但说拖拉的动作，也就是题主说的屏幕滚动其实一行代码就实现出来了，但是想要让画面滚动和手指操作协调跟手，这就需要大量的研究和试验积累了，例如手指接触屏幕速度加速度的捕捉，以及窗口滚动的速度加速度距离等等，还需要根据硬件的渲染方式特征等对动作进行优化。我记得当时就做一个让屏幕上的图标从中间发散出来呈现的动画就调了很久仅仅为了使其看起来自然一点，对于一个没有相关技术积累的公司来说这个难度是十分大的。我猜苹果应该是凭借多年在动画，MMI方面的技术积累以及软硬件结合的巨大优势才做的这么好的。说到软硬件结合各位可以去华强北看看一些500到1000块的山寨安卓机器，论硬件其实已经很OK了，同样运行安卓系统，那屏幕滚动效果跟同价位品牌机器还有巨大差别。简单说，手机屏幕上每个动画每个效果其实背后都有诸多的算法理论支撑，不同系统虽然展现方面相似但诸如动作速度加速度幅度等等参数的精确设计以及其与硬件配合的优化调整都不尽相同，这个是造成体验差别的重要原因。
其实就是系统架构的问题啊。安卓越来越成熟，现在N5一样流畅了。另外苹果的gpu 比安卓更强大，所以在针对界面图画反应速度更优秀。不是屏幕材质的原因。
从非技术角度来说下，只讲流畅，没注意滑动速率，ios对滑动最大速率做了限制，而android没有，同样的滑动，ios滑动距离明显没有android滑的远，滑动速率相对android低，所以ios感觉到的平滑度自然要好些。不信使劲滑动试试
其實主要的問題還是由於軟件廠商對於手機的優化，iPhone只有那麼幾款，優化的工程沒有Android那麼龐大，所以iOS平台的優化一直很好，體現在跟手，流暢。（固定分辨率也是一方面）Android手機廠商其實也是會對一些當下人們常用的幾款手機軟件進行針對性的優化（但限版本）一旦更新又會出現不跟手之類的老問題，像前一陣子Sony14年上半年的旗艦Z2就對微博，之類的熱門軟件進行優化，所以開始的版本非常跟手和流暢，再加上大屏和高分辨率帶來一種非常爽快，甚至超越iPhone客戶端的感覺，但更新了新版之後又出現了之前的問題，其實我個人感覺還是優化的問題與系統關係不大。
leeeeeeyc:
iOS和Android上的微博app不是一个app。在其他应用的操作中并不能发现上下翻动卡顿的现象。因此可以归结为微博app的个案。
是开发者问题。单纯比较安卓和IOS的流畅度，一定要用最新的nexus进行对比。然后你会发现单是‘’微博‘’这个应用流畅度是没差的。但是总体应用质量安卓是要比IOS差。
系统问题 android在界面上触摸感觉界面滑动很轻盈 这就是跟手 在android有点沉重 在系统自带的设置里就能感觉到 特别是在设置里的应用程序里 打开这个界面是会计算程序大小 需要大量读写存储器 不跟手更加明显 。android程序可以优化到不卡 但是还是比不上ios跟手 这是系统问题 多任务和ui处理优先级等原因造成的。
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动}