前言
随着APP开发的业务进展到一定的程度，无论是App安装包的体积也好，运行内存也好等方面都出现了极大的问题，安装包体积不断增大，运行内存过大容易导致OOM，这些问题都亟需解决，也是进阶的必备之路。既然前期已经污染了，后期就一定要加紧治理，所以这几天也进行了一定的思考和整理。
分析
从App的角度先分析了几个方面的优化，当然只是初期的整理，如下：
一开始的设想是想对显而易见的内存泄漏和安装包进行优化，对于模块化和组件化，这个主要是需要大量的时间对项目代码结构进行调整和实践。 接下来先简单介绍安装包大小和内存。
安装包方法数
项目的安装包大小大概在26.5兆左右，方法数大概是180000，方法数的统计是通过Apk method count得来的。对于方法数过大造成的影响一方面是体积增大，另一方面是dex包增大，180000个方法分为5个dex包，dex包过大会影响载入代码的性能。减少方法数的举措主要有两个，一个是移除重复功能的库，如项目同时使用了Glide和Fresco，还有及时对未使用的库进行清理，第二是优化第三方的混淆规则，打包开启Proguard之后，会把无用的第三方库的方法移除。像我自己做的实践也是如此，移除了之前项目中的春节活动代码，还有对项目中使用的Jsoup和Greendao的混淆规则进行优化，之前相关的开发人工的混淆规则是keep整个库，所以会导致无用的方法也保留，一般来说库的混淆规则作者都会进行提供，优化了Jsoup GreenDao的混淆规则之后，方法数也减少了一千多。资源优化
首先是大图压缩，推荐网站是tinypng，通过tinypng可以大大减少图片的体积，其次要及时清楚项目的无用图片资源，还有对于资源的压缩还可以通过微信开源的资源压缩工具AndResGuard，原理是压缩了资源的路径和名称，亲测可以减少体积1兆左右，不过由于自身项目换肤方案依赖于资源的名称，所以无法应用上AndResGuard。- 运行内存
对于应用运行内存来说，要注意的地方很多，但是可以先优先两点，第一是内存紧张的时候，通过Application的onTrimMemory回调来回收掉一部分内存，对于低内存的模拟可以通过adb的指令 adb shell am send-trim-memory com.example.app MODERATE 其中MODERATE是内存紧张的等级，大致可以分为以下几个：
TRIM_MEMORY_COMPLETE：内存不足，并且该进程在后台进程列表最后一个，马上就要被清理
TRIM_MEMORY_MODERATE：内存不足，并且该进程在后台进程列表的中部。
TRIM_MEMORY_BACKGROUND：内存不足，并且该进程是后台进程。
TRIM_MEMORY_UI_HIDDEN：内存不足，并且该进程的UI已经不可见了。
TRIM_MEMORY_RUNNING_CRITICAL：内存不足(后台进程不足3个)，并且该进程优先级比较高，需要清理内存
TRIM_MEMORY_RUNNING_LOW：内存不足(后台进程不足5个)，并且该进程优先级比较高，需要清理内存
TRIM_MEMORY_RUNNING_MODERATE：内存不足(后台进程超过5个)，并且该进程优先级比较高，需要清理内存
通过指令指定等级，即可以模拟相关的内存紧张情况。第二是不必要的对象或者类进行延迟加载，例如使用布局的viewstub来对视图进行延迟加载，在自己的项目中，通过对侧边栏视图使用ViewStub进行延迟加载，延迟了将近10兆内存的消耗。
总结
对于App的优化，不是一朝一夕可以完成的，此次我也只是简单做了相关的介绍和整理，之后相关的具体优化实践会通过专栏进行更多的介绍和应用。