首先说一下背景，项目一个滑动界面，利用viewPager做的，滑动以及加载的时候十分卡，卡到怀疑人生。所以，不幸的收到了优化的工作。优化看似简单，实则真是一言难尽（orz）。虽然很头大，但是还是收获颇多，结果也不算太坏。界面的情况大致如下，一个大界面，仅有一个recycleView，里面有60个item需要一起显示，而且每个item的布局是复用的，也就是说其他界面也会用这个布局，只是根据状态对控件进行隐藏和显示，这就导致了item的布局很深较复杂，滑动不卡顿那才是奇怪的事情。不考虑加载动画，因为需求不许，要有加载动画，走完第一个回合就差不多了。

我统计了一下布局的层数，有七层之多，所以第一步就是要减少嵌套。下面就是我走过的辛酸历程

1.设计布局前，尽量的考虑用最少的嵌套层数。优化布局的时候，先考虑能不能减少层数。如果你存在父布局也有id，他的作用只不过是统一显示或隐藏其子控件，那么你大可以把这层去掉，逻辑层写方法统一处理子控件；同时检查是否存在多余的背景图，本人的优化布局就存在一个image，设置match宽高充当背景，这个大可不必，完全可以去掉。如果最后发现实在无法去把嵌套减少，那么新出的约束布局则是最好选择。我经过对比，发现在层级很少的情况下，约束布局的效率和传统布局差距不大，甚至不如传统布局，但是对于层级很深的（3层以上），优势较大，可提升一个台阶。约束布局的好处是，你经过缜密的设计，可以完全把一套空间写在同一个层级中，这样绘制的效果就会大幅度增加。以上我都做了，效果有提升，但还是达不到要求，60个item，确实难。这里送上一个链接，是比较布局之间的加载速度，个人经过实际测试，也相差无几

https://www.cnblogs.com/liujingg/p/7161319.html

2.layout_weight慎用，我查阅了大量资料，layout_weight其实也会对布局加载速度产生影响。一般布局没那么复杂，还好，影响几乎为0，但是需求的这个布局，乘上60，这个影响就大了。所以，在LinearLayout布局中这个比例慎用，我对一些不复杂的地方将其宽或搞固定，发现确实有提升，但提升较小。约束布局也有类似应用，如果真需要用比例，不妨减少层级用约束布局，通过约束布局的比例运用来解决，这样的效率会提高不少。

3.onBindViewHolder里面的方法子线程调用。突发奇想，由于每个布局都在主线程，那么假如多开线程会不会好一点？事实上并不会，因为加载onCreateView里面是不予许在子线程调用，至少我是报错的，所以最后改为在onBindViewHolder里面。初始确实不会卡，但界面效果是你划到那个界面他会一个一个加，其实如果需求允许的情况下，个人觉得这种效果也不失为一种好的解决方式。

4.StudView。需求要求不可取，这个标签的意思是，你只有代码调用的时候他才会加载，也就是说，你不用的话他就相当于不存在，这就造成了本人优化项目的一个后果，由于布局共用，id找不到导致部分用到代码的地方挂掉。当然如果你仔仔细细的一开始就能捋顺，用这个来设计共用布局，也不失为一个好的解决方案。但是项目是祖传代码，无解，还不如从新写。

5突然又想到了懒加载，因为既然是进来的时候慢，那是因为会预加载其他的，那么关闭预加载不就行了？一次只加载一个，应该会快一点，结果，根本没用。看来这里面的源码还需要多瞅瞅。

6.最后只能抽离布局了，把布局抽离出来，各用各的，耗费许多时间，但是效果较为理想。能不要的控件尽量不要，在实际中发现，布局层数的减少到最后往往时间上不会减少很多，相反，控件个数的减少会缩短很多时间。所以这也给了一个提示，有能够共用一个控件进行展示的尽量用一个，比如图文，尽量自定义控件，不要一个ImageView加textView。同时，启示就是，共用虽然方便，但后患也不是没有，一定要考虑仔细。

推荐工具，SysTrace，教程网上一堆，作为辅助用。还有就是打开机器的gpu渲染，看看重绘程度。不要苛求，因为有的实在没办法消去所有的红色，保证界面只有一小部分是红色，就足够了。

总体就是这么多了，都是些常见的手段，所以假如大神看见了，也给点其他的建议，小弟在此谢过了。笔记，记菜鸟优化路之疯狂的三天。