关于 Android APP 过度绘制的问题

看复杂度，有些是一开始没考虑到，后面布局已经定型了，突然大改的话成本没必要。但是我们还是有一个同事专门花了一两周时间基本解决了这个....

@crayygy emmm...我差点以为咱两是同事，，，我基本解决了这个问题后，想看看一些经典的 APP 和 Google 家亲儿子怎么做的，发现都是一片红。。。另，确实一开始就应该考虑进来，后续改动不仅仅是成本问题，还可能会有一些历史遗留引起的不适。。。

@crazypudding #2 我们是因为发现有很多的 Frozen Frames，然后从各个角度都开始进行优化

一开始就考虑太多会拖累开发进度。现在写布局需要考虑的东西太多了，布局复杂度（尽量减少层级）、热区大小、过度绘制，当然还有最应该考虑的具体业务实现。

除非是时间很充裕或者页面结构简单可以顺手做了，否则优化型的都应该放到以后做。（也可能你做了一堆发现后面需求变了，233 ）

历史原因+需求变更

你优化的速度更不上变更的速度

还有就是一些特殊的需求，你很难优化的


constraintlayout 了解一下？？新布局都用它写会减少很多层级

know nothing do everything，然后回头说手机不行

尽力而为吧很多时候不多绘制一次，有的地方会全黑，想解决还得手动画框框绘制，现在手机性能上来了，可以放开一些。
Gmail 还凑活大多都是蓝绿。不过有的应用全红当然是有问题了。
个人经验是，修理这个挺烦的，不过有时间为了良心过得去也要修一下。

@zhenghuiy 放到以后做是不可能的了，这辈子都不可能了 2333，，，只能说在开发的同时尽量考虑，不然新需求一上来停都停不下来

@tanranran 是这么个理，只能说新开发的同时尽量去注意做一下这个事。constraintlayout 一直在用，只是公司项目太老，要优化层级相当于重写了

@DeweyReed 感觉这个就是得开发的时候注意，后期优化工作量太大，一不小心还能挖个坑出来

说白了还是责任心的问题，有些人只想赶紧做完，有些人做之前先考虑考虑
至于别人做完了让我去优化？那不存在的，能这么不负责的人，写出来的代码谁敢动？

软件做到一定程度，有些是无法避免的，只能说尽量控制，自绘框架做的再好随着需求不断变动，最终也会掉这个坑里
早期 symbian 时代，那些自绘框架对这个非常注重，你那软件跑一会儿就发热，电唰唰的掉，用户转身就卸载了，到了 iOS 和 Android 时代，没多少程序员关心这个了，除非出现明显卡顿才会有人去处理

成本问题，精力成本和维护成本。我基本倒每次都会看一眼过度渲染。但实际上是没有办法完全避免。也没什么太多必要。看一眼渲染时间，已经 16ms 左右了，那再优化产生不了太大价值。
明显卡顿的时候，所有其他办法都用了再回来看这个，99%的时候无效。。有几次性能优化的时候遇见过= =！性价比并不高~。再仔细看看是逻辑算法有问题而已。。。
虽然没做过 pc 客户端，但从原理上推测，不管什么客户端，都没办法完全避免过度渲染，图层一定是一层一层贴上去的。只是重合问题多少而已。

过度绘制不是 Bug
过度绘制也不一定等于卡顿

很多时候还是要给工程性让步的，只要能保证 16ms 渲染也无所谓。

可能是现在的手机性能过剩，都不卡，如果卡了就有人会关心这个问题了吧

@sampeng @nicevar 有些过度绘制确实是没法避免的，所以说只能尽可能在自己做的时候注意下这个问题，至少写的代码多年后自己再看到不会觉得一阵恶心，，至于优化效果，就我做完来看，确实不是很明显

我发现就算绘制 30 层，甚至更多，都不会卡。程序卡百分之九十九，都是业务逻辑和 ui 更新，没写清楚。动画，多媒体播放器没有交代好。

其实...关于过度绘制...其实 android 在渲染那块是有一定的优化的........
对于避免过度绘制..最好还是上 constraintlayout ...