我們有一個產品在iOS上發貨，有些泄漏

大約2分鐘時間內，儀器顯示大約有9K的泄漏。在大約1/2小時的使用中，大約有235K和6645個單獨的泄漏。我們有一個產品在iOS上發貨，有些泄漏

我討厭甚至考慮這個，但代碼不在我手中。任何人都會考慮在這種狀態下運送產品，還是iPhone和iPad可以接受？

2011-12-16 Alex Zavatone

我已經發貨，蘋果已經批准了一個應用程序，其中有4兆字節的故意泄漏（內存調試代碼在生產版本中意外未被刪除）。稍後在更新中修復，但沒有一位客戶在此期間報告了崩潰。 – hotpaw2 2011-12-16 03:12:02

這太可怕了，你絕對不應該發佈任何應用程序，即使是你的漏洞的1/100也是如此。我個人從來沒有提供過這麼多泄漏的東西。在運送我的產品之前，我會盡量確保至少有零個泄漏;我建議你（或者有權訪問代碼的人）徹底查看代碼，並儘可能消除這些泄漏。最終，你的應用程序將開始崩潰一堆，蘋果甚至有可能一旦得到100個或更多的崩潰漏洞報告就拉上它。

來源

2011-12-16 00:25:23 WrightsCS

我強烈建議在發貨前修理最差的違規者。用戶有殘酷與收視率，幾乎不可能在幾乎每一個我見過的評級系統中從一連串可惡的1星評級中「恢復」。提早發貨的決定可能會讓你的團隊困擾多年。

來源

2011-12-16 00:20:06 sarnold

完全同意。盡你所能把代碼拿回你的手中。如果一位經理持有它，那麼就對他們的商業案例做出說明，即從長遠來看，這會花費他們的錢。說實話，如果你使用分析功能，你可以在一天的編碼中得到根除的大部分泄漏。 – sosborn 2011-12-16 00:25:38

是的，我在Instruments和Analyzed中運行報告，我們的合同程序員說：「我真的不知道該怎麼做」。 – 2011-12-16 17:13:05

跟進。在令牌解析代碼中，在動態鏈接的代碼中，供應商已經在他們分配用於解析返回數據的「方面」上發佈了註釋。從服務器返回的每個數據集（作爲http字符串）都保存在內存中。

回想起來，我應該能夠找到它，但瞭解到它花了一段時間讓供應商讓我感覺不太舒服。

感謝您關注此事。乾杯。

來源

2012-04-03 19:27:59

我們有一個產品在iOS上發貨，有些泄漏

回答

相關問題