大讨论: 手机硬件那么强，android为什么还那么容易卡(更新)
本帖最后由 mordorwww 于 2016-11-04 08:49 编辑本人搬砖码农一只，买不起苹果，用andriod而深受其害，因此，
诚邀内核以及android各路专家大牛来讨论如何解决此问题，以为民除害，造福亿万android穷人
"Mate 9带有华为自主开发的界面软件，它使用人工智能让Mate 9做到连续使用18个月，运行不卡顿。"
真有这么牛逼么？
我的P8和H3C卡成翔, 恨不得砸地上
好问题啊！请各位同行踊跃参与。我一些片面的看法。
第一，硬件真的很强大？cpu数目多，内存大就代表硬件好吗？瓶颈在哪里，这是很重要的细节。DDR带宽是否够，EMMC速度怎么样，很多广告之外的细节很重要。
第二，软件拖垮了硬件。android 本来就是用虚拟机的，多了一层 JVM 。性能打了折扣，再加上软件架构的设计问题，后台往往几十个程序在跑。手机当然吃不消了。加上手机需要考虑功耗，并不是所有的cpu都用最高频率跑的。也不是所有的cpu都会跑。 本帖最后由 mordorwww 于 2016-09-26 11:17 编辑
amarant 发表于 2016-09-26 10:31
好问题啊！请各位同行踊跃参与。我一些片面的看法。
第一，硬件真的很强大？cpu数目多，内存大就代表硬件 ...
"后台往往几十个程序在跑。手机当然吃不消了。加上手机需要考虑功耗，并不是所有的cpu都用最高频率跑的。也不是所有的cpu都会跑。"
我正是对这个很困惑
几十个程序不算什么，可能绝大部分都处在sleep和wait状态，根本不会影响你前台的UI操作
就算几十个程序在runing, 系统的调度会在1，200毫秒甚至几十毫秒内调度到处理UI的进程
手机的CPU每秒执行几亿条甚至几十亿条指令，linux对处理UI的进程和几十个后台进程进行均衡调度的话，根本就不存在CPU吃不消的问题，何况UI渲染都是用GPU
至于说为了省电8个核不是都在工作，如果说用户都在戳UI了，android不可能为了省电让八个核都休眠或者跑低频而不处理UI事件的，
八个核之间还有负载均衡，不可能说手机都卡了，你还有一堆的核在睡觉
一言蔽之，linux原本就是为多进程而设计的, 手机CPU的能力肯定是足够让手机能及时响应用户的UI操作了，即便是有很多后台进程再跑
回复 3# mordorwww
这里就有很多具体的技术细节了。
ARM在推big-LITTLE架构，推出了 EAS 调度器。这里本来就是一个很难的工作，什么时候上大核，什么时候上小核。调度器的tuning的情况，和UI的流畅程序相关性很大。
手机卡顿主要还是和workload相关，workload太多了，容易出现丢帧的现象。
十几个进程，还要看是什么样的进程。例如，就算你的PC这么强劲的性能，运行make -j32 都会卡的很。如果它们确实大部分时间都在 sleep，那么自然是好的。但是它们可能在做很多事情。
本帖最后由 mordorwww 于 2016-09-26 13:51 编辑
amarant 发表于 2016-09-26 13:15
回复 3# mordorwww
这里就有很多具体的技术细节了。
要这样讲双核单核的手机不会卡了？非big/little架构的android手机不卡了?说不通吧?
PC linux上make -j32 操作，系统并不会卡，虽然此时CPU 100%, IO也高，但是系统本身一点都不那么卡，
当然make操作本身可能需要较长时间才能完成，但是系统本身不那么卡
但是 android手机在卡的时候CPU/内存占用似乎都很低,100%根本谈不上，日常的应用什么APP会要burn你的CPU到100%
刚在PC linux上做的实验
Tasks: 371 total,34 running, 337 sleeping, 0 stopped, 0 zombie
%Cpu0: 97.8 us,2.2 sy,0.0 ni,0.0 id,0.0 wa,0.0 hi,0.0 si,0.0 st
%Cpu1: 90.9 us,9.1 sy,0.0 ni,0.0 id,0.0 wa,0.0 hi,0.0 si,0.0 st
%Cpu2: 75.6 us, 19.5 sy,0.0 ni,0.0 id,0.0 wa,0.0 hi,4.9 si,0.0 st
%Cpu3: 84.4 us, 15.6 sy,0.0 ni,0.0 id,0.0 wa,0.0 hi,0.0 si,0.0 st
KiB Mem: 1025476 total, 838304 used, 187172 free, 8912 buffers
KiB Swap:1045500 total, 267916 used, 777584 free. 144724 cached Mem
PID USER PRNI VIRT RES SHR S%CPU %MEM TIME+ COMMAND
7 root 20 0 0 0 0 S15.40.0 0:38.25 rcu_sched
28267 root 20 0 28140 9232 2432 R15.40.9 0:00.07 cc1
27673 root 20 0 5664443864 8024 R13.24.3 0:00.73 cc1
28142 root 20 0 3647619936 3916 R13.21.9 0:00.20 cc1
28145 root 20 0 4074424340 3916 R13.22.4 0:00.17 cc1
27398 root 20 0 5740444580 8160 R11.04.3 0:00.98 cc1
27724 root 20 0 4585233160 7988 R11.03.2 0:00.62 cc1
27725 root 20 0 4567233456 7788 R11.03.3 0:00.65 cc1
28019 root 20 0 3868426924 7916 R11.02.6 0:00.33 cc1
28082 root 20 0 4734032484 4996 R11.03.2 0:00.24 cc1
28105 root 20 0 3644420488 3916 R11.02.0 0:00.21 cc1
28158 root 20 0 3408017668 3904 R11.01.7 0:00.17 cc1
28175 root 20 0 3022012908 2432 R11.01.3 0:00.12 cc1
28206 root 20 0 2979213824 3888 R11.01.3 0:00.07 cc1
28207 root 20 0 2978413836 3892 R11.01.3 0:00.07 cc1
28227 root 20 0 3200014568 3892 R11.01.4 0:00.09 cc1
28238 root 20 0 2986412708 3888 R11.01.2 0:00.06 cc1
28279 root 20 0 25548 6804 2432 R11.00.7 0:00.05 cc1
27497 root 20 0 5491242576 8144 R 8.84.2 0:00.81 cc1
28095 root 20 0 4073624172 3924 R 8.82.4 0:00.18 cc1
28141 root 20 0 3634420024 4852 R 8.82.0 0:00.18 cc1
28211 root 20 0 28128 9504 2432 R 8.80.9 0:00.07 cc1
28242 root 20 0 2703610708 3876 R 8.81.0 0:00.06 cc1
28250 root 20 0 2762811944 3884 R 8.81.2 0:00.05 cc1
28253 root 20 0 2979212540 3888 R 8.81.2 0:00.06 cc1
28254 root 20 0 2977612752 3888 R 8.81.2 0:00.05 cc1
28289 root 20 0 24852 9148 3864 R 8.80.9 0:00.04 cc1
3003 root 20 0 11256 848 648 S 6.60.1 0:05.08 sshd
28163 root 20 0 6964 5192 480 R 6.60.5 0:00.08 genksyms
28193 root 20 0 5908 4140 480 S 6.60.4 0:00.04 genksyms
28264 root 20 0 5908 4140 480 S 6.60.4 0:00.03 genksyms
28282 root 20 0 24828 8124 3864 R 6.60.8 0:00.03 cc1
28276 root 20 0 3268 1496 480 S 2.20.1 0:00.01 genksyms
刚才在虚拟机上做的实验，物理机上make -j32系统真的是一点都不卡
top - 14:47:56 up 386 days, 53 min,3 users,load average: 29.15, 13.02, 5.99
Tasks: 299 total,34 running, 265 sleeping, 0 stopped, 0 zombie
Cpu(s): 93.4%us,6.6%sy,0.0%ni,0.0%id,0.0%wa,0.0%hi,0.0%si,0.0%st
Mem:10012132k total,7471756k used,2540376k free, 528120k buffers
Swap:5079032k total, 0k used,5079032k free,4879504k cached
PID USER PRNIVIRTRESSHR S %CPU %MEM TIME+COMMAND
18231 root 20 0187m71m 8104 R 12.20.7 0:00.84 cc1
18375 root 20 0173m57m 8280 R 12.20.6 0:00.65 cc1
18595 root 20 0159m44m 8088 R 12.20.5 0:00.43 cc1
15433 root 20 0271m 152m 8444 R 11.91.6 0:04.86 cc1
18162 root 20 0167m52m 8352 R 11.90.5 0:00.88 cc1
18196 root 20 0169m53m 8092 R 11.90.5 0:00.83 cc1
18436 root 20 0182m62m 4264 R 11.90.6 0:00.58 cc1
18574 root 20 0160m45m 7648 R 11.90.5 0:00.45 cc1
18622 root 20 0153m37m 7884 R 11.90.4 0:00.38 cc1
18624 root 20 0155m40m 7868 R 11.90.4 0:00.37 cc1
18627 root 20 0153m38m 8044 R 11.90.4 0:00.37 cc1
18206 root 20 0169m55m 8284 R 11.60.6 0:00.84 cc1
18245 root 20 0190m72m 5368 R 11.60.7 0:00.79 cc1
18325 root 20 0159m44m 8316 R 11.60.5 0:00.68 cc1
18563 root 20 0160m44m 7900 R 11.60.5 0:00.44 cc1
18074 root 20 0178m61m 8244 R 11.20.6 0:01.04 cc1
18678 root 20 0152m34m 5296 R9.90.4 0:00.30 cc1
18697 root 20 0148m29m 4256 R8.30.3 0:00.25 cc1
18711 root 20 0145m27m 4256 R7.30.3 0:00.22 cc1
18733 root 20 0143m24m 4244 R5.90.2 0:00.18 cc1
18736 root 20 0143m24m 4248 R5.90.3 0:00.18 cc1
18758 root 20 0139m20m 4240 R4.60.2 0:00.14 cc1
18764 root 20 0131m11m 2832 R3.60.1 0:00.11 cc1
18779 root 20 0132m14m 4232 R2.60.1 0:00.08 cc1
18780 root 20 0132m14m 4232 R2.60.1 0:00.08 cc1
18763 root 20 0 10208 6776496 S2.30.1 0:00.07 genksyms
18801 root 20 0127m 7672 2832 R1.00.1 0:00.03 cc1
18807 root 20 0127m 7136 2832 R1.00.1 0:00.03 cc1
18809 root 20 0127m 7140 2832 R1.00.1 0:00.03 cc1
15437 root 20 0 2533213m 1108 S0.70.1 0:00.08 as
18815 root 20 0127m 6640 2832 R0.70.1 0:00.02 cc1
1302 root 20 0 0 0 0 S0.30.042:09.79 kondemand/2
1303 root 20 0 0 0 0 S0.30.046:53.60 kondemand/3
5423 root 20 0 98.0m 4160 3152 S0.30.0 0:00.15 sshd
18455 root 20 0 15172 1416952 R0.30.0 0:00.03 top
18798 root 20 05980 2552496 S0.30.0 0:00.01 genksyms
18803 root 20 05456 2040496 S0.30.0 0:00.01 genksyms
18806 root 20 05456 1992496 S0.30.0 0:00.01 genksyms
1 root 20 0 19364 1448 1140 S0.00.0 0:00.62 init
2 root 20 0 0 0 0 S0.00.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S0.00.0 0:25.02 migration/0
4 root 20 0 0 0 0 S0.00.0 5:42.36 ksoftirqd/0
5 root RT 0 0 0 0 S0.00.0 0:00.00 migration/0
6 root RT 0 0 0 0 S0.00.0 0:15.98 watchdog/0
7 root RT 0 0 0 0 S0.00.0 1:03.39 migration/1
8 root RT 0 0 0 0 S0.00.0 0:00.00 migration/1
9 root 20 0 0 0 0 S0.00.0 1:50.12 ksoftirqd/1
10 root RT 0 0 0 0 S0.00.0 0:12.39 watchdog/1
11 root RT 0 0 0 0 S0.00.0 1:41.39 migration/2 本帖最后由 Buddy_Zhang1 于 2016-09-26 17:18 编辑
android代码 从应用层走到 android HAL 层都让程序员这么混乱了，所以速度当然慢，还有就是那个 java 虚拟机，一次性多那么多层，不慢不行，这关键还是 android 架构本身的缺陷吧（只是猜测），
有个疑惑，当初开发android 为什么不用 python 这种速度超级快的语言去开发，java 虚拟机就把速度降低多少，
android 速度慢和 linux 没有关系的。 Buddy_Zhang1 发表于 2016-09-26 17:15
android代码 从应用层走到 android HAL 层都让程序员这么混乱了，所以速度当然慢，还有就是那个 java 虚拟 ...
和java没关系吧
新机也是跑Java，比较快啊。机器稍微用久了就卡，卡得比用久的PC服务器和PC台式机都卡得多
回复 6# mordorwww
1.看你make什么项目吧。我的机器是i7 8核的台式机，make android 会很卡。
2.内存永远是不够用的。进程多了，内存的缓存页太多。需要压缩或者置换，这是一个原因。
3.cpu bound 的 case 可能会比较少。但肯定会存在。
4.很多应用都会去 emmc 里面读取会存数据，我理解老机器卡的原因和这个关系比较大。
本帖最后由 mordorwww 于 2016-09-27 10:35 编辑
amarant 发表于 2016-09-27 10:11
回复 6# mordorwww
1.看你make什么项目吧。我的机器是i7 8核的台式机，make android 会很卡。
我是make最新的4.7的内核, i5 4590 不改配置全部一般要make一两个小时的
几十个进程死循环，一般不会卡吧,很容易测的
不会卡在CPU上, 要么卡在flash上，要么是恶意软件把APP给卡住了，分析就这么两种情况吧。
现在手机内存都是3-4GB，如果这内存都不够，除非你把手机当电脑用了，开的窗口太特么多
用android手机去做编译这种大工程的活，不可能吧，没有太大的可比性
比如有时候点下就黑屏了，好久才恢复。
需要测，如果我做android手机，肯定会测一下到底是哪里卡住了
页:
[1]
2