又一次我们是幸运的，我们能够重用 V8 中的现有信息。由于 Function.prototype.toString 需要知道函数在原文件中的位置以提取适当的子字符串，函数已经知道它们在源代码中的起始位置和结束位置。
在收集到最优的覆盖范围时，这两种机制简单地结合在一起：首先，我们通过遍历整个堆来找到所有存活的函数。对于每个可见的函数，我们报告调用次数（存储在反馈向量中，我们可以从函数中访问）和源范围（方便存储在函数本身）。
请注意，由于无论是否启用 coverage，都会维护调用计数，因此尽力服务的覆盖不会引入任何运行时开销。它也不使用专用的数据结构，因此既不需要显式启用也无需显式禁用。
那么为什么这种模式称为尽力服务(best-effort)呢，它的局限性是什么？ 超出范围的函数可能会被垃圾回收器释放掉。这意味着相关的调用计数将会丢失，事实上我们完全忘记了这些函数曾经存在过。 因此“尽力服务”：即使我们尽力了，所收集的覆盖信息也可能不完整。
精准覆盖 (函数粒度)
与尽力服务模式相比，精确覆盖可确保所提供的覆盖信息是完整的。为实现这一目标，我们会在启用精准覆盖后将所有反馈向量添加到V8的根参考集中，从而阻止GC对其进行回收。虽然这确保了信息无丢失，但它通过人为地保持对象存活增加内存开销。
精准覆盖模式还可以提供执行计数。这为精准覆盖实施增加了另一个窍门。回想一下，每次通过V的解释器调用函数时，调用计数器都会递增，并且一旦函数访问频率过高，这些函数就可以升级并进行优化。 但优化的函数不再增加其调用计数器，因此必须禁用优化编译器，以使其报告的执行次数保持准确。
精准覆盖（块粒度）
块粒度覆盖必须报告准确到独立表达式层级的覆盖范围。例如，在下面的一段代码中，块覆盖可以检测到条件表达式的else分支: c从不执行，而函数粒度覆盖只会知道函数 f（作为一个整体）被覆盖了。
function f(a) { return a ? b : c; } f(true);
你可能从前面的部分想起我们已经在 V8 中提供了函数调用次数和源码范围。不幸的是，这不适合块覆盖的场景，我们必须实现新的机制来收集执行次数和它们相应的源码范围。
第一个方面是源码范围：假设我们拥有一个特定块的执行计数，我们如何将它们映射到源代码的一部分呢？ 为此，我们需要在解析源文件时收集相关位置信息。在块覆盖之前，V8已经在某种程度上做到了这一点。一个示例是由如上所述的Function.prototype.toString而触发的函数范围的收集。
另一个例子是用于构造Error对象的回溯的源码位置。但这些都不足以支持块覆盖; 前者仅适用于函数，而后者仅保存位置信息（例如if-else语句的if标记的位置），而不是源码范围。
因此，我们必须扩展解析器以收集源码范围。为了演示，假设我们正在使用if-else语句：
if (cond) { /* Then branch. */ } else { /* Else branch. */ }
当启用块覆盖时，我们收集 then 和 else 分支的源码范围，并将它们与已解析的 IfStatement AST 节点相关联。其他相关语言结构也是如此处理。
在解析过程中收集完源码范围集之后，第二个方面是在运行时跟踪执行计数。 这是通过在生成的字节码数组的关键位置插入新的专用 IncBlockCounter 字节码来完成的。在运行时，IncBlockCounter 字节码处理程序只是增加对应的计数器接口（可通过函数对象访问）。
在 if-else 语句的上述示例中，这样的字节码将被插入在三个位置：紧接在 then 分支的主体之前，在 else 分支的主体之前，紧接在 if-else 语句之后（由于分支内可能存在非本地控制，因此需要连续的计数器）。
最后，报告块粒度覆盖与函数粒度报告类似。但除了调用计数（来自反馈向量）之外，我们现在还报告了感兴趣的源范围的集合以及它们的块计数（存储在挂起该函数的辅助数据结构中）。