关于开发 Android 应用时 Application 或者 Activity 的 android:hardwareAccelerated="true" 的问题
greenskinmonster · 2015-09-11 15:34:36 +08:00 · 13070 次点击这是一个创建于 3354 天前的主题，其中的信息可能已经有所发展或是发生改变。
你们的应用是怎么设置的？
我自己试了下，貌似设不设差别不是太大。
所以来看看有没有先行者分享下经验。
我自己试了下，貌似设不设差别不是太大。
所以来看看有没有先行者分享下经验。
 |
1
wy315700 2015-09-11 15:42:37 +08:00  1
遇到刷新快一点的页面，不开硬件加速会出闪
遇到大的图片，开了硬件加速会有问题 当然，如果手机开了强制 GPU 渲染，这个选项是无效的 |
 |
2
greenskinmonster OP @wy315700 多谢～莫非还是要保留个开关？
|
|
3
wy315700 2015-09-11 15:58:34 +08:00
@greenskinmonster 看你使用场景了。。
|
|
4
greenskinmonster OP @wy315700 论坛客户端，文字图片都有，大段文字时有点卡。现在想看看有什么办法改进下流畅性。
|
|
5
wy315700 2015-09-11 16:04:04 +08:00
@greenskinmonster 卡的话开了硬件加速会比较好，但是大图片(4096 以上分辨率)的处理就要小心了
|
 |
6
kifile 2015-09-11 16:08:14 +08:00
硬件加速是属于在内存里始终保持了一块区域装载上一次的绘制图像，因此他其实是用内存空间换速度。
|
|
7
greenskinmonster OP @wy315700 这么大的图都是缩放了才显示的。不过有时候会有一页会有上百张图，不知道硬件加速会不会导致更容易 OOM 。看来需要去实际测试下看看了。
|
 |
8
kyze8439690 2015-09-11 16:10:16 +08:00
拿空间换速度
|
|
9
wy315700 2015-09-11 16:14:52 +08:00
@greenskinmonster 主要是长图，，，见过 300*30000 的图，，，
|
|
10
greenskinmonster OP |
|
11
greenskinmonster OP @kifile @kyze8439690 这个内存应该还是算在 App 的占用里面，而不是系统级的吧？意思是理论上会导致 App 更容易 OOM 吧？
|
 |
12
liangzhitao 2015-09-11 16:44:06 +08:00
|
|
13
greenskinmonster OP @liangzhitao 已经在用这个了，个别图片显示的有点问题，但是总体还是很棒的。不过我想试下硬件加速主要还是解决 TextView 含有大量文字时，以及 Fragment 切换时的性能问题。
|
 |
14
allan1st 2015-09-11 17:26:57 +08:00 1
@greenskinmonster 大段文字卡可能是 TextView 的问题，看看 Instagram 怎么解决的： http://instagram-engineering.tumblr.com/post/114508858967/improving-comment-rendering-on-android
|
|
15
kifile 2015-09-11 17:56:29 +08:00
@greenskinmonster 首先他保存的图像内存并不是保存的所有图片，而是当前 View 的绘制界面，也就是说那些使用 ListView 但是没有加载出的图片其实并没有放到内存里，所以虽然你总的图片很多，但是很多图片其实是没有占用额外内存的。
|
|
16
kyze8439690 2015-09-11 18:50:17 +08:00
通用的思想而已，硬件加速本身会占用内存。
然后你所说的列表滚动卡的问题，也可以用空间换速度。 首先列表为什么会卡？这就涉及列表滚动的时候做了什么事。 主要看 getView 函数， 可能的 inflate ，以及数据绑定。然后 listview 去 measure ， layout ，最后 draw 。 inflate 方面，可能因为 xml 的层次过多导致 inflate 耗时过多，这时候就要简化 xml 结构，整个也会影响 listview 的 measure 和 layout 的耗时。还有一个可能就是一个 listview 采用了多种 type ，导致滚动时新的 type 没有缓存，导致 inflate 耗时，这时候可以事先新建好 view 来复用。 inflate 之后，就是数据绑定的事情了，这里可能会对数据做一些处理，比如格式化，等等。这里就是我建议的空间换速度，把数据事先格式化好，尽量减少 getView 的耗时。 measure 和 layout 就靠简化 xml 层次，前面已经说了。 draw 的话就尽量减少 overdraw 。 关于硬件加速的问题，一般不会去开启它，因为他是全局性的（ application ）。可以尝试在 View 的层次去局部开启硬件加速，比如对一个 View 做 animation 的时候，先开启硬件加速， animation 结束后关闭硬件加速。 可能有点乱，讲究着看。 |
|
17
greenskinmonster OP @kyze8439690 多谢，说的都对啊，特别是 inflate - measure 这段。
但是现在限于水平问题，比较难准确的分析出来，到底哪里还有改进的空间，具体怎么改进。 所以先想走个捷径，看看硬件加速有没有用。 |
|
18
greenskinmonster OP @allan1st 多谢，我收藏下看看。
|
|
19
kyze8439690 2015-09-11 19:44:05 +08:00
method tracing
还是针对性优化比较好，你这个改动太大。 |
|
20
greenskinmonster OP @kyze8439690 多谢，暂时采用了 animation 时临时开启硬件加速的办法
有兴趣的看这篇文章吧 http://daniel-codes.blogspot.sg/2013/09/smoothing-performance-on-fragment.html 不过主观上还没法评价改进幅度，模拟器上开不开都傻快傻快的。 |
 |
21
busymilk 2015-09-13 20:01:36 +08:00
自定义控件的话，会出问题
|
 |
22
Cryse 2015-09-15 14:50:55 +08:00 via Android
我也自己做的论坛应用，图文混排，用 custom View 替换了 TextView, 用预生成的 StaticLayout/DynamicLayout 直接绘制在 canvas 上，性能有相当提升
|
|
23
greenskinmonster OP @Cryse 多谢，不过貌似对我来说实现起来有点难度。
|
Select Language