作者jastpower884 (WIND)
看板AndroidDev
标题[问题] Asynctask 无法立即执行的问题
时间Thu Apr 17 20:38:37 2014
最近写了一个程式，功能会大量用到 Asynctask 和 GCM 去向网路取资料。
但是最近发生了一个状况，就是在某些状况下（可能是 Asynctask 没把东西还没取
完东西）如果碰到主程序 Crash 的时候，再开启一次程式 Asynctask 的执行序会全部都
卡住。
低阶机种 HTC Desire S(大树)倒是不会有这种状况，但是 LG G2、Sansumg Note3
却得卡上一段时间才会跑执行序(大约一分钟)，而如果遇到 Sony 的机子(Z、ZR)，则会
彻底卡死，除非去清除暂存和快取，还有强制终止程式才能解决。
碰到这样的状况如果我下 ActivityManager.killBackgroundProcess 能够解决，本
来是想说用 UncaughtExceptionHandler 去拦截後下杀光所有背景服务的指令，只是好
像不是每一次都这麽顺利(有的时候可以，有的时候不行)。
周遭的同仁对这个状况多出了很有趣的假设，因为大树的记忆体太少了，所以在程
式写坏当掉的时候会把这些东西清掉，但是 G2 Note3 或是 ZR Z 那些，则是记忆体
比较大，会把这些卡住的执行序留着，反而让一次限制五个执行的 AsynTask 卡住了。
我想问的是，有没有人遇过太多异步任务卡住的问题？是如何解决呢？
--
"The speed of communication is wondrous to behold. It is also true that speed
can multiply the distribution of infomation that we know to be untrue." -
Edward R. Murrow
「现代的通讯速度确实惊人，但它同时也能加速错误讯息的传播」- 爱德华‧莫罗
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.248.232.9
※ 文章网址: http://webptt.com/cn.aspx?n=bbs/AndroidDev/M.1397738325.A.7EF.html
1F：→ qweqweqweqwe:但ap都crash了.. Asynctask 还会有影响?这麽神奇QQ 04/17 21:26
我也觉得很神奇，写 Android 两年有余，这种事情还真的头次遇到。
※ 编辑: jastpower884 (111.248.232.9), 04/17/2014 21:41:58
2F：推 sdyy:用executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR) 04/17 21:56
3F：→ sdyy:强制异步 应该可以解决 不然一定会等前面做完才继续 前面卡了 04/17 21:57
4F：→ sdyy:就动弹不得 04/17 21:57
恩，谢谢，我会试试。其实我比较怕的是，这不单是 Asynctask 的问题，会不会是我用
了一些 static 的关系....。
5F：→ Deltaguita:我觉得你的Asynctask 里面的连线，要设定timeout 04/17 21:58
其实有设 timeout 的，但是如果 crash 掉，已经 timeout 还是卡着，我是觉得他就会卡
着直到被系统抛掉了。
※ 编辑: jastpower884 (111.248.232.9), 04/17/2014 22:03:42
6F：→ Deltaguita:你的问题我有遇过类似的，到後来我自己实作一个 04/17 22:05
7F：→ Deltaguita:asynctask 先跟系统预设的Thread Poor分开来 04/17 22:06
8F：→ Deltaguita:当时会造成这样的原因是因为 两个thread 互相等待 04/17 22:07
9F：→ Deltaguita:当时会造成这样的原因是因为排队造成的 04/17 22:07
喔喔喔，这样啊，我还以为只有我有这种状况，赶紧来试试。x
※ 编辑: jastpower884 (111.248.232.9), 04/17/2014 22:13:08
恩姆，真的是 Thread 阻塞的问题，用Thread pool 就解决了，根据厂商，阻塞的表现
还会有所不同...。
※ 编辑: jastpower884 (111.248.220.197), 04/19/2014 11:45:01
10F：推 tac0wu:pool? 04/19 16:58
11F：→ qweqweqweqwe:ㄎ 能简略分享一下吗 感觉这例子很有趣 04/19 21:13
恩，就是我一个 Activity 会同时使用 AsyncTask.execute() ，至少会有五个吧。
如果这时候 Crash 掉，再重开一次程式， AsyncTask.execute() 就不会立即执行，
有的手机甚至就卡在那边永远都不动了。
在我的认知上，是因为 3.0 後的 AsyncTask.execute() 一次只会执行一个，其他的就会
进入排队的状态，所以一个塞着队伍，其他都卡住了。
後来我就改用 executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR) 就解决了。
不知道是不是这个指令会把前面的 AsyncTask 给踢掉就是了。
※ 编辑: jastpower884 (111.248.220.197), 04/21/2014 23:06:43
12F：→ Deltaguita:要间容3.0以前的，会有点麻烦 04/22 12:21
13F：→ Deltaguita:可以考虑直接使用一个3.0以後的asynctask(从源码抓) 04/22 12:22
这边我很乾脆直接继承 AsyncTask 去写一个 function 用 Build.VERSION.SDK_INT 做
判断了，3.0 前直接用 execute，3.0 後就用 executeOnExecutor。
两者写法不同，不过实际跑起来是一样的。其实这个问题不要让手机 Crash 掉都不会遇
到，现在我比较头痛的是 bitmap 的 OOM。
※ 编辑: jastpower884 (118.163.116.90), 04/22/2014 13:24:47
※ 编辑: jastpower884 (118.163.116.90), 04/22/2014 13:26:23
14F：推 Deltaguita:bitmap oom 我之前也是很常遇到阿~~~~ (爆 04/22 14:27
15F：→ Deltaguita:後来有解决就是了，有兴趣可以再讨论 04/22 14:28
这部份比较像是我个人耍憨包，本来是 LruCache SoftReference 都用上了就是无解
感觉很绝望...後来发现是自己脑残抓了近百张 300*300 的图片...大树会爆不解释，
这样的状况 G2 都不见得撑得住。
※ 编辑: jastpower884 (118.163.116.90), 04/22/2014 15:32:21