微信小程序开发问题:win和mac调试产生的代码不一样

0.前言

这两天在做一款微信小程序的开发,今天在前后端及UI对后面几天的工作进行安排时,发现小程序出了一点小问题。

在win端和mac端分别进行真机调试时,同一部手机通过两个系统上的微信开发者工具进行调试时,产生的效果不同。

1.问题描述

在mac端调试生成的效果如图

可以看到失物招领四个字是正常的,但同样的代码在win下的微信开发者工具,生成的效果如图

微信小程序开发问题:win和mac调试产生的代码不一样_第1张图片

失物招领四个字有一个被挤下去了。

对应的wxml代码如下


   失物招领

 对应的样式文件如下

.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和mac调试产生的代码不一样_第2张图片

win:

微信小程序开发问题:win和mac调试产生的代码不一样_第3张图片

发现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两种不同的操作系统对换行符的定义的不同,偶尔会带来一些排版上的问题。但大部分情况下并不会引起注意,本文也只是给大家在遇到类似的问题时,提供一种解决的思路。

你可能感兴趣的:(note,微信小程序)