Swift performed using Xcode development software language when，Many people in the latter part of the project will encounter such a problem，If that diagram as：SourceKitService Take up a lot of CPU and memory，Or even directly cause the system stuck。
Encountered SourceKitService intensive CPU and memory that many people
Then，This in the end is how it all about? StuckOverflow of the vote on the answer is to say：
Find SourceKitService double-click it in the Activity Monitor，It opens the directory to see which，To delete the cache and then terminates the process。
This does help relieve symptoms，But a temporary solution，Not even a few seconds and again occupied CPU 200% Got it。so，We need a more fundamental solution。
In fact, if you force the end of SourceKitService ，You will find the code highlighting in Xcode are gone - the code into a plain text document similar kind of black and white! SourceKitService Highlight charge of your code，In fact, it took charge of Swift's type inference work。
That is，For example, your code is written：
|
1 |
private lazy var emojiFace = ["?", "?", "?", "?"] |
Anyway, the easy way and you will not change the basic content，So write directly for a long array of all the facial expressions are as a string to go into the，Then the literal array will become very, very long。
At this moment SourceKitService It takes a lot of time to deal with these，An array of type inference you - may be due to some internal Bug，Or that is SourceKitService Born imperfect，In short it will be stuck in here，The formation of the title figure of embarrassment。
At this moment，We need this treatment：
|
1 |
private lazy var emojiFace:[String] = ["?", "?", "?", "?"] |
That is，This array to explicitly specify the type，Such，SourceKitService It will not come again handle its type - and because it is clear。
The same time，SourceKitService CPU usage immediately drop down。
Original article written by LogStudio：R0uter's Blog » SourceKitService take up a lot of memory and CPU solutions
Reproduced Please keep the source and description link：https://www.logcg.com/archives/2209.html
