1、易用性

简单易用的框架，可以事半功倍。

易用性，是框架的一个重要特征。因此，不管使用什么框架，它都应该得到考虑。

就日志框架而言，一旦选定，项目团队中的每一个人在开发后期都会经常使用。如果不容易使用的话，这是一个噩梦。

因此，在选择日志框架的时候，应该尽量寻找由简单、直观API实现的方案。

衡量标准可参考：对于缺乏经验的团队成员来说，在查看文档和简单示例后，就能够上手。

2、性能(效率)

功能决定当下，性能决定未来。

要考虑的另一个重要因素是性能影响。我们频繁地调用日志，这对程序的性能有很大影响。

所以，当评估日志框架时，可以参考网上的一些文章进行对比，或者自己做一些对比试验(基准)，

比如，吞吐量-测量每秒可以完成多少次方法调用(越高越好);采样-测量每次调用执行究竟花费了多少时间(越低越好)。

3、对现有代码的影响

影响越小，越容易维护。

日志在今后的使用中将无处不在。这会影响运行时性能，同时也会影响源码的可维护性。

就应用程序的角度来看，日志的位置比较尴尬。这样说的原因是，我们尽力隔离依赖性，提供良好的接口和较小化耦合，在编程时考虑的是单一的职责原则。然后，日志就出现了，它无处不在，与周围的代码无关。和的设计原则相比，日志似乎有点不对劲。

所以，应该充分考虑到引入日志的影响范围，尽可能地减少对代码的修改!

此外，就是老生常谈的发展前景和社区支持了。这两个很好理解，如果一个发展渺茫的日志框架你会使用吗?肯定会被淘汰，到时候还需要再换一个框架。

另一个是社区支持，一个好的社区支持是重要的，当我们遇到问题的时候，会有相应的解决办法，更多的可能在短时间内解决问题。