當我們去點一個屬性的時分，我們知道其實是調用了屬性的setter或許getter辦法。那麼，用點調用一個辦法會發作什麼？

這時分零碎並不會解體，而只是報一個正告(Property Access result unused)。

如今我改成用中括號正常調用辦法，可是由於大意沒有在.m中寫辦法的完成，會發作什麼呢？

OC是一門靜態編程言語。

調用saySomething這個辦法。假如這個辦法只是在.h中聲明了，而沒有在.m中完成。那麼我們編譯順序不會呈現問題(Build Success)，只要當運轉順序的時分，才會直接解體(unrecognized selector sent to instance 0x60000000e8d0)

這是由於在編譯階段，編譯器並不知道saySomething要執行那段代碼，這個時分[people saySomething]會轉換為objc_msgSend(people, "someThing")，就是說給people以selector的方式發送someThing這個音訊。當真正運轉的時分，才會去people的內存中尋覓someThing的地址，這時分找不到才會形成解體。

那麼，有沒有方法說可以不在.m中完成somtThing，而又不讓順序解體呢？

有！所謂 靜態言語，就是一類在運轉時可以改動其構造的言語：例如新的函數、對象、甚至代碼可以被引進，已有的函數可以被刪除或是其他構造上的變化。

想要順序不解體，我們有三次時機去解救它。這個就是音訊轉發機制的三個步驟：

第一步：靜態辦法解析

下圖可以看到，我沒有完成saySomething的辦法，順序運轉成功。實踐上是調了Dosomething這個辦法。

我們這裡的saySomething是對象辦法，假如是類辦法的話，對應的是resolveClassMethod:

第二步：備用接納者

假如我們糜費了第一次時機不必，還有第二次時機解救工程：把這個音訊轉給他人，讓他人替我處置！

下圖可以看到，我沒有完成run辦法，而是交給了_dog去處置這個音訊。在Dog.m中，我完成了的run辦法被調用了！

第三步：完好轉發音訊

假如我們連第二次時機都糜費了，那麼還有最後一次時機彌補。在完好轉發音訊這一步中，我們把音訊封裝到NSInvocation對象中，並把它發給一個可以呼應音訊的對象。

察看音訊轉發機制的後兩步，其實都曾經不是people在處置音訊了，而是交給了他人。但是在裡面看，我們是調用了[people run] 和 [people eat] 。經過這種方式可以將原本對象A要做的事交給B或C來做。

Github Demo

以上就是對從iOS點語法引發的一番考慮的相關引見，希望對您學習ios有所協助，感激您關注本站!

【從iOS點語法引發的一番考慮】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！