Android优化系列一: 日志清理

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: ## 简介 在Android应用开发过程中,通过Log类输出日志是一种很重要的调试手段。 大家对于Log类的使用,一般会形成几点共识: 1. 在Debug模式下打印日志,在Release模式下不打印日志 1. 避免滥用Log类进行输出日志。因为这样可能造成日志刷屏,淹没真正有用的日志。 1. 封装Log类,以提供同时输出日志到文件等功能 具体细化为以下几点建议: 1. 禁

简介

在Android应用开发过程中,通过Log类输出日志是一种很重要的调试手段。
大家对于Log类的使用,一般会形成几点共识:

  1. 在Debug模式下打印日志,在Release模式下不打印日志
  2. 避免滥用Log类进行输出日志。因为这样可能造成日志刷屏,淹没真正有用的日志。
  3. 封装Log类,以提供同时输出日志到文件等功能

具体细化为以下几点建议:

  1. 禁用System.out.println
    Android应用中,一般通过封装过的Log类来输出日志,方便控制。而System.out.println是标准的Java输出方法,使用不当,可能造成Release模式下输出日志的结果。
  2. 禁用e.printStackTrace
    禁用理由同上

建议通过封装过的Log类来输出异常堆栈信息

  1. Debug模式下,通过一个静态变量,控制日志的显示隐藏。
    我一般习惯直接使用BuildConfig.DEBUG,当然,你也可以自己定义一个。

private static final boolean isDebug = BuildConfig.DEBUG;

public static void i(String tag, String msg) {
    if (isDebug) {
        Log.i(tag, msg);
    }
}

4.Release模式下,通过Proguard配置来移除日志
在Proguard配置文件中,确保没有添加 --dontoptimize选项 来禁用优化的前提下,
添加以下代码:

-assumenosideeffects class android.util.Log {
        public static *** d(...);
        public static *** e(...);
        public static *** i(...);
        public static *** v(...);
        public static *** println(...);
        public static *** w(...);
        public static *** wtf(...);
}

那么,是否我们按照上面的做,就真的一劳永逸呢?
我的脑海中浮现出几个相关问题:

  1. Proguard配置中添加的配置,真的可以在Release模式下,移除日志吗?
  2. 如果我们用的是封装过的Log工具类,应该怎么配置?
  3. 移除日志后,原来在日志方法中的拼接字符串参数,是否还会申请/占用内存?
    ...

本着大胆假设,小心求证的原则,下面我们通过实践来探索上面的问题答案。

本文基于以下项目进行测试实践:
https://github.com/snowdream/test/tree/master/android/test/logtest
反编译工具:JD-GUI

验证Proguard配置清理日志的有效性

CASE

Log.i(TAG,"这样使用,得到的LOGTAG的值就是DroidSettings," +
        "然而并非如此,当DroidSettings这个类进行了混淆之后,类名变成了类似a,b,c这样的名称," +
        "LOGTAG则不再是DroidSettings这个值了。这样可能造成的问题就是,内部混淆有日志的包,我们去过滤DroidSettings " +
        "却永远得不到任何信息。");

在添加上述Proguard配置前后,编译打包Release模式的正式包,使用JD-GUI进行反编译,对比上述代码的编译后代码。

结果

添加配置前
case1_a

添加配置后
case1_b

结论

通过比对结果,我们可以得出结论:
通过添加Proguard配置,可以在Release模式下,移除掉日志。

验证封装过的Log工具类,是否有必要进行而外配置

CASE

LogUtil.i(TAG,"这样使用,得到的LOGTAG的值就是DroidSettings," +
        "然而并非如此,当DroidSettings这个类进行了混淆之后,类名变成了类似a,b,c这样的名称," +
        "LOGTAG则不再是DroidSettings这个值了。这样可能造成的问题就是,内部混淆有日志的包,我们去过滤DroidSettings " +
        "却永远得不到任何信息。");
        

在添加上述Proguard配置前后,编译打包Release模式的正式包,使用JD-GUI进行反编译,对比上述代码的编译后代码。

结果

添加配置前
case2_a

添加配置后
case2_b

结论

通过比对结果,我们可以得出结论:
在这种简单封装的情况下,我们不需要额外的配置,也可以将封装过的Log工具类调用日志一起移除。

