因为涉猎过一点前端开发,所以对分辨率自适应这个问题印象深刻。如果追求完美的使用体验,这一关一定是绕不开的。对于IOS和PC来说比较好解决,在Android平台就比较麻烦。
很多人往往认为,初学一个开发工具重要的是语法等基本的东西,往往一上来就先通读手册,期间不断参阅各种demo,稍微进步一点的则在他人demo的基础上进行修改……不得不承认,这是一种有效的学习方法,但我始终认为这是低级的方法。
手册是一个好东西,但是有没有一种工具或语言在编制其手册的时候是按照使用频率来排序的?至少我是没有见过。若是如此,那么通读手册的做法无疑是对我们大脑资源的极大浪费,因为在信息数据大爆炸的今天,通读所有的手册无疑需要大量的时间和精力,甚至是不可能的任务!
所以,手册只是在需要的时候拿来查查就好。
再说demo。阅读别人的代码可以让你快速的知道,哦,这个功能是这样写的。但是我想很少有人会同时想到:这段代码为什么这样写?为什么要用这个方法?为什么这个方法要放到那个方法的后面?二者交换会发生什么有趣的事情?……
很多人一定看不下去了……bullshit !~在这个阶段的人都是初学者,即便他们想到这些问题,又怎么可能弄得清楚?!
好吧!这个说法有一定的道理。很多人学习的初衷就是“速成”,所以造成的结果是:很多所谓精通者,不过是些“workers”,但是从一开始,我就立志成为一个优雅的“desgner”。
那么,问题来了,高贵优雅的贵族气质,是可以速成的么……
所以我选择的方式是,先想想我要干什么,要达到什么目标,实现这些目标需要分多少个步骤,每个步骤我需要用什么方法、使用什么工具……
貌似扯得远了,回到起笔的问题上——
我想要做一款首先是视觉上体验良好的小游戏,不要变形、不要黑边,所以我才考虑到这个自适应分辨率的问题,在我写第一个场景之前我就要把这个问题解决,而不是在我完成了所有功能之后在做修补。
好了,接下来的时间,我要翻一翻、查一查,有多少种解决这个问题的办法,优劣是什么,最终我会选择什么……
By the way, 当我确定了我的方法之后,我一定已经对手册上的很多内容非常熟悉了。