Android 优化总结( 七 ) _Android

9.其他优化9.1 静态变量优化
尽量不使用静态变量保存核心数据。这是为什么呢？- 这是因为android的进程并不是安全的，包括application对象以及静态变量在内的进程级别变量并不会一直呆着内存里面，因为它很有会被kill掉。- 当被kill掉之后，实际上app不会重新开始启动。Android系统会创建一个新的Application对象，然后启动上次用户离开时的activity以造成这个app从来没有被kill掉的假象。而这时候静态变量等数据由于进程已经被杀死而被初始化，所以就有了不推荐在静态变量（包括Application中保存全局数据静态数据）的观点。
9.2 注解替代枚举
使用注解限定传入类型比如，尤其是写第三方开源库，对于有些暴露给开发者的方法，需要限定传入类型是有必要的。举个例子：
刚开始的代码
/** * 设置播放器类型，必须设置 * 注意：感谢某人建议，这里限定了传入值类型 * 输入值：111 或者 222 * @param playerType IjkPlayer or MediaPlayer. */public void setPlayerType(int playerType) { mPlayerType = playerType;}

优化后的代码，有效避免第一种方式开发者传入值错误

/** * 设置播放器类型，必须设置 * 注意：感谢某人建议，这里限定了传入值类型 * 输入值：ConstantKeys.IjkPlayerType.TYPE_IJK 或者 ConstantKeys.IjkPlayerType.TYPE_NATIVE * @param playerType IjkPlayer or MediaPlayer. */public void setPlayerType(@ConstantKeys.PlayerType int playerType) { mPlayerType = playerType;}/** * 通过注解限定类型 * TYPE_IJK IjkPlayer ，基于IjkPlayer封装播放器 * TYPE_NATIVE MediaPlayer ，基于原生自带的播放器控件 */@Retention(RetentionPolicy.SOURCE)public @interface IjkPlayerType { int TYPE_IJK = 111; int TYPE_NATIVE = 222;}@IntDef({IjkPlayerType.TYPE_IJK,IjkPlayerType.TYPE_NATIVE})public @interface PlayerType{}

使用注解替代枚举，代码如下所示

@Retention(RetentionPolicy.SOURCE)public @interface ViewStateType { int HAVE_DATA = https://www.isolves.com/it/cxkf/ydd/Android/2019-07-30/1; int EMPTY_DATA = 2; int ERROR_DATA = 3; int ERROR_NETWORK = 4;}9.3 多渠道打包优化
还在手动打包吗？尝试一下Python自动化打包吧……瓦力多渠道打包的Python脚本测试工具，通过该自动化脚本，自需要run一下或者命令行运行脚本即可实现美团瓦力多渠道打包，打包速度很快。配置信息十分简单，代码中已经注释十分详细。可以自定义输出文件路径，可以修改多渠道配置信息，简单实用。项目地址：http://github.com/yangchong21…
9.4 TrimMemory和LowMemory优化
可以优化什么？在 onTrimMemory() 回调中，应该在一些状态下清理掉不重要的内存资源。对于这些缓存，只要是读进内存内的都算，例如最常见的图片缓存、文件缓存等。拿图片缓存来说，市场上，常规的图片加载库，一般而言都是三级缓存，所以在内存吃紧的时候，我们就应该优先清理掉这部分图片缓存，毕竟图片是吃内存大户，而且再次回来的时候，虽然内存中的资源被回收掉了，依然可以从磁盘或者网络上恢复它。大概的思路如下所示在lowMemory的时候，调用Glide.cleanMemory()清理掉所有的内存缓存。在App被置换到后台的时候，调用Glide.cleanMemory()清理掉所有的内存缓存。在其它情况的onTrimMemory()回调中，直接调用Glide.trimMemory()方法来交给Glide处理内存情况。
9.5 轮询操作优化
什么叫轮训请求？简单理解就是App端每隔一定的时间重复请求的操作就叫做轮训请求，比如：App端每隔一段时间上报一次定位信息， App端每隔一段时间拉去一次用户状态等，这些应该都是轮训请求。比如，电商类项目，某个抽奖活动页面，隔1分钟调用一次接口，弹出一些获奖人信息，你应该某个阶段看过这类轮询操作！具体优化操作长连接并不是稳定的可靠的，而执行轮训操作的时候一般都是要稳定的网络请求，而且轮训操作一般都是有生命周期的，即在一定的生命周期内执行轮训操作，而长连接一般都是整个进程生命周期的，所以从这方面讲也不太适合。建议在service中做轮询操作，轮询请求接口，具体做法和注意要点，可以直接看该项目代码。看app包下的LoopRequestService类即可。大概思路：当用户打开这个页面的时候初始化TimerTask对象，每个一分钟请求一次服务器拉取订单信息并更新UI ，当用户离开页面的时候清除TimerTask对象，即取消轮训请求操作。