界面生成器降级故事板，以小增量调整视图大小并重新定位视图 [英] Interface Builder degrades storyboards, resizes and repositions views in small increments
问题描述
我注意到，当开发者没有直接对故事板进行任何编辑时，我们视图的这些降级会出现在我们的Git仓库的提交中。他们可能在Interface Builder中查看了故事板，但并没有对故事板做任何实际的改变。这些变化仍然保存下来，并与他们正在进行的工作一起进行。
当我在负责任的提交之前和之后对故事板文件进行文本比较时，以查看以下框架：
$ b
< rect key = framex =203y =8width =362height =29/>
|
V
< rect key =framex =203y =7.5width =362height =29/>
和
< rect key =framex =446.00000170260091y =7width =302height =30/>
|
V
< rect key =framex =446y =7width =302height =30/>
和
< rect key =framex =364y =3width =200height =38/>
|
V
< rect key =framex =363y =3width =200height =38/>
和
< rect key =framex =284y =7width =97height =30/>
| |
V
< rect key =framex =283y =7width =96height =30/>
和
< rect key =framex =384.00001078580522y =7width =101height =30/>
| |
V
< rect key =framex =383.00000530853856y =7width =100height =30/>
大多数情况下，框架尺寸的数字只是变化很小，其他时候，这些值会改变几个点，如下所示：
< rect key =framex =334y =3width =200 height =38/>
|
V
< rect key =framex =331y =3width =200height =38/>
和
< rect key =framex =251y =7width =223height =30/>
|
V
< rect key =framex =251y =7width =220height =30/>
和
< rect key =framex =478y =3width =274height =38/>
| |
V
< rect key =framex =475y =3width =276height =38/>请注意，所有这些示例帧更改均取自相同的示例提交，当开发人员并不打算对故事板进行单一更改。文件的两个版本之间的XML有269个差异，它们都是帧大小或位置的轻微变化。故事板XML是9000行。
看起来这个问题可能与IB使用浮点数和舍入错误有关，在几次打开，解析和重新序列化数据的过程中，几个像素可能是这些舍入错误的集合。
这只是一个理论，一直没有找到不必要的变化的确切原因。通常的做法是根本不对帧做任何重大的改变，只有微不足道的浮点数变化，如446.00000055262581 - > 446.00000112002783。但是，当发生严重的变化时，它们似乎大量出现。
发生更改的提交也由同一开发人员使用相同版本的Xcode和Interface Builder。在这个例子中，提交这个数据的地方，文档标签是< document type =com.apple.InterfaceBuilder3.CocoaTouch.Storyboard.XIBversion =3.0toolsVersion =6250systemVersion =例如，在这两个版本的故事板文件中，14A389targetRuntime =iOS.CocoaTouch.iPadpropertyAccessControl =noneinitialViewController =JAD-vj-VfC> b
$ b
除了确保不要对故事板文件进行无意或无意的更改，我想要缩小是什么导致这些不需要的故事板视图更改。如果这是我们可以避免这样做的原因，我们可以知道原因。
更新：
As蒂姆有帮助地指出，这个问题似乎是在视网膜显示器上使用Interface Builder时造成的。所有造成问题的开发者都有视网膜MacBook Pro。我们这些没有视网膜显示器的人并没有遇到这个问题。
解决方案这个谜题中最有趣的线索是，当您在Retina显示屏上打开相同的故事板，而不是非视网膜显示屏。
起初，我是在4k iMac和预先设置好的显示器之间来回移动，视网膜的MacBook Pro，并得到了大量的变化（~300线每次更改）。
然后，我只是从我的主监视器拖动xcode窗口（4k /视网膜）到我的第二个显示器（2560x1440，非视网膜） - 而窗口是相同的大小，xcode调整大小的所有元素和抱怨约50错位的意见。我把它移回到视网膜显示器，大约一半的错位错误消失了，但是一半仍然存在。如你所说，重新缩放会降低底层的数据。如果你有多个开发人员在同一个文件上工作，这肯定会经常发生。
解决方案？这可能是所有的苹果纠正 - 我还没有遇到任何设置，否则会减轻它。
We have a number of iOS apps that several different developers contribute to. A problem that I continue to notice is that views in our storyboards will shift out of the position they were put in or resize so that they are smaller, which on labels that were sized to fit text originally becomes painfully obvious when the labels all of a sudden are truncating their text.
I'm noticing these degradations of our views appear in commits to our Git repository when the developer did not directly make any edits to the storyboard. They may have viewed the storyboard in Interface Builder, but did not make any real changes to the storyboard. The changes were nevertheless saved and committed along with what they were working on.
When I do a text compare between the storyboard files before and after the responsible commits I see small changes to view frames such as:
<rect key="frame" x="203" y="8" width="362" height="29"/>
|
V
<rect key="frame" x="203" y="7.5" width="362" height="29"/>
and
<rect key="frame" x="446.00000170260091" y="7" width="302" height="30"/>
|
V
<rect key="frame" x="446" y="7" width="302" height="30"/>
and
<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"/>
and
<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"/>
Most of the time the numbers for frame dimensions are changing by just a small amount, either an integer value changes by one or a floating point value is truncated or the decimal portion is changed minorly.
Other times, the values are changing by a few points though like:
<rect key="frame" x="334" y="3" width="200" height="38"/>
|
V
<rect key="frame" x="331" y="3" width="200" height="38"/>
and
<rect key="frame" x="251" y="7" width="223" height="30"/>
|
V
<rect key="frame" x="251" y="7" width="220" height="30"/>
and
<rect key="frame" x="478" y="3" width="274" height="38"/>
| |
V V
<rect key="frame" x="475" y="3" width="276" height="38"/>
Note that all of these example frame changes were taken from the same example commit when the developer did not intend to make a single change to the storyboard. There were 269 differences in the XML between the two versions of the file, all of them being these slight changes in frame sizes or positions. The storyboard XML is ~9000 lines.
It seems the issue may have something to do with IB's use of floating point numbers and rounding errors and the differences that become off by a few pixels could be an aggregation of these rounding errors over a period of several times opening, parsing and re-serializing the data.
This is just a theory though as I've not been able to pinpoint the exact cause of the unwanted changes. Often commits don't make any significant changes to the frames at all, only insignificant floating point changes such as 446.00000055262581 -> 446.00000112002783. But when the serious changes occur, they seem to occur in large numbers.
The commits between which the changes occur are also made by the same developer using the same version of Xcode and Interface Builder too. In this example commit where this data was taken, the document tag is <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"> in both versions of the storyboard file for example.
Other than being sure to check not to commit insignificant or unintended changes to storyboard files, I'd like to narrow down what is causing these unwanted changes to our storyboard views. If it's something we can avoid doing that is causing the issue, we can be aware of the cause.
Update: As Tim helpfully noted, this issue does seem to be caused while using Interface Builder on a retina display. All the developers that have caused the problem have retina MacBook Pros. Those of us without retina displays have not experienced the issue.
The most interesting clue in this mystery is that it seems especially bad when you open the same storyboard on a Retina display as opposed to a non-retina display.
At first I was going back and forth between a 4k iMac and a pre-retina Macbook pro and was getting a large volume of changes (~300 lines altered each time).
Then I simply dragged the xcode window from my main monitor (4k/retina) over to my second monitor (2560x1440, non-retina) - and while the window was the same size, xcode resized all the elements and complained of ~50 misplaced views. I moved it back to the retina display and about half of the "misplaced" errors went away, but half remained. The re-scaling - as you suggest - degrades the underlying data.
If you've got multiple developers working on the same file, this is bound to happen frequently.
The solution? This is likely all on Apple to correct - I haven't run into any settings that would mitigate it otherwise.
这篇关于界面生成器降级故事板，以小增量调整视图大小并重新定位视图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
