背景
今天遇到一個（其實之前就遇到了一直沒重視）佈局問題。
在iphone plus機型和MAX機型裏，一個transfrom: translate3d(x, y, z)操作比預計的位置要遠。
最後根據調試和不斷測試找到了問題的原因，原因是因爲我們在頁面使用了rem佈局。並且rem的基準是按照37.5px來計算了。比如下面這個css:
p {
width: 24px;
}
經過轉換回變成：
p {
width: 0.64rem;
}
然後我們在根據屏幕的大小調整document的font-size大小。比如屏幕寬度如果375。那麼html的字體大小就調整爲37.5，這樣，我們佈局的時候只需要按照375px的設計稿來進行固定佈局即可，當屏幕放大使，html的字體大小會相應放大，這樣所有元素就會等比放大，到達自適應的效果。具體代碼如下：
document.documentElement.style.fontSize = (document.documentElement.clientWidth / 10 > 48 ? 48 : document.documentElement.clientWidth / 10) + 'px';
問題（計算結果不一致）
當這樣的效果在iOS裏卻出現了一個問題，比如上面的元素在375px的屏幕裏是24px寬，在414屏幕裏就是26.469px寬，但是iOS裏渲染的時候會直接取整，也就是26px。
當是如果我們在transfrom裏如下的代碼：
.p {
transform: translate3d(0.64rem, 0, 0);
}
同樣是414屏幕的寬度裏，這個translate3d真的會移動26.496px，而不是26px。這會導致如果依賴元素本身在CSS裏寫的寬度來計算transform的🈯️就會出現問題。解決方案就是當元素實際渲染以後獲得元素的寬度，再根據元素實際渲染寬度進行transform。
總結
現象：iOS裏，準確的說是safari瀏覽器裏。普通屬性，比如寬高，遇到rem單位裏有小數時，實際渲染值會取整。但是在transform裏的rem值，並不會取整。
解決方案：當transform裏的移動值依賴元素本身屬性時，等元素渲染完成以後獲得實際渲染值再設置transform。
真正的總結
寫到這裏我發現是我弄錯了。上面的總結是錯的，transform也是會取整的。
只不過當時的情況是在transform裏，把原始的0.64乘了9。因爲0.64rem到26px，中間被去掉了0.469px。那麼0.64*9=5.76，5.76*41.4=238.464px。但是實際上9*26=234px。所以transform裏值不和實際渲染的值向對應了。
寫出來纔想明白這個道理。