Referring to the header file in the header file will fully know all the interface information of the imported header file during compilation. For example, if B.h is imported into A.h, if A.h is imported into SubA.h in the future, it will be imported implicitly. B.h is added, unnecessary compilation is added, and the cohesion is low; Import the header file in the implementation file, the compiler will only know the interface information of the class when needed, which will reduce the compilation time, and between classes The degree of coupling will be reduced
As the questioner said, if it is an interview question, just answer it like this:
You should try to import in .m instead of .h. The reason has been well stated by other respondents. Types used in .h should be declared with @class as much as possible, and then imported in .m. There are only two situations where import must be done in .h: 1. Inherited parent class 2. Implementing a certain protocol.
.h is the description .m is the implementation Generally speaking, if the classes used in .h must be imported in .h If they are not used in .h. What is used in m can be imported in .m (or .h)
Please refer to the coding specification for details Generally for convenience, what is used in .h is quoted in .h What is used in .m is quoted in .m
I think the biggest difference is that writing in .m can effectively reduce cross-references. If you pay more attention, you will find that all references in Fundition and UIKit frameworks use .m and .h Using the Class declaration method has no impact on the app's runtime, but it can improve the speed of compiler preprocessing. The larger your project, the more obvious this impact will be.
So the default template of xcode6 has removed the previous public header file .pch file in order to improve the compilation speed.
Objective-C language supports dynamic features, which means that you only need to provide a statement at compile time. It doesn't matter even if it is not implemented. However, at runtime, the corresponding implementation will be found when the message is actually sent. If If it is not implemented, the corresponding process will be followed.
import .h file only introduces the header file declaration, and does not care about the implementation during compilation. Therefore, if the corresponding method is not implemented in the .m file, no error will be reported. import .m file is usually an implementation file. Of course, there will also be a pseudo-private API (implemented through Extension). The method selector->IMP relationship table will be found at runtime.
Preventing cross-references is necessary because we often make repeated references.
About sending messages dynamically, you can read: http://www.henishuo.com/runtime-message-forwarding/
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Referring to the header file in the header file will fully know all the interface information of the imported header file during compilation. For example, if B.h is imported into A.h, if A.h is imported into SubA.h in the future, it will be imported implicitly. B.h is added, unnecessary compilation is added, and the cohesion is low;
Import the header file in the implementation file, the compiler will only know the interface information of the class when needed, which will reduce the compilation time, and between classes The degree of coupling will be reduced
As the questioner said, if it is an interview question, just answer it like this:
You should try to import in .m instead of .h. The reason has been well stated by other respondents. Types used in .h should be declared with @class as much as possible, and then imported in .m. There are only two situations where import must be done in .h: 1. Inherited parent class 2. Implementing a certain protocol.
.h is the description
.m is the implementation
Generally speaking, if the classes used in .h must be imported in .h
If they are not used in .h. What is used in m can be imported in .m (or .h)
Please refer to the coding specification for details
Generally for convenience, what is used in .h is quoted in .h
What is used in .m is quoted in .m
You can import it wherever you use it
But my approach is basicallyYour .h file doesn’t need to be imported at all. Why are you importing it?
using @Class in .h is enough
using #import in .m
I don’t think anyone above has hit the point.
I think the biggest difference is that writing in .m can effectively reduce cross-references. If you pay more attention, you will find that all references in Fundition and UIKit frameworks use .m and .h Using the Class declaration method has no impact on the app's runtime, but it can improve the speed of compiler preprocessing. The larger your project, the more obvious this impact will be.
So the default template of xcode6 has removed the previous public header file .pch file in order to improve the compilation speed.
Hope it helps.
Objective-C language supports dynamic features, which means that you only need to provide a statement at compile time. It doesn't matter even if it is not implemented. However, at runtime, the corresponding implementation will be found when the message is actually sent. If If it is not implemented, the corresponding process will be followed.
import .h file only introduces the header file declaration, and does not care about the implementation during compilation. Therefore, if the corresponding method is not implemented in the .m file, no error will be reported.
import .m file is usually an implementation file. Of course, there will also be a pseudo-private API (implemented through Extension). The method selector->IMP relationship table will be found at runtime.
Preventing cross-references is necessary because we often make repeated references.
About sending messages dynamically, you can read: http://www.henishuo.com/runtime-message-forwarding/
tip:
Many people don’t know that using #import can prevent cross-references.
This is also the difference between #import and #include.