当然,实际使用过程中,可能封装更复杂。为了保险起见,可以也添加上Log工具类的配置。示例如下:

-assumenosideeffects class com.github.snowdream.logtest.LogUtil {
        public static *** d(...);
        public static *** e(...);
        public static *** i(...);
        public static *** v(...);
        public static *** w(...);
}

验证移除日志后,字符串拼接是否还存在?

CASE

Log.i(TAG,"这样使用,得到的LOGTAG的值就是DroidSettings," +
        "然而并非如此,当DroidSettings这个类进行了混淆之后,类名变成了类似a,b,c这样的名称," +
        "LOGTAG则不再是DroidSettings这个值了。这样可能造成的问题就是,内部混淆有日志的包,我们去过滤DroidSettings " +
        "却永远得不到任何信息。");

Log.i(TAG, "这样使用,得到的LOGTAG的值就是DroidSettings," +
        "然而并非如此,当DroidSettings这个类进行了混淆之后,类名变成了类似a,b,c这样的名称," +
        "LOGTAG则不再是DroidSettings这个值了。这样可能造成的问题就是,内部混淆有日志的包,我们去过滤DroidSettings " +
        "却永远得不到任何信息。" + index ++);
        

上面代码的区别是:
前面是简单的字符串相加,而后面是字符串和变量的相加
在添加上述Proguard配置的前提下,分别针对以上两段代码,编译打包Release模式的正式包,使用JD-GUI进行反编译,对比上述代码的编译后代码。

结果

简单字符串相加
case1_b
字符串和变量相加
case3

结论

通过比对结果,我们可以得出结论:
如果只是简单字符串相加,是会彻底移除的,并且字符串拼接也不见了,不会占用内存。
而如果是字符串和变量相加,日志会移除,但是字符串拼接还在,还会占用内存。

验证日志中使用函返回值的情况

CASE


        LogUtil.i(TAG, getMessage());

        LogUtil.i(TAG, "FROM FUNCTION " + getMessage());
        
        private String getMessage() {
            return  "这样使用,得到的LOGTAG的值就是DroidSettings," +
                "然而并非如此,当DroidSettings这个类进行了混淆之后,类名变成了类似a,b,c这样的名称," +
                "LOGTAG则不再是DroidSettings这个值了。这样可能造成的问题就是,内部混淆有日志的包,我们去过滤DroidSettings " +
                "却永远得不到任何信息。";
        }
        

上面代码的区别是:
前面是直接使用函数返回值,而后面是字符串和函数返回值的相加
在添加上述Proguard配置的前提下,分别针对以上两段代码,编译打包Release模式的正式包,使用JD-GUI进行反编译,对比上述代码的编译后代码。

结果

直接使用函数返回值
case1_b

字符串和函数返回值相加
case4

结论

通过比对结果,我们可以得出结论:
以上两种场景下,日志移除,拼接字符串不在了,也不会占用内存。

经过大量实践后的结论

如果你以为上面就是全部真相的话,就错了。
经过大量的测试实践,实际上真相更复杂。

以下是开启Proguard前提下,各种情况下的测试结论:

  1. Log.i(简单字符串)
  2. Log.i(局部变量)
  3. Log.i(成员变量)
  4. Log.i(简单字符串+局部变量)
    以上四种情况,日志被彻底移除,不会额外增加内存。
  5. Log.i(简单字符串+成员变量)
    日志被移除,但是字符串拼接会存在,并占用内存。
  6. Log.i(成员函数) 其中,成员函数返回值为: 简单字符串
  7. Log.i(成员函数) 其中,成员函数返回值为: 简单字符串+局部变量
    以上两种情况,日志被彻底移除,不会额外增加内存。
  8. Log.i(成员函数) 其中,成员函数返回值为: 简单字符串+成员变量
    日志被移除,但是字符串拼接会存在,并占用内存。

注:以上所有情况,参数都是指第二个或者后面的参数。第一个参数,我都使用了静态成员变量:
private static final String TAG = MainActivity.class.getSimpleName();

优化建议

  1. 确保没有开启 --dontoptimize选项的前提下,添加Proguard优化日志配置
