objective-c 如何在Objective-C中检测未使用的方法和#import

How to detect unused methods and #import in Objective-C

提问by Hectoret

After working a long time on an iPhone app, I realized that my code is quite dirty, containing several #import and methods that are not called or useful at all.

在 iPhone 应用程序上工作了很长时间后，我意识到我的代码很脏，包含几个 #import 和根本没有调用或有用的方法。

I would like to know if there's any compiler directive or way to detect those useless lines of code. Does Xcode have any tool to detect this?

我想知道是否有任何编译器指令或方法来检测那些无用的代码行。Xcode 是否有任何工具可以检测到这一点？

回答by Quinn Taylor

Xcode allows you to (un)check settings for specific compiler warnings that can warn you of some types of unused code. (Select the project in the source list and File > Get Info, then select the Build tab.) Here are a few (which show up for Clang and GCC 4.2 for me) which may be of interest:

Xcode 允许您（取消）检查特定编译器警告的设置，这些警告可以警告您某些类型的未使用代码。（在源列表中选择项目，然后选择 File > Get Info，然后选择 Build 选项卡。）这里有一些（对我来说显示为 Clang 和 GCC 4.2）可能会感兴趣：

• Unused Functions
• Unused Parameters
• Unused Values

• 未使用的功能
• 未使用的参数
• 未使用的值

I don't see any options for detecting unused imports, but that is a bit simpler — the low-tech approach is just to comment out import statements until you get a compile error/warning.

我没有看到任何用于检测未使用导入的选项，但这有点简单 - 低技术方法只是注释掉导入语句，直到您收到编译错误/警告。

Unused Objective-C methods are much more difficult to detect than unused C functions because messages are dispatched dynamically. A warning or error can tell you that you have a potential problem, but the lack of one doesn't guarantee you won't have runtime errors.

未使用的 Objective-C 方法比未使用的 C 函数更难检测，因为消息是动态分派的。警告或错误可以告诉您存在潜在问题，但没有警告或错误并不能保证您不会出现运行时错误。

---

---

Edit:Another good way to detect (potentially) unused methods is to examine code coverage from actual executions. This is usually done in tandem with automated unit testing, but doesn't have to be.

编辑：检测（可能）未使用的方法的另一种好方法是检查实际执行中的代码覆盖率。这通常与自动化单元测试一起完成，但并非必须如此。

This blog postis a decent introduction to unit testing and code coverage using Xcode. The section on gcov(which only works with code generated by GCC, by the way) explains how to get Xcode to build instrumented code that can record how often it has been executed. If you take an instrumented build of your app for a spin in the simulator, then run gcov on it, you can see what code was executed by using a tool like CoverStory(a fairly simplistic GUI) or lcov(Perl scripts to create HTML reports).

这篇博文很好地介绍了使用 Xcode 进行单元测试和代码覆盖率。上的部分gcov（顺便说一下，它仅适用于 GCC 生成的代码）解释了如何让 Xcode 构建可以记录执行频率的检测代码。如果您将应用程序的检测构建用于模拟器中的旋转，然后在其上运行 gcov，您可以使用像CoverStory（相当简单的 GUI）或lcov（用于创建 HTML 报告的 Perl 脚本）之类的工具查看执行了哪些代码.

I use gcovand lcovfor CHDataStructures.frameworkand auto-generate coverage reportsafter each SVN commit. Again, remember that it's unwise to treat executed coverage as a definitive measure of what code is "dead", but it can certainly help identify methods that you can investigate further.

我使用gcov和lcov用于CHDataStructures.framework并在每次 SVN 提交后自动生成覆盖率报告。同样，请记住，将执行覆盖率视为对哪些代码“死”的明确衡量标准是不明智的，但它肯定有助于确定可以进一步调查的方法。

Lastly, since you're trying to remove dead code, I think you'll find this SO question interesting as well:

最后，由于您正在尝试删除死代码，我想您会发现这个 SO 问题也很有趣：

• Profiling Objective-C binary image size

• 分析 Objective-C 二进制图像大小

回答by patrick-fitzgerald

Appcodehas a code inspection feature which finds unused imports and code.

Appcode具有代码检查功能，可查找未使用的导入和代码。

