30分钟轻松搞定代码瘦身

导语

当一个新的产品想要复用一个旧的产品的逻辑的时候，是直接把全盘的代码copy过去就可以了吗？站在功能的角度当然没问题，但是这对于新产品是相当臃肿的，因为一些它根本不会使用的功能代码也包含在里面。同样对于旧产品而言，随着功能日积月累的变更，有些功能已经废弃，但是代码仍然在工程中，那我们应该怎样快速高效的给代码瘦身呢？半个小时，三个步骤，轻松搞定！

一、背景

• 根源

FT有需求，要把一个完整的功能（插件）作为一个sdk移植到其他项目。

• 实现方式

将插件A以及与插件A有依赖关系的所有插件一并合入。

• 带来的问题

有大量sdk不会使用的功能代码一并合入，导致sdk中含有大量的冗余代码和冗余资源。

二、思索中寻找解决方案

当前时间很紧，如何可以在短时间内，成本最低的解决呢？在思考的过程想到了2个方法。

方法一：通过代码覆盖率

准备开始做这件事的时候，第一个想到的方法是代码覆盖率，觉得最直接的方式是将该sdk的功能用例全部跑一遍，通过EC和EM看究竟哪些路径会被覆盖到，然后删除未被覆盖到的路径。但是当时碰到的问题有：

（1） 打包问题：使用的是手机管家的框架，而很早之前手管的框架就已经支持了打代码覆盖率的包，通过配置来控制，所以觉得理所当然的使用RDM配置一下就能打出来，但是事实是打的过程中一直失败，最后再本地编译，花费了开发GG将近1天的时间调试+删除，才打出来一个包。

（2） 执行耗时问题：

• 业务紧张：当时业务处于FT集成，没有人力来进行多轮的功能测试。
• 分析耗时：功能测试用例并不能百分之百的覆盖到所有的分支，这是由于目前的代码覆盖率是函数级别，导致得出结果之后，还需要进一步分析，没覆盖到的代码到底是异常路径，还是真正的冗余代码，面对代码行数的量级为10w+的插件，这种分析显然会很慢。
• EC生成要求条件较高：在生成EC的过程中，如果出现crash等因素，会导致EC无法使用。

结论：该方法不适合初期，代码量大，范围很广的时候做，比较适合已经确定有哪些file，有哪些class，细究method内部实现时使用。

所以该方法被否决。

方法二：通过静态扫描代码之间的调用关系：

总共安装试用了2款工具，只是用了比较浅的功能，以我的目的为需求，我要获得整个工程下面的所有的代码之间的调用关系，对比见下图：

通过以上对比，我毫不犹豫的选择了doxygen+graphviz的组合，满足我当前的需求。

understand官网：https://scitools.com/，有兴趣的同学可自行了解。

三、实践篇

3.1工具安装

1. 安装包下载地址，见官网：

Doxygen：http://www.stack.nl/~dimitri/doxygen/

Graphviz：http://www.graphviz.org/

本文描述的都是windows版本，如有同学对linux和mac感兴趣，请自行试用。

2. 先安装graphviz，要记住安装路径。

3. 再安装doxygen。

3.2工具使用

1. 设置project的相关属性

2. 选择语言

3. 选择使用graphviz来绘制图表

4. 设置提取范围

每个字段的具体含义请查看官网说明：http://www.doxygen.nl/config.html

5. 由于使用到了Graphviz，所以要设置Dot选项，勾选HAVE_DOT，并设置DOT_PATH为Graphviz的bin目录。

6. 运行

7. 查看结果

3.3冗余定位

1. 寻找孤立的结点

2. 点击孤立的结点查看详情，是否存在调用关系

3. 一般来说如果不存在调用关系的都为冗余

4. 存在这种调用关系的需要进一步确认是否业务逻辑有用到，还是一起迁移进来的功能用到，确定后删除即可

3.4数据统计

1. 每做一轮，需要统计看扫描的效果如何，那如果统计呢？代码是放在svn的，是不是可以从这里入手呢？按照这样的思路，找到了可以统计svn代码行数的工具：Statsvn，下载地址：http://statsvn.org/downloads.html

l 在工程目录下（必须安装有svn）：svn log -v --xml > logfile.log

l 然后运行statsvn获取代码行数：

l 结果见下图，加载较慢，耐心等待，统计的有总的文件数，行数，每天代码行数，开发者提交数等等的信息，提取出自己需要的内容就ok了：

l 删除之前，删除之后分别做一遍，就可以得到删减的代码行数

2. 获益，我做了三轮，总收益还是相当可观的。

3.5资源冗余

资源冗余让我头疼了一阵，资源，尤其是图片，原理很简单就是扫描代码中哪些资源又被调用，哪些没被调用，有没有什么好的工具可以使用呢？在一个很巧合的情况下，咨询了一位资深的开发GG，发现eclipse中有个神器叫lint。

Android lint是在ADT 16提供的新工具，它是一个代码扫描工具，能够帮助我们识别代码结构存在的问题，主要包括：

1）布局性能（以前是 layoutopt工具，可以解决无用布局、嵌套太多、布局太多）

2）未使用到资源

3）不一致的数组大小

4）国际化问题（硬编码）

5）图标的问题（重复的图标，错误的大小）

6）可用性问题（如不指定的文本字段的输入型）

7）manifest文件的错误

更多lint详细，请查看官网：http://tools.android.com/tips/lint-checks

这完全满足我的需求，于是开始动手。

1. 检查没有使用到的资源

2. 收益，总共扫描了4轮，图片资源删除了60个之多。

3.6总收益

冗余资源和冗余代码总共减少了sdk的1/3的大小。

四、下一步应该做什么？

以上的结果全部都是静态扫描，就目前来看sdk的大小仍然是不够好的，那么下一步应该要怎么做才能使得sdk瘦身成功呢？

• 加入动态检查，例如代码覆盖率，单元测试等等，补充静态扫描的缺陷，能够精确到method的每个分支等。
• 资源图片的整合，压缩等等
• ……