界面生成器以小增量降級故事板，調整視圖大小並重新定位視圖

Question

我們有幾個不同的開發者貢獻的iOS應用程序的數量。我仍然注意到的一個問題是，我們的故事板中的視圖將從其放入或調整大小的位置移出，以使它們更小，當標籤全部爲一個標籤時，標籤上適合文本大小的標籤最初變得非常明顯突然間正在截斷他們的文字。

我注意到，當開發人員沒有直接對故事板進行任何編輯時，我們視圖的這些降級會出現在對Git存儲庫的提交中。他們可能在Interface Builder中查看了故事板，但並未對故事板進行任何實際更改。然而，這些變化與他們正在進行的工作一起得到拯救和承諾。

當我做之前和負責提交我看到的微小變化，以查看幀，諸如後的故事板文件之間的文本比較：

<rect key="frame" x="203" y="8" width="362" height="29"/> 
          | 
          V 
<rect key="frame" x="203" y="7.5" width="362" height="29"/> 

和

<rect key="frame" x="446.00000170260091" y="7" width="302" height="30"/> 
         | 
         V 
<rect key="frame" x="446" y="7" width="302" height="30"/> 

和

<rect key="frame" x="364" y="3" width="200" height="38"/> 
         | 
         V 
<rect key="frame" x="363" y="3" width="200" height="38"/> 

and

<rect key="frame" x="284" y="7" width="97" height="30"/> 
         |    | 
         V    V 
<rect key="frame" x="283" y="7" width="96" height="30"/> 

和

<rect key="frame" x="384.00001078580522" y="7" width="101" height="30"/> 
         |        | 
         V        V 
<rect key="frame" x="383.00000530853856" y="7" width="100" height="30"/> 

大部分爲幀尺寸的號碼由只是一個小的量改變時，無論是由一個或一個整數值的變化的浮點值被截斷或小數部分變化不大。

其他時候，值由幾個點改變雖然喜歡：

<rect key="frame" x="334" y="3" width="200" height="38"/> 
         | 
         V 
<rect key="frame" x="331" y="3" width="200" height="38"/> 

和

<rect key="frame" x="251" y="7" width="223" height="30"/> 
             | 
             V 
<rect key="frame" x="251" y="7" width="220" height="30"/> 

和

<rect key="frame" x="478" y="3" width="274" height="38"/> 
         |     | 
         V     V 
<rect key="frame" x="475" y="3" width="276" height="38"/> 

注意，所有的這些示例框架的變化是當開發人員不打算對故事板進行單一更改時，會從同一示例中提交。這兩個版本的文件在XML中有269個不同，它們都是幀大小或位置的輕微變化。故事板XML是〜9000行。

看起來這個問題可能與IB使用浮點數和舍入誤差有關，並且由幾個像素變成的差異可能是這些舍入誤差在多次打開，解析並重新序列化數據。

這只是一個理論，雖然我無法確定不需要的更改的確切原因。通常，提交不會對幀進行任何重大更改，只有微不足道的浮點更改，例如446.00000055262581 - > 446.00000112002783。但是當發生嚴重變化時，它們似乎大量出現。

發生更改的提交也由同一開發人員使用相同版本的Xcode和Interface Builder進行。在本示例中，在提交數據的位置提交時，文檔標記例如在故事板文件的兩個版本中均爲<document type="com.apple.InterfaceBuilder3.CocoaTouch.Storyboard.XIB" version="3.0" toolsVersion="6250" systemVersion="14A389" targetRuntime="iOS.CocoaTouch.iPad" propertyAccessControl="none" initialViewController="JAD-vj-VfC">。

除了確保不對提交故事板文件提交不重要或無意的更改，我想縮小是什麼導致這些不需要的故事板視圖更改。如果這是我們可以避免造成問題的原因，我們可以意識到原因。

更新： 正如蒂姆指出的那樣，這個問題似乎是在視網膜顯示器上使用Interface Builder時造成的。所有造成問題的開發者都有視網膜MacBook Pro。我們這些沒有視網膜顯示器的人都沒有遇到過這個問題。

