微信小程序开发问题:win和mac调试产生的代码不一样
0.前言
这两天在做一款微信小程序的开发,今天在前后端及UI对后面几天的工作进行安排时,发现小程序出了一点小问题。
在win端和mac端分别进行真机调试时,同一部手机通过两个系统上的微信开发者工具进行调试时,产生的效果不同。
1.问题描述
在mac端调试生成的效果如图
,
可以看到失物招领四个字是正常的,但同样的代码在win下的微信开发者工具,生成的效果如图
失物招领四个字有一个被挤下去了。
对应的wxml代码如下
<view class="list_title" hover-class="none" hover-stop-propagation="false">
失物招领
</view>
对应的样式文件如下
.list_title {
font-size: 22rpx;
margin: 0 auto;
}
2.问题分析
2.1手机型号
首先,分别使用组里其他二人的手机扫码调试,发现问题依旧出现。因此,排除手机型号的问题。
2.2代码问题
通过人眼对比win和mac两边的代码,发现代码完全相同。将代码通过git同步后发现,问题依旧存在。但对比win和mac生成的代码包发现,win下代码包为460kb,而mac下为451kb,然而代码相同,猜测是不同环境下的开发者工具产生的代码不同。
2.3真机调试
在两种环境下分别进行真机调试,对比这一行的代码
mac:
win:
发现win下的font-size被转换成了13px。遂百度有关微信小程序rpx转px的问题。在微信官方的社区中,有人说是wxss编译时的问题,可以通过删除wcsc.exe文件来解决。
在console中输入openvendor(),打开文件夹后删除wcsc文件,重新编译后发现问题依旧存在。
2.4 CRLF
对比win和mac生成的wxml文件发现
win下的失物招领两边有一个空格,但mac下是没有的
这时,想起来之前看到的win和mac下的对换行符的定义不同
名词解释
- CR:Carriage Return,对应ASCII中转义字符\r,表示回车
- LF:Linefeed,对应ASCII中转义字符\n,表示换行
- CRLF:Carriage Return & Linefeed,\r\n,表示回车并换行
众所周知,Windows操作系统采用两个字符来进行换行,即CRLF;Unix/Linux/Mac OS X操作系统采用单个字符LF来进行换行;另外,MacIntosh操作系统(即早期的Mac操作系统)采用单个字符CR来进行换行。猜测是因为两种系统CRLF的区别导致了生成效果的不同。
这也就很好的解释了为什么之前win下生成的代码包比mac大的问题,于是通过vscode,将代码的换行符模式改成了LF。重新编译,发现问题解决。
3.总结
win和mac两种不同的操作系统对换行符的定义的不同,偶尔会带来一些排版上的问题。但大部分情况下并不会引起注意,本文也只是给大家在遇到类似的问题时,提供一种解决的思路。