在视频中已经说过了，小程序的设计思想和原生app的设计思想颇为相似，基本的应用单元为页面。当然对于一个页面来说每一个元素的放置位置在哪儿以及显示成什么样子这个是由 样式来决定的 。我们知道在web开发中样式是在css文件中规定的，叫做层叠样式表 (Cascading Style Sheets)。其实在APP中样式的约束也是使用css，在支付宝小程序中也是使用css不过文件的后缀是.acss而且对css3进行了扩充而已。
那么在支付宝小程序中的.acss和微信小程序中的.wxcss没有什么两样。 上边已经说了.acss其实包含了css3那么它还有一些新的特性是css3中不具备的，让我们一一看看
第一次看到这个东西也能猜到他是干什么用的。在css中我们知道规定大小一般使用像素(px)这个单位。比如显示生活中我们说房子128㎡那这儿的单位是平方米，在开发中需要更加精准的大小就是px像素。像素就非常精细了因为在我们显示屏幕中像素是最小的显示单元。这个道理如果不懂的话就找个LED屏幕仔细看，LED屏幕上一个一个的发光二极管可以想象为像素。
我们知道手机屏幕有大有小，就拿iPhone来说，iPhone 6 plus比iPhone 5要大。那么就说明plus的像素比5要多。对比：
加入有一个160px宽度的红色矩形在这两种手机中的位置如下：
rpx（responsive pixel）可以根据屏幕宽度进行自适应。如何自适应呢？看下边的分析：
看下图：
在模块化开发中我们有时候不得不在页面中使用其他的第三方库的样式，而第三方库的样式是保存在第三方包中的，我们不可能全部复制到我们的.acss文件中，那最好的办法就是导入了。在样式表中导入其他外联样式表。
当然仍旧支持内联样式和class属性制定样式类，如
选择器和css3的保持一致。一般有class=”test”类选择器和id=”test”的id选择器。当然在支付宝小程序的样式中特殊的地方就是：
※ .a- 或者 .am-为前缀的选择器已经被系统占用所以不要使用；
※ 不能使用属性选择器，例如,以下写法不被支持：
我之前说过小程序开发的应用单元为页面。其实我们在.axml中写的页面并不包含页面容器，就相当于我们做一个页面但是body标签不用写那如果我们要改变整个页面的背景怎么办呢?其实有一个固定的选择器。例如：
可以通过 page 元素选择器来设置页面容器的样式，比如页面背景色:
在你想改变页面容器的页面中定义该样式也可以，全局定义也可以，例如我想将test这个页面的页面容器背景设置为蓝色，就可以再pages目录下的test目录下找到test.acss在其中定义page的样式
下节是视图层讲解，如果有任何问题可以再下方给我留言或者发邮件到 [email protected] 我在收到邮件后会回复。
一、微信小程序的wxml
具有基本的编程经验的工程师，只有与wxml接触后，您才会发现该语言的编程概念类似于html网页的编程技术。经过一番研究和开发，您会知道微信小程序的要求技术含量不高，只是更换了一些标签，例如
已替换为等待状态。即使您不太擅长前端，转用微信小程序的发展也将是一个很好的方向。
二、微信小程序的wxss
wxss是微信的CSS。微信用自己的开发语言wxss代替了Web编程中使用的css；实际上，主要的实现思想与Web开发技术基本相同，并且它只是对某些标签的简单替换，其中大部分是原始的CSS，基本上是正确的。它们都是通过调用同一页面来实现的，但是可以说，微信小程序比Web开发更简单，更方便。例如，只要写入index.wxml和index.wxss，它就位于两个文件中。这两个文件同时位于同一目录中，就像直接在网页上写CSS一样，这既简单又快速。
三、微信小程序的js
如果要开发微信小程序，您必须精通微信小程序的js。只要您具有html+css+js的良好基础，就可以全力学习微信小程序js，然后在前端进行开发。上面没有问题，但是微信js需要努力学习。您可以购买参考书或了解微信小程序的API，它们可以快速帮助您参与开发队列。
四、微信小程序的json
掌握了以上几点之后，您需要掌握json。简而言之，json是微信小程序的主要和次要接口。工程师可以通过json控制上下菜单栏，主要和辅助页面的显示顺序。但是，使用频率不高。它仅适用于基本小程序的框架，但这也需要学习，因为除显示类型外，每个前端操作都需要与后端匹配，因为如果要使其放大，则必须之所以简化，是因为修改代码后，在迷你程序中搜索到的版本就是启动后的版本，即我们提交微信评论后显示的版本。修改源代码后，需要将其提交给微信公众进行审核。平台小程序管理平台，用户只能在审核通过后才能看到您的修改，因此，为避免这种麻烦，您必须了解后端技术开发并与前端链接以与您进行交流。
实际上，小程序类似于H5表面，并提供了视图层描述语言。您需要掌握WXML和WXSS以及基于JavaScript的逻辑层框架。这里的wxml等同于html，而wxss等同于CSS。
在这之前，如果有人问我，在微信中做一个产品，是用小程序还是 Web 页面 (严谨，既不是 HTML5 更不是 H5…) 的时候，我会这么说：
产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
关于后一点，朋友圈分享现在普遍会用海报来做，在这点上 Web 和小程序的能力其实是一样的，都是只能帮你保存图片到相册，再请用户手动发送到朋友圈。而小程序独有的发现 - 小程序、搜索框快捷方式等对用户回访特别重要的入口，Web 页面是不能使用的。
那么，昨天的发布意味着什么？简单地说，小程序的开发成本有了很大的下降。
微信小程序刚刚上线的时候，由于小程序使用类似 HTML、CSS 和 JavaScript 等 Web 语言的方式进行开发，让一些媒体误以为小程序就是 Web 开发，欢呼将「迎来 Web 开发的春天」。我自己的第一份工作就是 Web 开发工程师，Web 开发入门确实比较容易；可是尽管小程序使用了 Web 语言，那只是语法上的一致，整个开发模式完全不同，更接近于原生 App 的开发而不是 Web。打个比方，对在看这篇文章的大多数人来说，读中文要比读英文更容易，但假如你看不懂英文版的《量子力学导论》，翻译成中文版你也不一定能看懂。开发小程序，需要有专门的、独立于 Web 团队之外的团队，按小程序的规范重新设计、重新开发，不能将已有的产品直接迁移过来。
可以理解微信当初做这个决定，是希望开发者按照微信的要求，为微信的用户重新去思考、设计一套全新的用户体验，而不是将已有的 Web 页面搬进来。历史上，包括 Microsoft 的 Windows Phone 平台、Google 的 Chrome Packaged App 都冒过类似的险，而其实 Apple 也做过类似的决定——Steve Jobs 2010 年 4 月亲笔写过一篇文章，解释为何 iPhone 不支持 Flash (Thoughts on Flash)，其中最重要的原因是，Apple 不希望第三方开发者将已有的产品直接搬过来，而是希望开发者能直接在 iOS (当年还叫 iPhone OS) 进行开发，为 iPhone 的用户提供最好的体验。这些决定赌的是，新平台 (小程序或 iOS) 带来的商业上的好处，最终会让开发者们愿意付出这个成本。
那时候的 iPhone 还很弱小，但后来的历史证明 Steve Jobs 赌对了——Adobe 公司今年 7 月宣布，将在 2020 年最终停止 Flash 的更新和分发。
微信，则在昨天支持了开发者直接嵌入已有网页。
所以，如果你已经有一个网站，可以直接在小程序中套个壳，把网站中的 Web 页面摇身一变成一个小程序。至于这和直接分发 Web 页面有什么区别——
产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
细心的你可能已经注意到了，上面这两条并没有任何变化… 对，在小程序的用法上其实没有任何变化，只是开发成本下降了。
那么，在今天之后，使用微信小程序框架开发的「原生」小程序，和嵌入已有的 Web 页面的「Web」小程序，在用户感受上会有什么区别呢？
「原生」小程序，整个小程序是提前下载的，不会有 Web 页面打开时的页面加载感。我们过去的可用性研究表明，这是用户对一个界面是「Web」还是「原生」的最主要判断标准。对于偏工具型的小程序，「原生」的感受应该会更好。
「原生」小程序对体验的控制更完整，自己要做的事情也更多。例如 Web 页面中用户可以选择页面上的文字复制，而在「原生」小程序界面中，这是需要单独添加的功能。
「原生」小程序提供了一些专属的控件和 APIs（接口），如展示群信息、发送推送等，这些只有使用小程序框架开发才能使用。
所以，如果需要和微信生态整合得更紧密，可以使用「原生」方式开发；如果追求快速迁移已有 Web 产品，嵌入 Web 页面更快。
