Android 系统的优化，包括系统整体性能，开机启动时间(包括第一次和后续开机启动时间)，单个应用的启动时间。
整体性能的优化非常难处理，关键是如何找到系统性能的瓶颈。同时，这也是考验系统工程师的关键核心，可以说体现价值的时刻到了。
如果你会，而别的工程师弄不出来，你的工资高出几千，人家也没有话说了，这些资料可是市面上找不到的高价值资料，一般老工程师都不愿意说。
那么系统体验不好的原因如何查找？系统慢只是一个感觉而已，原因多种多样，比如测试工程师测试的时候后台在使用某些后台动作，拖慢了系统；
系统工程师在集成的时候，将某些耗时的调试日志一直开启，低内存系统配置系统不当；驱动工程师一些错误的修改。
1、测试工程师的测试手法问题，我们系统工程师可以自己复现问题的时候仔细观察，一般可以很快发现，这个就不多说。
2、系统集成的问题，我们工程师自己通过观察系统日志，发现有些日志会短时间的大量的输出，可以考虑查找对应日志并关闭即可
3、低内存的系统，首先要确定系统是否开启了 内存压缩机制，如果开启了内存压缩机制，会在运行时进行内存压缩和解压缩，这个当然就会影响性能。
另外，低内存的系统，如果安装的应用比较多，无法让所有应用同时存在，这样就会导致一个问题，用户在切换应用的时候，其实系统是不断的
在后台杀死某些应用，同时又启动用户需要的应用。这样也会导致系统体验不好。最后，低内存的系统，往往会将 Cache分区划分的比较小，这也是
会影响系统速度的。
其实，我们常用的优化办法之一，对于很多初级系统工程师来说，也是唯一知道的办法就是 ODEX。原理很简单，空间换时间，开启ODEX后，编译出来的System.img
会大很多，编译出来的APK会变成APK+ODEX，实际上就是把一些在启动的时候做的事情在系统编译的时候做好了，这样开机速度会明显快起来。
ODEX开启之后，系统依然缓慢，这时候大多数初级系统工程师基本就束手无策了。
这个问题难在什么地方？因为系统并不出差错，系统日志看不出毛病，和过去的一些出现问题的情况不一样，那么我们很难定位到问题点，就无从改起。
系统瓶颈到底在什么地方呢？典型的情况是 一些非我们预期的应用在后台运行，并且占着CPU或者内存，那么我们可以使用类似 ps 或者 top 等工具分析CPU和内存
的占有率，找到对应的进程之后，才能找到对应的应用，我们才能进行下一步的优化修改。
有经验的工程师会怼我：”说的容易，那么容易，谁都可以拿高薪了“。的确，这些分析工具获得的数据，并不能简单快速的找到问题点，想要多拿几千，还必须沉下心来。
