android中logcat打印输出结果不完整,超出上限

本文解决Logcat内存限制导致的日志信息丢失问题,并介绍了一个自定义的日志输出类LogUtil,该类通过分段输出长字符串以避免Logcat内存溢出。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天写代码的时候,服务器返回的json数据量比较大,然后我想在logcat中完全输出服务器返回的Json格式的字符串事,发现logcat中返回的信息中明显少了后面一节,刚开始还以为程序有bug,调试了好半天才发现原来程序没有bug,而是LogCat中的每次的Msg输出是有上限的,坑的我好惨啊,查了资料才发现,.原来logcat在实现上对于message的内存分配大概是4k左右.所以超过的内容都直接被丢弃;

于是自己封装了一个属于自己的LogUtil类,代码如下:


public class LogUtil {

    //可以全局控制是否打印log日志
    private static boolean isPrintLog = true;
    private static int LOG_MAXLENGTH = 2000;


    public static void v(String msg) {
        v("LogUtil", msg);
    }

    public static void v(String tagName, String msg) {
        if (isPrintLog) {
            int strLength = msg.length();
            int start = 0;
            int end = LOG_MAXLENGTH;
            for (int i = 0; i < 100; i++) {
                if (strLength > end) {
                    Log.v(tagName + i, msg.substring(start, end));
                    start = end;
                    end = end + LOG_MAXLENGTH;
                } else {
                    Log.v(tagName + i, msg.substring(start, strLength));
                    break;
                }
            }
        }
    }

    public static void d(String msg) {
        d("LogUtil", msg);
    }
    public static void d(String tagName, String msg) {
        if (isPrintLog) {
            int strLength = msg.length();
            int start = 0;
            int end = LOG_MAXLENGTH;
            for (int i = 0; i < 100; i++) {
                if (strLength > end) {
                    Log.d(tagName + i, msg.substring(start, end));
                    start = end;
                    end = end + LOG_MAXLENGTH;
                } else {
                    Log.d(tagName + i, msg.substring(start, strLength));
                    break;
                }
            }
        }
    }

    public static void i(String msg) {
        i("LogUtil", msg);
    }

    public static void i(String tagName, String msg) {
        if (isPrintLog) {
            int strLength = msg.length();
            int start = 0;
            int end = LOG_MAXLENGTH;
            for (int i = 0; i < 100; i++) {
                if (strLength > end) {
                    Log.i(tagName + i, msg.substring(start, end));
                    start = end;
                    end = end + LOG_MAXLENGTH;
                } else {
                    Log.i(tagName + i, msg.substring(start, strLength));
                    break;
                }
            }
        }
    }

    public static void w(String msg) {
        w("LogUtil", msg);
    }

    public static void w(String tagName, String msg) {
        if (isPrintLog) {
            int strLength = msg.length();
            int start = 0;
            int end = LOG_MAXLENGTH;
            for (int i = 0; i < 100; i++) {
                if (strLength > end) {
                    Log.w(tagName + i, msg.substring(start, end));
                    start = end;
                    end = end + LOG_MAXLENGTH;
                } else {
                    Log.w(tagName + i, msg.substring(start, strLength));
                    break;
                }
            }
        }
    }

    public static void e(String msg) {
        e("LogUtil", msg);
    }
    public static void e(String tagName, String msg) {
        if (isPrintLog) {
            int strLength = msg.length();
            int start = 0;
            int end = LOG_MAXLENGTH;
            for (int i = 0; i < 100; i++) {
                if (strLength > end) {
                    Log.e(tagName + i, msg.substring(start, end));
                    start = end;
                    end = end + LOG_MAXLENGTH;
                } else {
                    Log.e(tagName + i, msg.substring(start, strLength));
                    break;
                }
            }
        }
    }

}



问题解决了,做个笔记。

### Android Studio 编写的 App 闪退原因及解决方案 #### 一、常见闪退原因分析 1. **Debug 和 Release 模式的差异** 如果在 Android Studio 的主界面左下角的 “Build Variants” 中选择了 Debug 模式,可能会导致某些优化未生效,从而引发闪退。将 Build Variant 修改为 Release 后重新构建项目通常能解决问题[^2]。 2. **API 版本匹配** 当模拟器使用的 API 版本与 `build.gradle` 文件中指定的 `compileSdkVersion` 或 `targetSdkVersion` 一致时,可能导致兼容性问题并引起闪退。例如,如果模拟器使用的是 API 29 而项目的 Gradle 文件却指定了 API 30,则需要调整 Sdk Version 和 Target Version 至相同版本[^3]。 3. **第三方库初始化异常** 初始化第三方 SDK(如 Bmob 数据库)时可能触发错误。例如,调用 `Bmob.initialize()` 方法后可能出现 `sources code does not match the bytecode` 错误。这种情况下应检查模拟器和编译环境的 API 是否一致,并确保依赖项正确配置。 4. **静态接口方法的支持限制** 使用静态接口方法时,若目标设备的操作系统低于 Android N (API Level 24),则会抛出 `Static interface methods are only supported starting with Android N (--min-api 24)` 错误。此时需升级最低支持版本或将代码逻辑改为动态实现方式[^3]。 5. **SELinux 配置当** 在嵌入式开发板环境中调试 APP 时,SELinux 默认处于 enforcing 模式,这可能阻止部分操作而导致闪退。可以通过修改 `/rk3568_android_sdk/kernel/.config` 将 SELinux 设置为 permissive 模式或者通过命令行设置 `setenforce 0` 来临时禁用强制策略[^4]。 6. **Dex 方法数量超出限制** 对于较老版本的 Android 系统(如 4.4 及以下),单个 APK 文件内的方法总数得超过 65535(即 64K)。当应用规模较大时容易突破此限制,进而发生无法加载类的现象。Google 提供了 MultiDex 技术作为应对方案来分割 dex 文件[^5]。 7. **资源文件冲突或缺失** 若布局 XML 文件存在语法错误、引用存在的图片或其他资源也可能造成崩溃现象。务必仔细核查 res 目录下的所有资源定义是否准确无误。 --- #### 二、具体排查流程 以下是针对以上提到的各种可能性所设计的一套通用诊断步骤: 1. 查看 Logcat 日志输出,定位具体的 Exception 类型及其堆栈信息; 2. 根据日志提示确认是否存在外部服务集成失败情况,比如网络请求框架 Retrofit/Firebase 初始话过程是否有异常; 3. 审核 manifest 清单声明权限是否齐以及 activity 注册是否遗漏; 4. 测试同物理机型/虚拟机组合验证是否属于特定硬件架构适配难题; 5. 更新 gradle 插件到最新稳定版以获得更好的性能表现和支持特性改进; 6. 实施 multidex 支持机制扩展可容纳更多 method count 上限范围; --- #### 三、代码实例展示 下面给出一段关于如何开启 Multidex 功能的例子: ```gradle // build.gradle 文件片段 android { ... defaultConfig { multiDexEnabled true // 开启MultiDex选项 } } dependencies { implementation 'com.android.support:multidex:1.0.3' } // Application 子类重载 attachBaseContext 函数 @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); // 加载额外dex档案 } ``` --- ###
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值