h5内嵌原生，移动端到pad，不同尺寸的适配

做适配就是为了一套设计稿，在不同的尺寸的屏幕下，保证一致性，保证屏效，保证内容不被裁减。

通常这种问题在常规的移动端竖屏显示下，在不涉及不同语言的开发下问题不是特别明显，但是一旦设计到h5嵌套原生，或者一稿适配到pad，或者横屏的情况下，就会出现严重的混乱，原因是开发会按照自己的理解去做布局，思路不够统一，原生习惯写固定的边距，h5端这边如果不做特殊处理，即使一样写边距也会自动转化为屏幕的百分比，这种情况在设备屏幕尺寸与设计图（我这里是常规的2倍图尺寸，750px  1334px）等比例的情况下当然是没有问提的，一旦涉及到不等比例，尤其是长屏手机，或者pad问题就会很明显了。

所以我自己的思路是，常规尺寸的一屏显示的内容，要保证在不同设备下起码能够展示完整，如果是一张图片就是保证在不同设备下不能被裁减（当然比如启动页，如果是带背景，我会把内容和背景拆分成两个图层，保证内容区域不受影响或者裁减）。

按照这个思路，首先是正常750px 1334px设计稿适配到pad（1536px 2048px），如果是竖屏的情况下，web开发如果不说明，会按照2倍图（750px 1334px ）宽度的百分比去写，导致到了pad端实际上是等比缩放了2倍，但是pad的高度其实是不足6的两倍（2048px/1334px = 1.5左右），这种情况会导致h5嵌套原生界面是，在切换时，相同的元素、控件就会变得傻大傻大的，严重影响一致性（同于横屏幕下的6与x）。

所以解决办法是统一板式布局和适配方式，也不用转换单位，移动端，web前端一样，都可以拿到设备的机型（屏幕宽度高度的实际像素值），为了统一方便理解以竖屏幕为例：

页面适配元素以2倍图的实际像素值去写，包括布局方式仍不变（卡片累的容器，屏幕宽度-边距（不是写死的，如果是图片，原图有宽高比，乘以宽高比，如果不是图片，内容撑开）），然后在乘一个系数（这里取名为e吧），然后置于这个系数取多少，就看屏幕的宽高比（宽取名w，高取名h），当 w/h 大于等于 750px/1334px ，e=h/1334px，当w/h小于750px/1334px，e=w/750px，（边距，字号，间距等都✖️以这系数，拉伸区域不用管，自行填充）。

个人工作中遇到问题，解决办法，经验总结，希望对大家有所帮助。