我正在爲客戶端和他的一個設備(iOS4上的第二代iTouch)開發應用程序,該應用程序啓動時出現問題。我運行了一些分配/泄漏測試,並得出結論說我的應用程序代碼沒有任何問題。我注意到在啓動時存在分配高峯,我得出結論認爲這是因爲dyld在啓動時動態鏈接庫。我將如何去預先綁定xcode4中的應用程序?Xcode 4中的預綁定庫
OS X論壇似乎是極其無法提供信息的,因爲他們認爲您能夠找到它。 :/
任何幫助,將不勝感激。 謝謝!
(我也希望我能做出一個新的標籤爲「預綁定」)
我正在爲客戶端和他的一個設備(iOS4上的第二代iTouch)開發應用程序,該應用程序啓動時出現問題。我運行了一些分配/泄漏測試,並得出結論說我的應用程序代碼沒有任何問題。我注意到在啓動時存在分配高峯,我得出結論認爲這是因爲dyld在啓動時動態鏈接庫。我將如何去預先綁定xcode4中的應用程序?Xcode 4中的預綁定庫
OS X論壇似乎是極其無法提供信息的,因爲他們認爲您能夠找到它。 :/
任何幫助,將不勝感激。 謝謝!
(我也希望我能做出一個新的標籤爲「預綁定」)
據蘋果公司稱,you shouldn't need to prebind your iOS applications。如果你獲得大的分配高峯,我猜這是由於你的應用程序的體系結構,而不是底層操作系統本身。
與由運行時的最早階段所做的最基本分配相比,由dyld分配的內存應該顯得微不足道。 Objective-C運行時和其他系統框架/庫分配一系列內部結構,這些內部結構是正確工作所需的。
例如,一個應用程序的快速測試,主要不做任何事情,但打一個電話NSLog(@"FooBar");
,然後睡覺(即從來沒有甚至假脫機UIApplication)執行373分配總共52K生活。
採取了一步,如果你真正開始了UIKit中,像這樣...
UIApplicationMain(argc, argv, nil, NSStringFromClass([MyAppDelegate class]));
...你會看到〜600K在7800〜生活的分配,一旦應用達到靜止狀態。這是所有不可避免的事情。沒有任何數量的預約會爲您節省這一點。我建議不要擔心。
如果你看到數量級更多的內存被分配,那麼,正如Nik Reiman所說,這是你的應用程序。在一天結束時,由動態鏈接器分配的內存是完全不重要的。