回答by dB.

We've been using some homegrown Ruby code, now extracted into a gem called fui: https://github.com/dblock/fui

我们一直在使用一些本土的 Ruby 代码，现在提取到一个名为 fui 的 gem 中：https: //github.com/dblock/fui

回答by Orangenhain

I recently wrote a script to find unused (or duplicate) #importstatements: https://gist.github.com/Orangenhain/7691314

我最近写了一个脚本来查找未使用（或重复）的#import语句：https: //gist.github.com/Orangenhain/7691314

The script takes an ObjC .m file and starts commenting out each #importline in turn and seeing if the project still compiles. You will have to change BUILD_DIR & BUILD_CMD.

该脚本采用 ObjC .m 文件并开始#import依次注释掉每一行并查看项目是否仍能编译。您将不得不更改 BUILD_DIR 和 BUILD_CMD。

If you are using a findcommand to let the script run over multiple files, make sure to use a BUILD_CMD that actually usesall those files (or you will see a file with lots of unused import statements).

如果您使用find命令让脚本在多个文件上运行，请确保使用实际使用所有这些文件的 BUILD_CMD （否则您将看到一个包含许多未使用的导入语句的文件）。

I wrote this without knowing AppCode has a similar feature, however when I tested AppCode it was not as thorough as this script (but way faster [for a whole project]).

我在不知道 AppCode 有类似功能的情况下写了这个，但是当我测试 AppCode 时，它​​没有这个脚本那么彻底（但速度更快 [对于整个项目]）。

回答by Erzékiel

As paddydubsaid, AppCodedo this very well. I tried, and it took me just 10 minutes :

正如paddydub所说，AppCode在这方面做得很好。我试过了，只花了我 10 分钟：

Go to Code > Optimize Imports..., or ^ + ? + O

前往Code > Optimize Imports...，或^ + ? + O

Here is a video describing how to do this : Detection of unused import and methods in AppCode

这是描述如何执行此操作的视频：检测 AppCode 中未使用的导入和方法

回答by sivi

You can use Xcode Analyser to find that and other problems.

您可以使用 Xcode Analyzer 来查找该问题和其他问题。

http://help.apple.com/xcode/mac/8.0/#/devb7babe820

http://help.apple.com/xcode/mac/8.0/#/devb7babe820

Also you can go to the project and target build and add change warnings preferences under build settings. See this guide:

您也可以转到项目和目标构建并在构建设置下添加更改警告首选项。请参阅本指南：

http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/

http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/

回答by Peter N Lewis

Recently, I changed a large project from Carbon to Cocoa. At the end of this, there were quite a few orphaned files that were no longer used. I wrote a script to find them that essentially did this:

最近，我将一个大型项目从 Carbon 更改为 Cocoa。最后，有相当多的孤立文件不再使用。我写了一个脚本来找到他们基本上做到了这一点：

Ensure the source is all checked in to subversion (ie clean) Ensure it currently builds without error (ie, xcodebuild returns 0 status) Then, for each source file in the directory, empty (ie, remove the contents, truncate the length) the source and the header file, try a build, if it fails, revert the files, otherwise, leave them empty.

确保源代码全部签入到subversion（即干净）确保它当前构建没有错误（即xcodebuild返回0状态）然后，对于目录中的每个源文件，清空（即删除内容，截断长度）源和头文件，尝试构建，如果失败，则恢复文件，否则，将它们留空。

After running this, revert and then delete all emptied files, compile and then remove all erroring #imports.

运行此程序后，还原并删除所有清空文件，编译并删除所有出错的#imports。

I should also add, you need to avoid files that are referenced from .xib or .sdef files, and there may be other dynamic linking cases, but it can still give you a good lead on what can be deleted.

我还应该补充一点，您需要避免从 .xib 或 .sdef 文件引用的文件，并且可能存在其他动态链接情况，但它仍然可以很好地引导您了解可以删除的内容。

The same technique can be used to see which #imports can be removed - instead of truncating the file, remove each #import in the file in turn and see if the build fails.

可以使用相同的技术来查看可以删除哪些 #imports - 而不是截断文件，而是依次删除文件中的每个 #import 并查看构建是否失败。