※ [本文转录自 nfsong 信箱] 作者: Freak1033 (金が信念! XD) 看板: Gossiping 标题: Re: [问卦] 为什麽HTC打不过IPHONE 时间: Wed Feb 16 12:10:08 2011 我认为你讲的一般而言还蛮正确的, 帮你补充几点. ※ 引述《Kenneth1225 ()》之铭言： : google一下就有规格了 : HTC Desire | iPhone4 : 上市时间 2010/5 | 2010/6 : CPU Qualcomm QSD8250 (Snapdragon) | Apple A4 : CPU Frequency 1 GHz | 1 GHz : L1 cache 32 KB | 32 KB Instruction+32KB Data : L2 cache 256 KB | 640 KB : RAM data bus 32 bit | 64 bit : GPU Adreno 200 | PowerVR SGX 535 : RAM 576MB | 512 MB 这边 Apple A4 列的时脉是跑在 iPad 上面的时候才是 1GHz, 在 iPhone4 上面它没有出全力在跑. 理由当然是为了省电, 可以跑更低的电压. 不过那个 640KB 的 L2 cache 是真的很恐怖, 不专业的乡民只会看时脉, 不过现在的 CPU 真的很大一部份是靠 L2 在吃饭. 一个经典的例子是 Core 2 Duo E8xx, E7xx, Pentium DC 以及 Celeron DC, 三者骨子里其实都是一样的东西, 就是差在 L2 是 6MB, 3MB, 2MB, 1MB 而已, 就可以差到左手边让 AMD 连车尾灯都看不见, 右手边被打左脸还要把右脸也赔上. : 使用Android的手机厂商的确是大杂烩 : 但iPhone也没你讲得如此封闭...当然原po讲的对了部分 : iPhone4上 Apple自己来的是CPU OS Application.... : 剩下的全部硬体 : GPU DRAM ROM 陀螺仪 Flash 通讯晶片...等等 : 全部都是别人的 : 当然你要说iPhone4因为Apple自己搞CPU跟OS 所以可以针对OS为CPU做最佳化 : 我不敢说不对 我不是做OS也不是搞CPU architecture的 : 所以也不懂该怎麽做optimization XD : 不过iPhone 3GS的CPU是samsung的....我是不知道iPhone 3GS是否因此而不流畅 我不太同意 Apple 的 CPU 是自己做的这个说法... 正确的说法是 SoC 是自己做的. 一颗 SoC 通常是包含一或多个 proceessor core 与许多的周边硬体组成, 这些周边硬体可能包含了 USB, SPI, I2C, UART bus controller 等等, 也可能包含了 power management, DAC, ADC, capacitive sensing 这些元件. 然而我想各位都会同意, 影响效能最大的还是那颗 processor core, 这个各家厂商都一样, 都是跟 ARM 买来的 Cortex-A8, 架构 ARMv7-A. 至於你说 optimization 喔, 基本上大多数的工程师根本不太 care, 在 Android 上面大多数都还是写 Java, 除非真的有效能瓶颈, 不然不会想写 native code. iOS 这边则是交给 XCode 决定一切, 通常也不会有什麽好结果, 真的要拚效能还是得自己写 NEON/VFP intrinsics. 基本是半斤八两. : 小弟我对iPhone跟OS都不算熟.... : 但是我想iPhone的流畅性应该是来自於Apple在OS上的贡献 : Apple从1976年就开始搞OS : 众所皆知的MAC OS则是在1984年诞生 : 更多的历史有兴趣的请参阅reference : Android由Andy Rubin在2003年创立 : 於2005年被google买走..... : 其以linux kernel为基础设计 : 光看年资就可以发现Apple在OS上的功力与历史 : 我与原po持不同的看法 : 我认为iPhone的流畅 并不是因为Apple搞了封闭的系统 : 并不是其他厂商搞了一个大杂烩 所以bug一堆 : 而是因为Apple对於搞OS实在太强了..... : 今天你拿iOS给其他厂商去开发application : 纵使跑了别家的硬体 我相信以Apple的功力 : 一样可以提供一个平稳的开发平台以供使用 : 别忘了OS的定义是什麽 : 恐龙本(第六版): an operation system is a program tha acts as an intermediary : between the user of a computer and the computer hardware. The purpose of an : operating system is to provide a environment in which a user can execute : programs in convenient and efficient manner : 给定了OS "上层"的程式开发者就不需要去管下面硬体是怎麽搞的 : 当然你说你的程式要动到driver....那你原则上就不算是个"上层"的程式开发者 : 以application的开发来看 "多半"不必动到那麽下层 : (我不想讲死 的确是有在OS上的程式要开socket去网卡或是其他层拿资料 : 只是这些多半在paper里出现 但是会动到这样通常不会叫自己是application : 这已经是system design 手机有没有这样的application 我就不清楚了) : 而前面提到的流畅度 多半是来自於application给使用者的观感 : 所以Android的慢真的来自於硬体的大杂烩吗? : 我想只是因为现在Android还没Apple他们搞得OS强罢了 : 另外一个重点则是原po也有提到的 : Apple一年搞一只 可以倾全手机部门之力为其设计 : 其他各家大厂 EX:HTC 每年都玩机海战术 : 想当然而品质便随之下降 : reference: http://en.wikipedia.org/wiki/Mac_OS : http://www.kernelthread.com/publications/appleoshistory// : 小弟才疏学浅 如有写错或不合理还请海函 : 并给予指正........................... 这边你有点过度简化问题了, 操作不顺, 也就是从操作到机器做出回应中间花的时间太长, 这中间有很多可能的原因, 从 1. capacitive sensor 侦测操作的时间 2. OS scheduler 给 UI thread 排程的时间 3. UI thread 本身回应操作的时间 三者皆有可能. 电容式触控这个东西原理其实很简单, 只要有基础的电子学知识就可以用铅笔跟胶布自己做一个, 我前阵子才自己在 mbed 上面做过. 困难的是侦测操作的演算法并不是非常容易, 你会到很多所有 sensor 都会遇到的问题: 1. noise, 原因有很多种, 从宇宙射线到天线效应到电路本身漏电都有可能 2. drift, 理由也很多, 比方说温差, 手指造成的压力形变, 材料氧化等等 要怎麽从 signal 跟 noise 中间只取出 signal 那就是讯号处里的范畴, 好的演算法可以用很短的 filter, 当然反应就会快, 坏的演算法可能 filter 很长, 反应慢, 要不然就是可能一天到晚误动作. 就这点而言, 我相信 Apple 一定选了市面上最好的 controller, 要不然也可能是自己做, 这就要请内部工程师报挂了. 另外 OS scheduler 这边卡了一段时间也很有可能. 一个好的系统应该要让前景的 UI thread 有额外的优先权, 而且当收到 user input 的时候要能够马上 preempt. 就这点而言, 我没摸过 Android 底层, iOS 则是想摸都摸不到, 所以我不知道他们做得怎样. 不过如果是 Windows 的话我就有八卦可以爆了, Windows 的设计是一个 thread 如果在等待输入装置, 如滑鼠键盘, 当事件一触发的时候就会马上被提升数个优先层级, 而且可以强制分到 2 个 tick 的 CPU 时间. 听不懂技术的乡民可以这麽理解, 就是回应使用者的执行绪会开无双就对了. 最後 application 本身的问题也很有可能, Android 3.0 之前的版本 UI rendering 是没有用 GPU 加速的: http://code.google.com/p/android/issues/detail?id=6914 所以不要说做特效了, 可能连个 menu 都来不及画完. 这点是 iOS 大胜, 也是被大多数人认为最重要的因素. 另外 Android 还有一个 Android 的原罪, 就是 kernel 用的 GPL 授权导致很多厂商不想把 driver 做在 kernel 里面, (因为会被强迫 open source) 所以他们想尽办法做出 user space 的 driver framework. 有些东西还好, 像是 PowerVR 的 driver 至少还是 in-process, 很多 audio driver 甚至还是 inter process, 每次传送资料还要进 kernel, 再 reschedule, 再回 kernel, 再回来, 效能会好才有鬼. --- : : 开放的Android机只要Bug除乾净就已经是神境了 : : 平板电脑上更是惨不忍睹，Android这个设计在手机上的OS硬改去平板上，还不成熟 : : 如果不算亚马逊的机，以能够兼智慧电脑用途的平板来说的话 : : 市面上除了iPad 之外，那些装 Android 的一窝蜂平板其实都还没有成熟，Bug飞天 : : 所以现在 iPad 是在屠宰平板市场 : : 以上是背景，而消费者看到的结果，就是在实机demo上看到的 : : 「Apple好顺，Android lag」 : : 这个体验只有一句话，但代表了很多，因为这就像打电玩时FPS的差别决定了很大的爽度 : : 在北美拥有大市占的RIM也是封闭系统的，蓝莓的机型也不多，系统自己搞 : : 一样是封闭系统路线，蓝莓的体验也是绝佳的，顺畅，速度超快，几乎不当机 : : ** 最终还是产品本身才是战场的关键 ** : : 产品本身是兵力，是实力，是硬道理，行销只是战术 : : 养出1000万大军，战术只要不太无脑都能轻松取胜 : : 当然当双方兵力相等时，战术就是关键 : : 但在现在的手机市场上，我不认为双方兵力相等，Apple的硬实力胜太多了 : : 说到潮不潮，其实也有关系，但并不是和赶流行的潮男潮女文青有关 : : 那些在拿在现的，都已经算是消费曲线里很後进的了 : : 所谓的潮流是在业界里面，主导潮流的人是大型软体开发商与数量庞大的中小型开发者 : : 因为开发者愿意开发 = APP 数量多 = 创意无限 = 消费者选择多 = 胜 : : 这个公式在一定条件内会成立，所以写程式的那一票流行往哪里倒，哪里就会是关键 : : 也就是宅中之宅的宅圣Geek是决定市场方向的人 : : 所以看都不用看就知道 WM7 和 nokia 稳死的 : : 因为Geek看到微软的第一句心里话就是「干你老师」 : : 鬼才会去帮微软写app 其实坦白说我也不觉得这篇文有什麽不对, 讲的都还挺正确的, 就是最後一段我不喜欢. Geek 不完全都是 Linux 或 Mac OS fanboy, 也不一定仇恨微软, 事实上身为一个专业宅男我就还蛮喜欢微软的. 另外就是你理解错 App 的生态了, 一流的 App, 我说的是会超过十万下载的那种, 通常都已经不是个人靠兴趣能做的了, 当你有了公司, 有员工要养, 有金主要负责, 谁还管你什麽个人喜好, 哪里有钱赚哪里就要做. 微软现在面临的大问题就是鸡生蛋蛋生鸡的问题, 如果没有人要买他家手机, 就没有人要帮他写 App, 没有 App 可以用, 消费者就更不想买. --- 顺便打一下广告, 这是我新开的小 blog, 最近刚好在写战 iPhone 跟 Android 的文章, 欢迎专业非专业乡民来讨论. wwwww http://blog.trchen.tw/2011/02/iphone-android.html -- 「ふ…ふざけるな！そんあ短い咒文で、魔法を起动できるわけないだろうが！ お前わマウゼルの神に逆らう气なのか？！傲慢な～」 「失礼致しました、诚实に全力でお相手致します。 第一战术级‧军用攻性魔法‧出よ、武雷神〈トール〉！」 〈スクラップド‧プリンセス〉 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.109.222.101 这很难讲, 我没玩过 Dalvik (Android 用的 Java VM) 我不知道效能怎样, 不过你可以多信任一下现在的 JIT 一些... 做得好的 JIT 不见得要比 native compiler 慢, 甚至可以更快! 其中理由是因为 JIT 可以看到一些 runtime 的资料来做最佳化, 比方说 virtual function 的提取它可以直接生成 native code. 这是 static compiler 做不到的. 相较之下, ObjC 的 object model... 我还真不觉得它能快到哪里. (它是完全 dynamic binding) 如果你不在乎未来, 只在乎现在哪一个平台比较好, 我会说 iPhone 是唯一选择. (当然啦, 还是要看个人喜好跟应用) 但是如果还得考虑未来性, 你要考虑你买了手机绝对不会只买手机, 你还会买 Apps, 然後你就会被它绑定了, 因为你以後不会想为了换平台而放弃已买的 Apps. 所以有没有押对宝很重要. (想当年我在 PHS 全盛的时候买了 J95, 结果一下兵败如山倒... QQ) 从现在的局面看来, 鹿死谁手还未可知, Android 的确成长得很快, 而且 Android 3.0 开始支援硬体加速, 以後会移植回 smartphone 版本, 这点很值得期待. ※ 编辑: Freak1033 来自: 140.109.222.101 (02/16 12:28) 好文章! 我会好好参考这些数字的. :p ※ 编辑: Freak1033 来自: 140.109.222.101 (02/16 12:41) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.161.49.103