何为android的性能优化？

很多人问：“给我说说android的性能优化吧”大多数问你这个问题的人都不知道答案是啥。因为要说android的性能优化涵盖的东西很多，这个没有确定的答案，你说一条是对，说十条也是对的。都是在做项目中慢慢总结的。说白了，性能为啥要优化，还不是你的app问题多，用户用起来不爽。不得不去改变app中的某些模块吗？那下面我们就根据在项目中遇到的问题以及利用现有的技术如何让app的问题少一点，用户爽一点。
一款app，给用户第一映像的是啥？当然是界面了，这是最直接的视觉冲击了 ，和谐的布局给人美感，错乱的布局总是让人有种要砸手机的冲动，为了考虑到用户的经济利益，少砸点手机，我们还是要对app的布局进行优化滴，优化的目的有两个，第一是app的布局要尽可能多的适配不同机型，第二个布局的加载要尽可能的流畅。总结以下几点

1.巧用线性布局的weight属性，合理分配屏幕显示比例。
2.尽量使用相对布局，提高布局的扩展性，通过利用父容器和子空间的相对位置优化界面显示。
3.使用include标签统一管理导航栏，这里简单的说一下include标签， 说白了不就是一个xml文件引入了
另一个xml 文件但是引入的xml文件是可以自定义属性值的，但是在自定义属性值的时候，你必须要覆盖之
前的layout_width和layout_height 属性，否则属性值不生效，至于为啥，谷歌给的文档上没写，当然我
们也没必要搞的那么明白，知道这么回事儿就行。还有谷 歌推荐使用merge标签，但是这个标签唯一的卵
用就是不用多嵌套一层布局，在管理布局和优化和解析布局耗时上是有一定作 的作用。
4.对于隐藏的布局使用ViewStub标签，这样在显示的时候通过findviewByid得到ViewStub,然后ViewStub
的inflate方法得到加载的布局，然后在显示隐藏的控件即可，这样做的好处是，减少了布局文件的加载，
从而减少解析时间，android中的布局文件都是要先解析成view然后在渲染的，这样就减少了渲染时了。
5.为了适配平板，合理使用限定符例如：layout-sw600-land这个就不多说了，就是对应不同手机宽度来加
载相同xml文件名的布局，这里的sw是small width的缩写，看到这儿你是不是恍然大悟啊。

在app的使用过程中，发现图片咋加载的这么慢？还时不时的屏幕就卡在哪儿不动弹了。这个对于用户来说可是相当不爽。要不是刚摔了一个手机，这个手机我估计也得摔了。经过用户的投诉，老板的评判，扣工资等多个环节。最后还得是开发人员来解决这个问题，为啥要开发来解决，原因是产品和UI解决不了呗。老板是搞技术的，但是你不能让老板来做啊，要不他咋扣你工资啊。那么现在我们分析为啥图片加载慢，屏幕卡，但是向文字这种的加载就比较流畅？经过三秒钟的思考，终于锁定了问题出在了那里，以及怎样解决。为啥三秒就想出来了？开发人员一般都比较NB。这个不是我乱说的，我遇见的开发都真的比较NB，ok不扯淡了。我们分析问题，在我们向服务器请求数据的时候。服务器返回给我们的都是json数据，而这个json数据包含了请求图片的url。也就是说我们还要在次拿着这个url去向服务器请求图片。最后我门拿到二进制的数据转化为bitmap设置给我们的ui控件。当然这个过程是异步的。现在明白了吧？对的，文字类的信息我们在第一次请求的时候就已经拿到了，不用再请求了。所以没有纯文字的界面会卡的。但是图片就不一样了，图片本身占用的空间比较大，而且在内存中我们的ui空间在加载图片的时候是以图片的像素点存储到内存中，然后在设置给ui空间的。一个像素点占用4个字节，这样算的话一个图片在内存中占用的空间是本身大小的4倍，这就要求我们怎么做呢？
1. 在请求图片的时候，要对图片进行二次压缩，压缩后在为我们的view设置
2. 对于图片要进行两级缓存，一般步骤是在Lrucache中和本地硬盘中都做缓存，
3. 在图片的请求过成中为防止用户滑动，而造成图片的错位加载，一般做法是图片采用后进先出的原则，啥
意思呢？就是用户 加载滑动到指定位置后，先加载指定位置的图片，而不是从前开始一张一张的加载。在
请求过程中，为避免线程过多引起手 机卡顿，一般在请求图片的工具类中维护一个线程池。

好不容易解决了图片的问题，app看起来也爽多了，但是用户在向服务器上传视频时，七八分钟都没完事儿？这个可是他录了5s的视频啊，这不是非得让客户砸手机吗？在又一次扣了500块的情况下，开发人员再次坐在了电脑前。你妈，录个5s的视频咋会上传那么长时间呢？经过三秒的思考，我们终于锁定了问题，这个录视频是用调用android系统录制的，录制1s就将要5M，这得吓死人啊。哪有录歌视频还这么大的，这个要上传给我们服务器，不一会儿就把我们服务器给撑爆了呀。改吧，这个个问题的关键是我们如何减少录制视频的大小。由于android系统录制的局限性，我们要不能再依靠android系统的那个东东了，用MediaRecoder这个类来搞了，用法在这里不多介绍，因为本片主要介绍android的优化，所以我们在这里只取一条，那就是MediaRecoder录制视频时可以指定视频的码率，有了这个东西我们就可以设置视频的大小了，哈哈。总结一下：

在录制视频时，不要使用android系统录制，尽量使用可定制视频录制大小的MediaRecoder来录制。视频大小=视频文件码率 X 时长。一般不涉及较多视频编码，水印等功能时，不用引进ffmpeg库。java就完全搞定了。

图片和视频也搞定了，看起来也流畅了，用户这次不用砸手机了，但是用户在使用的过程中又发现还是越来越卡，这是为啥呢？其实在android机上无论是那个程序，你用着用着就会变得卡，归结原因这并不是你的应用程序卡，而是手机整体性能降低了，android的机制是只要可以推送到消息的app都会在后台运行？那么，当我们接收到消息推送的时候，后台已经开始运行了某个app了，还有缓存的垃圾文件等，不像ios那样，每次只是运行一个应用程序，所以你看到ios即使是1g的运行内存都不会卡。android机制的问题我们不予解决，再说了咱也解决不了不是？先在我们可以做的是啥，尽量节约内存，提高app的运行效率，这个怎么做呢，请看这篇简单的总结android中的内存优化总结