本文将分享MySQL如何计算统计redolog大小的详细内容，并且还将对mysql计算人数进行详尽解释，此外，我们还将为大家带来关于3000帧动画图解MySQL为什么需要binlog、redolog和

本文将分享MySQL 如何计算统计 redo log 大小的详细内容，并且还将对mysql计算人数进行详尽解释，此外，我们还将为大家带来关于3000 帧动画图解 MySQL 为什么需要 binlog、redo log 和 undo log、Android Log.v()、Log.d()、Log.i()、Log.w()、Log.e() - 什么时候使用它们？、Android Log.v（），Log.d（），Log.i（），Log.w（），Log.e（） - 何时使用每一个？、android.util.Log常用的方法(Log.v,Log.d,Log.i,Log.w,Log.e)的相关知识，希望对你有所帮助。

• MySQL 如何计算统计 redo log 大小（mysql计算人数）
• 3000 帧动画图解 MySQL 为什么需要 binlog、redo log 和 undo log
• Android Log.v()、Log.d()、Log.i()、Log.w()、Log.e() - 什么时候使用它们？
• Android Log.v（），Log.d（），Log.i（），Log.w（），Log.e（） - 何时使用每一个？
• android.util.Log常用的方法(Log.v,Log.d,Log.i,Log.w,Log.e)

MySQL 如何计算统计 redo log 大小（mysql计算人数）

在 MySQL 中如何计算、统计重做日志（redo log) 的生成情况呢？ 例如 10 分钟内，生成了多少 M 的 redo log 呢？30 分钟内又生成了多少 M 的 redo log.....。MySQL 没有像 Oracle 中那样的系统视图统计这些数据，但是我们可以通过一些方法曲线的统计二进制日志的生成量。

虽然我在这篇博客 “MySQL 中 Redo Log 相关的重要参数总结” 中介绍了，MySQL 8.0 引入了 innodb_dedicated_server 自适应参数，可基于服务器的内存来动态设置 innodb_buffer_pool_size，innodb_log_file_size 和 innodb_flush_method。默认情况下，此参数是关闭的。但是在 MySQL 8.0 之前，通过计算重做日志（redo log）的生成量来判断判断 innodb_log_buffer_size 和 innodb_log_file_size 的大小是否合适是非常必要的，个人认为即使 MySQL 8.0 版本下，这个也是非常有参考和研究意义的。我们通过统计、分析计算重做日志（redo log）的生成量，从而判断 InnoDB 的事务日志文件大概能支撑多长时间就会切换。有具体数据支撑，你才好分析判断，否则巧妇也难为无米之炊。