Answer 1

這似乎是一個與Interface Builder的CGFloat值序列化相關的錯誤。視圖框架的大小和位置值是浮點。但是他們的價值觀總是整數。內部圖形操作要求它們是變換數學運算的浮點，但一切總是用圓整點值表示。

當這些浮點值序列化爲故事板XML時，IB通常會將值序列化爲整數，但有時也會將它們序列化爲浮點數。我不確定爲什麼它會做出這樣做的決定，但它不太常見。在我上面的示例框架中，其中3個值最終成爲浮點數，其他則是整數。

在我的例子中也可以看到，通常浮點表示將被改爲被序列化爲一個整數。這是我相信錯誤被發現的地方。

我注意到視圖框架的方式發生了變化，他們傾向於向左移動或縮小尺寸。所以價值觀變得越來越小。你可以在我提供的例子中看到，這是最常見的情況。

浮點數不準確地表示整數值，但精確到小數點後幾位。所以雖然有時整數在我的例子中表示爲略高於整數值（即384.00001078580522），但其他值則表示爲略小於整數值。這裏有一個框架變化的一個例子IB做：

<rect key="frame" x="457" y="7" width="291" height="30"/> 
         | 
         V 
<rect key="frame" x="456.99999985252464" y="7" width="291" height="30"/> 

雖然這個特別的變化似乎並沒有直接修改框的值。這兩個數字基本上等於457.我認爲發生的是當再次打開故事板時重新分析此XML時，它可能會截斷456.99999985252464值並將其讀取爲456.然後，這會導致值逐步獲得更小，縮小尺寸或將框架的位置向左或向上移動。

當然，這只是一個理論，並沒有給出Interface Builder爲什麼這樣做的原因。它似乎從最近的Xcode 6發佈以來就已經開始了。另外，它並沒有解釋在一個例子中它是如何從8到7.5變化的，甚至也不是從最後一個例子中的274變爲276。但大多數情況下，大部分變化趨於下降。

我正在申請一個與蘋果有這個問題的bug。

Answer 2

這個謎題中最有趣的線索是，當您在Retina顯示屏上打開相同的故事板而非非視網膜顯示器時，它看起來特別糟糕。

起初我來回4K的iMac和預視網膜的MacBook Pro之間，並得到一個大的體積變化（約300行，每一次改變）。

然後，我只需將xcode窗口從我的主顯示器（4k /視網膜）拖到我的第二個顯示器（2560x1440，非視網膜） - 而窗口尺寸相同時，xcode調整了所有元素並投訴〜50錯位的意見。我把它移回到視網膜顯示器，大約一半的「錯位」錯誤消失了，但一半仍然存在。重新縮放 - 如您所建議的那樣 - 會降低底層數據。

如果你有多個開發人員在同一個文件上工作，這肯定會經常發生。

解決方案？蘋果公司可能會糾正這一切 - 我還沒有遇到任何會減輕它的設置。

Answer 3

我可能對這個問題有一個答案。它在低分辨率模式下打開應用程序的知之甚少。我們最近有一個類似的問題，其中表格視圖單元格的內容視圖在分隔線設置爲默認或單獨時，高度爲0.5高度。當它設置爲None時，這個問題就不存在了。 步驟 1.將默認TVC拖到故事板。檢查表格視圖單元格的內容視圖的高度。這將是43.5。 2.將表格視圖的分隔線設置爲無。的細胞變化的內容以44

現在退出Xcode和設定開在Finder中低分辨率模式獲取信息窗口的Xcode的應用程序。現在，如果您按照上面的相同步驟操作，則會將表視圖單元格的內容視圖的高度顯示爲43.

當有不同的團隊成員在視網膜和非視網膜顯示器上工作時，您只需將故事板文件作爲只是因爲你在視網膜顯示器中打開故事板而被修改。一種解決方法是打開低分辨率模式並開始工作。但是，儘管你沒有改變任何東西，但是它卻擊敗了具有視網膜顯示的目的，但是比故事板標記爲已修改的更好。