- 小程序如何百分百去还原美工视图?
[图片] 例图: 美工用画布,762 px 宽度 标示了每个文字和边框之间的间距。但实际上小程序适配不同手机的时候,可能会有些差别。 虽然目前用了 rpx 和百分百的模式进行布局。视觉第一感觉上一致了。 如果说完全百分百还原,那肯定是没底的,几乎都是一点点试出来的,感觉高一点,就减少个rpx,矮了,就加一个rpx。 实际上并没有完全理解多少 rpx 才是真实还原视图. 想得到一个答案?求教
2019-07-11 - 美工下海开发的第一个小程序上线!细数一下遇到的那些坑…1、2、3…
我是个美工,日常工作的第一职责是负责把“火箭”漂漂亮亮地画在微信小程序上,然后让开发实现出来;然后第二职责是指着 1px 挑刺儿:“有这么难吗?我又不是没写过 hello world。” 想自己写个小程序不是一天两天了。正赶上快过年了,就用这个书法拜年的小程序练练手。 这个小程序的想法其实很简单,就是让用户用手指在屏幕上写书法的福字。为了丰富一些玩法,就加入了一些其他的拜年吉祥话的字帖,以及一些不同颜色的主题,并且把这些放在后端,更新起来更灵活一些。 整个开发过程中最复杂的其实是这个毛笔笔刷,因为小程序只能返回用户手指的 x 和 y,所以我只能通过这两个值和 touchmove 的时间差,来模拟毛笔的笔触:包括运笔、提笔以及最能代表毛笔特征的飞白效果。在研究了其他产品上的笔刷实现之后,并没有找到在不依赖按压力度的情况下,只依靠 x, y 来实现所有这些效果的案例。那只能自己搞了。于是经过一个多礼拜反复修改计算方案、调参数,最终的实现效果自己还挺满意的(虽然上手有一定难度)。 [图片] 可以扫码体验 [图片] 虽然笔刷是这个小程序里最重要的部分,但不是我花时间最多的。那时间都去哪了?都掉在下面这几个坑里了…… 第 0 坑:我就不用框架。框架是什么?能吃吗? 从一开始,我就打算纯手敲一个小程序,不用框架。 三个原因: 我搞不懂框架,要花时间去学习我觉得框架都很冗杂、臃肿,要为有限的便捷性牺牲灵活性(反正我做的又不是大项目)我爱造轮子!纯手敲小程序其实也没啥坑,硬要说带来的最大的坑就是:需要造不少轮子。但谁让我乐意呢。 作为新手,做一些简单的基础组件,再包成业务组件,再用到实际的业务场景,这整个过程其实挺健脑的。比如,写个 button 组件,用来处理样式、状态、事件;然后包进 button-group,用来处理布局;然后被包进 dialog 或者 form 用来处理点击后的统一行为(比如关闭、提交);最后被用到场景中处理具体的细节逻辑。好在这个小程序没有什么特别复杂的东西。 第 1 坑:去你的 rpx 微信的 rpx 初看起来挺聪明的,把所有的屏幕都映射到 750rpx 的宽度上,帮开发者省去了适应不同屏幕尺寸的麻烦。 但是!rpx 的坑就来了: 接口返回的数值基本都是标准的 px,我要设定 rpx 的话还要 x2。有时候不得不混用 px 和 rpx,简直灾难。(这倒也算不上啥大问题)机型表现不同。嗯,道理我懂,可有时候四舍五入出来露了 1px 的缝出来就会有明显的问题。还有设置字体大小的时候,大屏手机上,自定义导航栏的字体设置成 34rpx 就是比系统级的导航栏 17px 肉眼可见的大。为了方便,让手机屏幕等比放到pad的屏幕上,文字按钮都那么老大个儿,丑不说,让屏幕展示效率奇低,不是啥好主意。不用 rpx 那做适配不就麻烦了吗?其实还好,从我自己这个小程序的需求出发,我的方案是:根据页面需要的最小高度和当前屏幕比例来定一个最大宽度(类似游戏地图的适配逻辑)。对于一般的功能型产品来说,这样相对于用rpx,不仅阅读体验提升了,屏幕展示内容的效率也能有所提升,甚至如果要专门为宽屏(pad)适配新的布局也比较灵活。 第 2 坑:canvas 在小程序里用 canvas,我遇到了两个大坑: 第 2.1 坑,也是最莫名其妙的坑,就是自定义组件盖不住 canvas 的问题,无论自定义组件的 z-index 多高都盖不住 canvas。微信的官方解释就是“原生组件层级最高”,一句话,bug 就变 feature 了?解决方案也只能是:当需要盖住 canvas 的时候,隐藏这个 canvas,然后临时用 canvasToTempFilePath 生成一张假图顶替一下。真挺蠢的。 第 2.2 坑,是锯齿的问题。使用 canvasToTempFilePath 导出图片,会产生锯齿。因为在我的程序逻辑中涉及到至少 3 次将 canvas 导出图片然后重绘到 canvas 上,所以图片质量经过三次下降之后就变像素风了。最终找到的解决方案,竟然是要在绘制的时候给 canvas 的宽高设大一些(大家建议是 2 倍),导出的时候再导出成需要的尺寸。比如需要 1200px 宽的图片,要给 canvas 设置成 2400px 宽,然后导出的时候再导成 1200px。然后微信又有 canvas 尺寸不能超过 4096 的限制,所以当图片高度大于 2048px 的时候,我只能再把放大倍数调低一丢丢… 第 3 坑:云托管(其实,还好) 云托管,一键完成配置,我不用再另外自己搭个后台环境了。而且资源也是弹性的,对新手比较友好。 但作为一个挺业余挺业余挺业余的开发者,我这个“新手”可能过于新了: dockerfile 是啥?Docker 又是啥?我到现在也没搞懂。Sequelize?完全没用过啊,不过看起来挺简单。可是sequelize.org这文档写的…为什么一直报错?SQL的语句里为什么不能用Rank()?什么?MySQL 5.7 是什么鬼?你到底会收我多少钱啊,费用中心里啥也没有,资源用量说了也跟没说一样,我不会用破产吧,我好慌啊……总之,我觉得程序员的世界太不容易了,天天要面对这么多对用户(程序员)不友好的产品(框架、文档、服务…… )。 最后,先跑起来再说 不过世界就是这么个草台班子,到处都是不完美,到处都是对用户不友好,可是又不得不用的产品。所以当自己是设计的时候,就尽量帮着用户对产品吹毛求疵,力求完美。但哪有完美的东西,有几个 1px 的坑不碍事,先跑起来再说。
02-05