-assumenosideeffects class android.util.Log {
        public static *** d(...);
        public static *** e(...);
        public static *** i(...);
        public static *** v(...);
        public static *** println(...);
        public static *** w(...);
        public static *** wtf(...);
}
  1. 针对这种情况“Log.i(成员函数) 其中,成员函数返回值为: 简单字符串+成员变量”
    目前并没有办法规避,不建议这么使用。
  2. 针对这种情况"Log.i(简单字符串+成员变量)"
    我们的解决方案是,在封装的Log工具类方法中,使用变长参数。

下面是一个简单的示例:

package com.github.snowdream.logtest;

import android.text.TextUtils;
import android.util.Log;

/**
 * Created by snowdream on 16-10-22.
 */
public class LogUtil {
    private static final boolean isDebug = BuildConfig.DEBUG;

    public static void i(String tag, String... args) {
        if (isDebug) {
            Log.i(tag, getLog(tag,args));
        }
    }

    public static void d(String tag, String... args) {
        if (isDebug) {
            Log.i(tag, getLog(tag,args));
        }
    }

    public static void v(String tag, String... args) {
        if (isDebug) {
            Log.i(tag, getLog(tag,args));
        }
    }

    public static void w(String tag, String... args) {
        if (isDebug) {
            Log.i(tag, getLog(tag,args));
        }
    }

    public static void e(String tag, String... args) {
        if (isDebug) {
            Log.i(tag, getLog(tag,args));
        }
    }

    private static String getLog(String tag, String... args){
        StringBuilder builder = new StringBuilder();
        for (String arg : args){
            if (TextUtils.isEmpty(arg)) continue;

            builder.append(arg);
        }

        return builder.toString();
    }
}

参考

  1. 如何安全地打印日志
  2. 关于Android Log的一些思考
  3. Androrid应用打包release版时关闭log日志输出
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
13天前
|
缓存 Java Shell
Android 系统缓存扫描与清理方法分析
Android 系统缓存从原理探索到实现。
39 15
Android 系统缓存扫描与清理方法分析
|
4天前
|
JSON 监控 JavaScript
Node.js-API 限流与日志优化
Node.js-API 限流与日志优化
|
4天前
|
存储 Linux Docker
centos系统清理docker日志文件
通过以上方法,可以有效清理和管理CentOS系统中的Docker日志文件,防止日志文件占用过多磁盘空间。选择合适的方法取决于具体的应用场景和需求,可以结合手动清理、logrotate和调整日志驱动等多种方式,确保系统的高效运行。
8 2
|
14天前
|
存储 Java Android开发
Android|记一个导致 logback 无法输出日志的问题
在给一个 Android 项目添加 logback 日志框架时,遇到一个导致无法正常输出日志的问题,这里记录一下。
15 2
|
14天前
|
Java 程序员 API
Android|集成 slf4j + logback 作为日志框架
做个简单改造,统一 Android APP 和 Java 后端项目打印日志的体验。
54 1
|
24天前
|
调度 Android开发 开发者
构建高效Android应用:探究Kotlin多线程优化策略
【10月更文挑战第11天】本文探讨了如何在Kotlin中实现高效的多线程方案,特别是在Android应用开发中。通过介绍Kotlin协程的基础知识、异步数据加载的实际案例,以及合理使用不同调度器的方法,帮助开发者提升应用性能和用户体验。
40 4
|
25天前
|
Arthas 监控 Java
JVM知识体系学习七:了解JVM常用命令行参数、GC日志详解、调优三大方面(JVM规划和预调优、优化JVM环境、JVM运行出现的各种问题)、Arthas
这篇文章全面介绍了JVM的命令行参数、GC日志分析以及性能调优的各个方面,包括监控工具使用和实际案例分析。
38 3
|
6天前
|
安全 Android开发 iOS开发
深入探索iOS与Android系统的差异性及优化策略
在当今数字化时代,移动操作系统的竞争尤为激烈,其中iOS和Android作为市场上的两大巨头,各自拥有庞大的用户基础和独特的技术特点。本文旨在通过对比分析iOS与Android的核心差异,探讨各自的优势与局限,并提出针对性的优化策略,以期为用户提供更优质的使用体验和为开发者提供有价值的参考。
|
1月前
|
存储 消息中间件 大数据
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
37 1
|
1月前
|
SQL 存储 关系型数据库
Mysql主从同步 清理二进制日志的技巧
Mysql主从同步 清理二进制日志的技巧
25 1