介绍

这是一篇来自CCS2017的文章《Keep me Updated: An Empirical Study of Third-Party Library Updatability on Android》

贡献

对来自Google Play的203名应用程序开发人员进行了一项调查，以收集关于库使用情况的第一手信息，并确定开发人员不更新其依赖关系的根本原因。
分析了库版本，以发现库开发人员可能是导致库适应性差的一个因素。在所有库更新中，58%的源于语义版本控制的预期更改与实际库代码更改不匹配。
对1264118个应用程序进行了大规模分析，以确定库及其API使用情况。
深入讨论了应用生态系统中不同实体的短期/长期可操作项，以解决过时库的问题。

应用开发者调查

主要对应用开发者集中于三个问题：

搜索和将第三方库集成到应用程序中的通用工作流是什么？
开发人员更新应用程序/库的频率如何，他们更新的主要动机是什么？
不更新依赖项的可能原因是什么，应用程序开发人员可以想到什么解决方案？

工作流和集成

测量角度：
1）参与者搜索库的主要来源
在这里插入图片描述
2）选择库的标准

3）参与者的主要开发环境

4）应用程序集成方法

应用程序和库维护

测量角度：
1）应用程序/库更新的频率问题
在这里插入图片描述
2）参与者发布应用时间间隔

3）调查参与者更新应用程序及其应用程序库的原因

过时库原因

测量角度：
1）对Gradle构建系统的满意度
在这里插入图片描述
2）应用程序包含过时库的原因

3）使库更新更容易的首选改进

4）参与者接受终端用户设备上的自动库更新

库发布分析

语义版本

普雷斯顿·沃纳（Preston Werner）提出了将版本号分类为不同类别以推断预期集成努力的概念，称为语义版本控制。首先，库开发人员声明公共API，例如通过记录它。然后，记录的公共API中的任何更改都会与版本号进行通信。版本格式由三个数字组成：X.Y.Z（Major.Minor.Patch）。每当新版本包含不影响API的错误修复或代码更改时，补丁版本号将递增。

Android库版本控制

对于预期的更改，通过扩展了LibScout工具，并集成了一个版本解析器，它将版本字符串表示的版本更改分类为补丁、次要和主要版本。通过比较连续的库版本，然后检索预期更改的列表，例如，紧随2.3.7版本之后的2.4.1版本被归类为次要版本。
对于实际更改，语义版本控制要求公共库API必须在某个时候正确定义，要么通过显式文档，要么通过代码本身。由于一些库要么缺乏完整的文档，要么不提供其API引用的历史记录，因此我们通过编程方式从原始库SDK中提取公共API。数据集中每个库的第一个版本的公共API集用作基线。

过滤未记录的API。通过编程的方法，过滤没有被记录的API。为此，排除了位于名为internal的子包中的公共方法。此外，通过ProGuard等混淆工具重命名和缩短的类（及其声明的方法）进行过滤。具体地说，认为使用一个或两个小写字母字符命名的类是模糊的（遵循ProGuard的重命名规则）。
定义实际变化。运用API差异算法，定义两个公共API api[^old] 和api[^new] ，其中api[^old] 是api[^new] 的直接版本前驱。API由其签名来描述，包括包和类名以及参数和返回类型的列表，如com.facebook.Session.getAccessToken()java.lang.String。
如果api[^old] =api[^new] 时，如果有一个补丁级别的版本，那么只有代码改变。
如果api[^old] ? api[^new] 时，新的API就会被添加，但现有的API不会改变。
当api[^old] 包含api[^new] 未包含的API时，会进行类型分析，以检查api[^new]中的兼容对应项

语义版本统计

测量角度：
1）版本控制正确性：
在80%以上的版本中，只有3/89个库（3.4%）正确分类了版本级别，android oauth客户端库排名第一（93.8%）。另一方面，在不到20%的情况下，10/89（11.2%）的库正确指定了版本字符串。
2）预期变化和实际变化之间的不匹配问题
在这里插入图片描述
3）按补丁/次要/主要分组的连续库版本之间的预期和实际更改总数。