在 MySQL 的 information_schema.global_status 或 performance_schema.global_status 中有个服务器状态变量 (Server Status Variables）Innodb_os_log_written, 它记录了 Innodb 的重做日志（redo log）的生成量，它记录写入 InnoDB 重做日志文件的字节数，它是一个累积值。官方文档关于此服务器状态变量的描述如下

Innodb_os_log_written

The number of bytes written to the InnoDB redo log files.

我们主要通过一个计划任务 / 事件调度定期的去采集 Innodb_os_log_written 服务器状态变量获取重做日志的大小，将其存储在 innodb_log_size_his 表中，方便分析统计。具体脚本如下：

注意：performance_schema.global_status 是 MySQL 5.7 引入的，而 MySQL 8.0 开始，information_schema.global_status 直接被丢弃了。所以注意 MySQL 版本，选择合适脚本。

USE mysqls;

CREATE TABLE IF NOT EXISTS innodb_log_size_his

(

    log_id          INT AUTO_INCREMENT PRIMARY KEY COMMENT ''日志编号'',

    log_date        DATETIME COMMENT ''记录当前数据的时间'',

    log_size        DOUBLE COMMENT ''redo log的大小,单位为mb''

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT ''redo日志大小信息表'';

--MySQL 5.*版本用下面脚本

DELIMITER &&

DROP PROCEDURE IF EXISTS `Record_Innodb_Log_Size`&&

CREATE PROCEDURE Record_Innodb_Log_Size()

BEGIN

      INSERT INTO mysql.`innodb_log_size_his`

      (

          log_date,

          log_size

      )

      SELECT now() AS log_date,

             ROUND(CAST(VARIABLE_VALUE AS DOUBLE )/1024/1024, 1) as log_size

      FROM information_schema.global_status

      WHERE VARIABLE_NAME = ''innodb_os_log_written'';

END &&

DELIMITER ;

--MySQL 8.0以上版本使用下面脚本

DELIMITER &&

DROP PROCEDURE IF EXISTS `Record_Innodb_Log_Size`&&

CREATE PROCEDURE Record_Innodb_Log_Size()

BEGIN

      INSERT INTO mysql.`innodb_log_size_his`

      (

          log_date,

          log_size

      )

      SELECT now() AS log_date,

             ROUND(CAST(VARIABLE_VALUE AS DOUBLE )/1024/1024, 1) as log_size

      FROM performance_schema.global_status

      WHERE VARIABLE_NAME = ''innodb_os_log_written'';

END &&

DELIMITER ;

然后创建 MySQL 的计划任务 / 事件调度，这个可以根据需求弹性设定。

CREATE EVENT DPA_REDOLOG_SIZE

ON SCHEDULE EVERY 10 MINUTE STARTS ''2020-10-16 08:00:00'' 

ON COMPLETION PRESERVE 

DO CALL mysql.Record_Innodb_Log_Size;

然后你就可以基于这个表做一些简单的分析和统计了，例如，统计 10 分钟内生成重做日志生成了多少。如下所示：

SELECT m.*

      ,@lag  AS last_redo_size

      ,ROUND(m.log_size - @lag,2) AS gen_redo_size

      ,@lag:=log_size

FROM mysql.`innodb_log_size_his` m, (SELECT @lag :='''') AS n

WHERE m.log_date >= date_add(now(), interval -1 day)

ORDER BY m.log_id;

3000 帧动画图解 MySQL 为什么需要 binlog、redo log 和 undo log

全文建立在 MySQL 的存储引擎为 InnoDB 的基础上

先看一条 SQL 如何入库的：

这是一条很简单的更新 SQL，从 MySQL 服务端接收到 SQL 到落盘，先后经过了 MySQL Server 层和 InnoDB 存储引擎。

1. Server 层就像一个产品经理，分析客户的需求，并给出实现需求的方案。
2. InnoDB 就像一个基层程序员，实现产品经理给出的具体方案。

在 MySQL” 分析需求，实现方案 “的过程中，还夹杂着内存操作和磁盘操作，以及记录各种日志。

他们到底有什么用处？他们之间到底怎么配合的？MySQL 又为什么要分层呢？InnoDB 里面的那一块 Buffer Pool 又是什么？

我们慢慢分析。

分层结构

MySQL 为什么要分为 Server 层和存储引擎两层呢？

这个问题官方也没有给出明确的答案，但是也不难猜，简单来说就是为了 “解耦”。

Server 层和存储引擎各司其职，分工明确，用户可以根据不同的需求去使用合适的存储引擎，多好的设计，对不对？

后来的发展也验证了 “分层设计” 的优越性：MySQL 最初搭载的存储引擎是自研的只支持简单查询的 MyISAM 的前身 ISAM，后来与 Sleepycat 合作研发了 Berkeley DB 引擎，支持了事务。江山代有才人出，技术后浪推前浪，MySQL 在持续的升级着自己的存储引擎的过程中，遇到了横空出世的 InnoDB，InnoDB 的功能强大让 MySQL 倍感压力。

自己的存储引擎打不过 InnoDB 怎么办？

打不过就加入！

MySQL 选择了和 InnoDB 合作。正是因为 MySQL 存储引擎的插件化设计，两个公司合作的非常顺利，MySQL 也在合作后不久就发布了正式支持 nnoDB 的 4.0 版本以及经典的 4.1 版本。

MySQL 兼并天下模式也成为 MySQL 走向繁荣的一个重要因素。这能让 MySQL 长久地保持着极强竞争力。时至今日，MySQL 依然占据着极高数据库市场份额，仅次于王牌数据库 Oracle。

Buffer Pool

在 InnoDB 里，有一块非常重要的结构 ——Buffer Pool。

Buffer Pool 是个什么东西呢？

Buffer Pool 就是一块用于缓存 MySQL 磁盘数据的内存空间。

为什么要缓存 MySQL 磁盘数据呢？

我们通过一个例子说明，我们先假设没有 Buffer Pool，user 表里面只有一条记录，记录的 age = 1，假设需要执行三条 SQL：

1. 事务 A：update user set age = 2
2. 事务 B：update user set age = 3
3. 事务 C：update user set age = 4

如果没有 Buffer Pool，那执行就是这样的：

从图上可以看出，每次更新都需要从磁盘拿数据（1 次 IO），修改完了需要刷到磁盘（1 次 IO），也就是每次更新都需要 2 次磁盘 IO。三次更新需要 6 次磁盘 IO。

而有了 Buffer Pool，执行就成了这样：

从图上可以看出，只需要在第一次执行的时候将数据从磁盘拿到 Buffer Pool（1 次 IO），第三次执行完将数据刷回磁盘（1 次 IO），整个过程只需要 2 次磁盘 IO，比没有 Buffer Pool 节省了 4 次磁盘 IO 的时间。

当然，Buffer Pool 真正的运转流程没有这么简单，具体实现细节和优化技巧还有很多，由于篇幅有限，本文不做详细描述。

我想表达的是：Buffer Pool 就是将磁盘 IO 转换成了内存操作，节省了时间，提高了效率。

Buffer Pool 是提高了效率没错，但是出现了一个问题，Buffer Pool 是基于内存的，而只要一断电，内存里面的数据就会全部丢失。

如果断电的时候 Buffer Pool 的数据还没来得及刷到磁盘，那么这些数据就丢失了吗？

还是上面的那个例子，如果三个事务执行完毕，在 age = 4 还没有刷到磁盘的时候，突然断电，数据就全部丢掉了：

试想一下，如果这些丢失的数据是核心的用户交易数据，那用户能接受吗？

答案是否定的。

那 InnoDB 是如何做到数据不会丢失的呢？

今天的第一个日志 ——redo log 登场了。

恢复 - redo log

顾名思义，redo 是重做的意思，redo log 就是重做日志的意思。

redo log 是如何保证数据不会丢失的呢？

就是在修改之后，先将修改后的值记录到磁盘上的 redo log 中，就算突然断电了，Buffer Pool 中的数据全部丢失了，来电的时候也可以根据 redo log 恢复 Buffer Pool，这样既利用到了 Buffer Pool 的内存高效性，也保证了数据不会丢失。

我们通过一个例子说明，我们先假设没有 Buffer Pool，user 表里面只有一条记录，记录的 age = 1，假设需要执行一条 SQL：

1. 事务 A：update user set age = 2

执行过程如下：

如上图，有了 redo log 之后，将 age 修改成 2 之后，马上将 age = 2 写到 redo log 里面，如果这个时候突然断电内存数据丢失，在来电的时候，可以将 redo log 里面的数据读出来恢复数据，用这样的方式保证了数据不会丢失。

你可能会问，redo log 文件也在磁盘上，数据文件也在磁盘上，都是磁盘操作，何必多此一举？为什么不直接将修改的数据写到数据文件里面去呢？

傻瓜，因为 redo log 是磁盘顺序写，数据刷盘是磁盘随机写，磁盘的顺序写比随机写高效的多啊。

这种先预写日志后面再将数据刷盘的机制，有一个高大上的专业名词 ——WAL（Write-ahead logging），翻译成中文就是预写式日志。

虽然磁盘顺序写已经很高效了，但是和内存操作还是有一定的差距。

那么，有没有办法进一步优化一下呢？

答案是可以。那就是给 redo log 也加一个内存 buffer，也就是 redo log buffer，用这种套娃式的方法进一步提高效率。

redo log buffer 具体是怎么配合刷盘呢？

在这个问题之前之前，我们先来捋一下 MySQL 服务端和操作系统的关系：

MySQL 服务端是一个进程，它运行于操作系统之上。也就是说，操作系统挂了 MySQL 一定挂了，但是 MySQL 挂了操作系统不一定挂。

所以 MySQL 挂了有两种情况：

1. MySQL 挂了，操作系统也挂了，也就是常说的服务器宕机了。这种情况 Buffer Pool 里面的数据会全部丢失，操作系统的 os cache 里面的数据也会丢失。
2. MySQL 挂了，操作系统没有挂。这种情况 Buffer Pool 里面的数据会全部丢失，操作系统的 os cache 里面的数据不会丢失。

OK，了解了 MySQL 服务端和操作系统的关系之后，再来看 redo log 的落盘机制。redo log 的刷盘机制由参数 innodb_flush_log_at_trx_commit 控制，这个参数有 3 个值可以设置：

1. innodb_flush_log_at_trx_commit = 1：实时写，实时刷
2. innodb_flush_log_at_trx_commit = 0：延迟写，延迟刷
3. innodb_flush_log_at_trx_commit = 2：实时写，延迟刷

写可以理解成写到操作系统的缓存（os cache），刷可以理解成把操作系统里面的缓存刷到磁盘。

这三种策略的区别，我们分开讨论：

innodb_flush_log_at_trx_commit = 1：实时写，实时刷

这种策略会在每次事务提交之前，每次都会将数据从 redo log 刷到磁盘中去，理论上只要磁盘不出问题，数据就不会丢失。

总结来说，这种策略效率最低，但是丢数据风险也最低。

innodb_flush_log_at_trx_commit = 0：延迟写，延迟刷

这种策略在事务提交时，只会把数据写到 redo log buffer 中，然后让后台线程定时去将 redo log buffer 里面的数据刷到磁盘。

这种策略是最高效的，但是我们都知道，定时任务是有间隙的，但是如果事务提交后，后台线程没来得及将 redo log 刷到磁盘，这个时候不管是 MySQL 进程挂了还是操作系统挂了，这一部分数据都会丢失。

总结来说这种策略效率最高，丢数据的风险也最高。

innodb_flush_log_at_trx_commit = 2：实时写，延迟刷

这种策略在事务提交之前会把 redo log 写到 os cache 中，但并不会实时地将 redo log 刷到磁盘，而是会每秒执行一次刷新磁盘操作。

这种情况下如果 MySQL 进程挂了，操作系统没挂的话，操作系统还是会将 os cache 刷到磁盘，数据不会丢失，如下图：

但如果 MySQL 所在的服务器挂掉了，也就是操作系统都挂了，那么 os cache 也会被清空，数据还是会丢失。如下图：

所以，这种 redo log 刷盘策略是上面两种策略的折中策略，效率比较高，丢失数据的风险比较低，绝大多情况下都推荐这种策略。

总结一下，redo log 的作用是用于恢复数据，写 redo log 的过程是磁盘顺序写，有三种刷盘策略，有 innodb_flush_log_at_trx_commit 参数控制，推荐设置成 2。

回滚 - undo log

我们都知道，InnoDB 是支持事务的，而事务是可以回滚的。

假如一个事务将 age=1 修改成了 age=2，在事务还没有提交的时候，后台线程已经将 age=2 刷入了磁盘。这个时候，不管是内存还是磁盘上，age 都变成了 2，如果事务要回滚，找不到修改之前的 age=1，无法回滚了。

那怎么办呢？

很简单，把修改之前的 age=1 存起来，回滚的时候根据存起来的 age=1 回滚就行了。

MySQL 确实是这么干的！这个记录修改之前的数据的过程，叫做记录 undo log。undo 翻译成中文是撤销、回滚的意思，undo log 的主要作用也就是回滚数据。

如何回滚呢？看下面这个图：

MySQL 在将 age = 1 修改成 age = 2 之前，先将 age = 1 存到 undo log 里面去，这样需要回滚的时候，可以将 undo log 里面的 age = 1 读出来回滚。

需要注意的是，undo log 默认存在全局表空间里面，你可以简单的理解成 undo log 也是记录在一个 MySQL 的表里面，插入一条 undo log 和插入一条普通数据是类似。也就是说，写 undo log 的过程中同样也是要写入 redo log 的。

归档 - binlog

undo log 记录的是修改之前的数据，提供回滚的能力。

redo log 记录的是修改之后的数据，提供了崩溃恢复的能力。

那 binlog 是干什么的呢？

binlog 记录的是修改之后的数据，用于归档。

和 redo log 日志类似，binlog 也有着自己的刷盘策略，通过 sync_binlog 参数控制：

• sync_binlog = 0 ：每次提交事务前将 binlog 写入 os cache，由操作系统控制什么时候刷到磁盘
• sync_binlog =1 ：采用同步写磁盘的方式来写 binlog，不使用 os cache 来写 binlog
• sync_binlog = N ：当每进行 n 次事务提交之后，调用一次 fsync 将 os cache 中的 binlog 强制刷到磁盘

那么问题来了，binlog 和 redo log 都是记录的修改之后的值，这两者有什么区别呢？有 redo log 为什么还需要 binlog 呢？

首先看两者的一些区别：

• binlog 是逻辑日志，记录的是对哪一个表的哪一行做了什么修改；redo log 是物理日志，记录的是对哪个数据页中的哪个记录做了什么修改，如果你还不了解数据页，你可以理解成对磁盘上的哪个数据做了修改。
• binlog 是追加写；redo log 是循环写，日志文件有固定大小，会覆盖之前的数据。
• binlog 是 Server 层的日志；redo log 是 InnoDB 的日志。如果不使用 InnoDB 引擎，是没有 redo log 的。

但说实话，我觉得这些区别并不是 redo log 不能取代 binlog 的原因，MySQL 官方完全可以调整 redo log 让他兼并 binlog 的能力，但他没有这么做，为什么呢？

我认为不用 redo log 取代 binlog 最大的原因是 “没必要”。

为什么这么说呢？

第一点，binlog 的生态已经建立起来。MySQL 高可用主要就是依赖 binlog 复制，还有很多公司的数据分析系统和数据处理系统，也都是依赖的 binlog。取代 binlog 去改变一个生态费力了不讨好。

第二点，binlog 并不是 MySQL 的瓶颈，花时间在没有瓶颈的地方没必要。

总结

总结一下：

1. Buffer Pool 是 MySQL 进程管理的一块内存空间，有减少磁盘 IO 次数的作用。
2. redo log 是 InnoDB 存储引擎的一种日志，主要作用是崩溃恢复，有三种刷盘策略，有 innodb_flush_log_at_trx_commit 参数控制，推荐设置成 2。
3. undo log 是 InnoDB 存储引擎的一种日志，主要作用是回滚。
4. binlog 是 MySQL Server 层的一种日志，主要作用是归档。
5. MySQL 挂了有两种情况：操作系统挂了 MySQL 进程跟着挂了；操作系统没挂，但是 MySQL 进程挂了。

最后，再用一张图总结一下全文的知识点：

Android Log.v()、Log.d()、Log.i()、Log.w()、Log.e() - 什么时候使用它们？

不同的LogCat方法是：

Log.v(); // VerboseLog.d(); // DebugLog.i(); // InfoLog.w(); // WarningLog.e(); // Error

使用每种类型的 Logging 的合适情况是什么？我知道这也许只是一点点语义，也许并不重要，但对于LogCat在 Android Studio 和
Eclipse 中进行过滤，很高兴知道我在适当的时间使用了正确的方法。

答案1

让我们以相反的顺序进行：

• Log.e ：这是为了当坏事发生时。在 catch 语句中等位置使用此标记。您 知道 发生了 错误 ，因此您正在记录错误。

• Log.w ：当您怀疑发生了一些可疑的事情时使用它。你可能没有完全进入错误模式，但也许你从一些意想不到的行为中恢复过来。基本上，使用它来记录您不希望发生但不一定是错误的事情。有点像“嘿，这件事发生了，很 奇怪 ，我们应该调查一下。”

• Log.i ：使用它来将有用 的信息 发布到日志中。例如：您已成功连接到服务器。基本上用它来报告成功。

• Log.d ：将其用于 调试 目的。如果您想打印出一堆消息以便记录程序的确切流程，请使用它。如果要保留变量值的日志，请使用它。

• Log.v ：当你想对你的日志完全疯狂时使用它。如果出于某种原因您决定在应用程序的特定部分中记录每一件小事，请使用 Log.v 标记。

作为奖励…

• Log.wtf ：当事情绝对，可怕，神圣的废话错误时使用它。你知道那些你在捕捉你 永远不 应该得到的错误的 catch 块......是的，如果你想记录它们，请使用 Log.wtf

Android Log.v（），Log.d（），Log.i（），Log.w（），Log.e（） - 何时使用每一个？

不同的LogCat方法是：

Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // Error

使用每种类型的日志记录的适当情况是什么？ 我知道也许这只是一些语义，也许它并不重要，但对于Android Studio和Eclipse中的LogCat过滤，我很高兴知道我在适当的时候使用了正确的方法。

#1楼

源代码提供了一些基本指导：

详细程度的顺序，从最小到最多，是ERROR，WARN，INFO，DEBUG，VERBOSE。 除了在开发期间，不应该将详细编译到应用程序中。 调试日志在运行时编译但被剥离。 始终保留错误，警告和信息日志。

更多细节，Kurtis的答案已经过去了。 我想补充一点：不要在INFO或以上（ WARN / ERROR ）记录任何个人身份信息或私人信息。 否则，错误报告或包含日志记录的任何其他内容可能会受到污染。

#2楼

Android Studio网站最近（我认为）提供了一些建议，从Kurtis的回答中可能有用的不同日志级别期望什么样的消息：

• 详细 - 显示所有日志消息（默认）。
• 调试 - 显示仅在开发期间有用的调试日志消息，以及此列表中较低的消息级别。
• 信息 - 显示常规使用的预期日志消息，以及此列表中较低的消息级别。
• 警告 - 显示尚未出现错误的可能问题，以及此列表中较低的消息级别。
• 错误 - 显示导致错误的问题，以及此列表中较低的消息级别。
• 断言 - 显示开发人员期望永远不会发生的问题。

#3楼

你可以使用LOG如：

Log.e(String, String) (error)
Log.w(String, String) (warning)
Log.i(String, String) (information)
Log.d(String, String) (debug)
Log.v(String, String) (verbose)

示例代码：

private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);

#4楼

虽然这个问题已经回答了，但我觉得答案中有缺少的例子。

因此，我将把我在博客文章“Android Log Levels”中写的内容带到这里

详细

是最低级别的日志记录。 如果你想坚持记录，那么你就可以使用这个级别了。 我从来不知道何时使用Verbose以及何时使用Debug。 差别对我来说非常武断。 一旦我指出Android¹的源代码，我终于理解了“除了在开发过程中，不应该将Verbose编译成应用程序。”现在我很清楚，无论何时开发并想要添加可删除的日志来帮助你开发有用的是详细级别，这有助于您在投入生产之前删除所有这些日志。

调试

用于调试目的。 这是生产中应该达到的最低水平。 这里的信息是在开发过程中提供帮助。 大多数情况下，您将禁用此生产日志，以便发送较少的信息，并且只有在出现问题时才启用此日志。 我喜欢登录调试应用程序从服务器发送/接收的所有信息（注意不要记录密码!!!）。 这对于了解错误是在服务器还是应用程序中非常有帮助。 我还会记录进入和退出重要功能的日志。

信息

有关突出显示应用程序进度的信息性消息。 例如，当应用程序的初始化完成时。 当用户在活动和片段之间移动时添加信息。 记录每个API调用，但只记录URL，状态和响应时间等信息。

警告

当存在潜在的有害情况时。

这个日志在我的经历中是一个棘手的水平。 你什么时候有潜在的有害情况？ 一般情况下或它是好的或它是一个错误。 我个人不太喜欢这个级别。 我使用它的例子通常是多次发生的事情。 例如，用户的密码错误超过3次。 这可能是因为他错误地输入了3次密码，也可能是因为我们的系统中没有接受某个字符存在问题。 网络连接问题也是如此。

错误

错误事件。 错误后应用程序仍可继续运行。 这可能是例如当我得到一个空指针，我不应该得到一个。 解析服务器的响应时出错。 从服务器收到错误。

WTF（多么可怕的失败）

致命是导致应用程序退出的严重错误事件。 在Android中，致命的是实际上的错误级别，不同之处在于它还添加了fullstack。

#5楼

我们按相反顺序进行：

• Log.e ：这是为了发生坏事。 在catch语句中使用此标记。 您知道发生了错误 ，因此您正在记录错误。

• Log.w ：当你怀疑阴影正在发生时使用它。 您可能无法在错误模式下完全完整，但也许您从某些意外行为中恢复过来。 基本上，使用它来记录您不希望发生的事情，但不一定是错误。 有点像“嘿，这发生了，而且很奇怪 ，我们应该调查它。”

• Log.i ：使用此命令将有用信息发布到日志中。 例如：您已成功连接到服务器。 基本上用它来报告成功。

• Log.d ：用于调试目的。 如果要打印出大量消息，以便记录程序的确切流程，请使用此方法。 如果要保留变量值的日志，请使用此选项。

• Log.v ：当您想要完全记录日志时使用此选项。 如果由于某种原因您决定在应用程序的特定部分记录每个小东西，请使用Log.v标记。

作为奖励......

• Log.wtf ：当东西绝对可怕时，使用这个，可怕的，神圣的错误。 你知道那些捕获块，你捕获的错误，你永远不会得到...是的，如果你想记录它们使用Log.wtf

android.util.Log常用的方法(Log.v,Log.d,Log.i,Log.w,Log.e)