一个app的Libraries文件（sketch文件啦）一共有四个，分别是图层样式**、文字样式、元素和组件以及模块库（这个我没有做）。
颜色上，我个人的习惯是把设计稿中的【背景色】、【按钮色】、【卡片样式】、【特殊的分割线样式】、【蒙层颜色】**及【常用的图标颜色】等在Libraries内样式，这些都是可复用且再之后的元素及组件库中可以用到的。

整理颜色样式我一般是根据上述说的内容，依次从设计稿中进行样式的复制（option+command+C/V）到作为Libraries的文件中来。为了避免最后变成杂乱无章的一堆，所以我对图层样式的摆放进行了简单的整理。

整理完毕后就开始建立图层样式吧。我图层样式的命名规范是采用英文命名的方式，方便和同事进行交接，命名格式为：base/colors/bg（或者card、content、mask、btn、icon/颜色色值或作用）。
敲小黑板，插一句简单讲一下“/”的意思。在sketch里，“/”的作用是进行分组，或者你可以把base理解为一个文件夹，colors是base文件夹下的一个子文件夹，而bg则是在colors文件夹下的一个子文件夹，一层套一层的关系。
通常我对于黑白红品牌色等易区分且或相似颜色的图层样式的命名基本直接用色值或颜色，如base/colors/bg/#FFFFFF或base/colors/bg/white，对于代表两种状态（如按钮可点击或不可点击状态）的颜色使用颜色+状态的命名方式，如：base/colors/btn/blue/nor及base/colors/btn/blue/sel
最终建立完毕图层样式看到的是这个样子：

然后将图层样式库保存，储存在一个特定文件夹内（最好不要在建立Libraries后移动位置，也不要和设计源文件混在一起），然后设置为Libraries。

（添加到library中）

然后我们可以打开一个新文件来验证一下Libraries是否可用。

（我这里尽管按钮颜色和icon中都使用了品牌蓝色，但是为了区分以及万一后期需要单独修改icon颜色，因此对icon中使用的品牌色单独建立了一个图层样式，灰色同理）

ok，没有问题，在command+N的新文件中图层样式组件库时可用的，那么就准备开始下一步吧！
然后来建立文字的Libraries。关于文字样式的设置，其实在进行设计的过程中我们就会为了便于样式的复用用而建立一些字体样式，但是可能从命名规范、样式的完整程度上并不是那么尽如人意，因此我们在这里也需要对现有的字体样式进行整理，且添加一些新的样式。
步骤还是和图层样式库的建立一致，先进行收集和整理，然后进行命名和设定文字样式。需要特别注意的是，尽管单行文字和多行文字可能字号、字重、对齐方式、颜色等一致，但是行高不同，因此在设置时我会使用两种文字样式来分别代表单行样式和多行样式。对于单行文字，根据开发的习惯，我会将line值调整为和文字大小一致。多行文字则line值一般为文字大小乘以1.2-1.5，因此这两个在建立的时候也要进行区别。

我这边一般设计使用的字体为pingfangSC，在字体使用上不会出现区分，因此在命名的时候就不考虑字体的区分问题了，我个人命名的规则是：字体/字号/字重/对齐方式/颜色/单行（or段落），这个规则也是可以因人而异进行更改的。
拿刚才的单行和多行文字为例：

单行文字：PF/12pt/regular/left/dark grey #999999/line12
多行文字：PF/12pt/regular/left/dark grey #999999/line16

如果没有单行和多行的区分，则不用考虑此项（命名方式看个人习惯，我说的也只是参考，大家结合自己具体工作中遇到了什么来定就可以）。
最终，整理之后的文字样式是这个样子的

可以看出因为这个设计稿在我接手之前有很多设计师去做，但是没有一个标准的规范，所以每一个设计师都按照自己的习惯和感觉去进行设计，最终交到我手里时候，设计稿里各种大小颜色的字基本都有，整理的我要吐血了。诚然，现在进行统一和规范是可以的，但是不建议，因为现阶段我负责的产品已经上线，所以如果贸然进行调整容易之后再和前端交付的时候出现问题，忘记了哪里调整了，哪里没有调整，因此先按照目前的设计稿进行Libraries的建立，之后还要结合线上版本逐步进行调整和规范，总之是一个非常麻烦的工作量，难受。

然后依旧按照建立图层样式的方式，将文本样式放在固定位置并设置为Libraries，这样一个Libraries的基石就打好了，现在我们要准备继续搬砖啦~

接下来是制作元素（element）库和组件（component）库，等这两个库做出来之后，距离我们通常意义上的一个软件的所有Libraries库建立就基本完成了。
那么可能有好奇宝宝又要问了，我现在储存了常用的颜色和图层样式、也对自己用的字体进行了规范，为什么不直接一步到位来制作组件（component）库，而是还要再做一个元素库？
对此我的理解是：通常一说起组件库，我们往往想到如何同语雀插件一样，由一个模块一个模块的组件们构成。诚然，组件化能够让设计更加方便和快捷，但是相应的，我们在工作中遇到的原型、功能可能并不能完全照搬现有的组件，因此除了成型的组件外，我们还需要比组件更细致的“零件”们来构成界面与创造丰富的新的界面。因此在制作组件库（component）之前，我们还需要建立一个元素（element）库。
为什么这两个要一起说呢？因为一开始我也经常搞不清楚元素和组件以及模块的区别以及制作他们的意义。不过经过工作中的整理和不断尝试，我发现如果将组件区分的越仔细，那么组件库的拓展性越强。
好了好了，如果你觉得上面一段话宛如天书，内心中充满什么是元素库、什么是组件库、什么是模块库的黑人问号，那就先看下文，再回头来琢磨上文。
我先来说说我是如何判定什么是元素（element）、什么是组件（component）、什么是模块（module），希望能对大家的工作有所帮助，当然如果有更好的区分方法也非常欢迎斧正。
我们来用比较常见的商品卡片为例来进行说明：
首先，我通常会把一个完整的商品卡片称之为component，因为它相当于一块哪里需要去哪里的小板砖，我们可以在首页里推荐商品的板块中看到他，在搜索之后的结果页的瀑布流里看到他，也有可能出现在资讯文章下方的相关商品板块中，他就像一块小板砖，可以去砌墙，可以去做壁炉、也可以去垫桌脚（？），这个商品卡片可以被用来去组成app中其他常见的板块。同时，这个商品卡片并非组成一个板块或页面的最小单位，他又可以进行拆解，例如一个商品卡片可以由一个带阴影的bg+商品图片+商品名称+商品规格+价格+销量+促销标签（这个可能会没有）组成。这些拆解出来的东西，我称之为元素。这个由元素构成的商品卡片，我称之为组件，而由这个商品卡片加其他的组件、文字或者元素构成的app组成部分，我称之为模块。（这个不是我发明的，也是拆解别人的源文件结合自己的理解来说的）
这三者的关系非常像化学里的分子、原子关系，一环包含一环。所以在做这一部分的整理时，我通常是三者同时进行。
如何进行整理呢，我们依旧用商品卡片为例。

（以商品卡片为例进行说明）

我们可以看到商品卡片的样式会有有特价或热销标签的样式（显示原价）、没有特价热销标签的样式（不显示原价），商品名称为单行的样式、商品名称为两行的样式，这些要怎么进行整理呢？每一种卡片建立一个symbol？那样组件库整理出来会非常庞大，所以我的做法是这样的。
首先，通过观察我们发现，上方的两个卡片其实是下方的两张卡片的高配版本（增加了价签和划掉的原价），因此只要整理上面两张卡片的样式即可包括下面卡片的样式了。
于是我们先将这两张卡片粘贴至在元素库或者组件库文件中（目前这两个现在一个sketch文件中制作）中，然后使用之前整理的文本样式库和图层样式库对卡片中的文字和bg进行添加样式（如果在设计的时候已经使用Libraries进行规范，这一步请跳过）

（让页面由图层样式和文本样式组成）

然后我们将页面中的元素进行整理和建立元素库。在这里先说一下什么是元素（element）,我认为可以放到元素库中的内容包含但不限于Icon、Btn、头像、线条、输入框、弹窗、标签、制作成symbol的文字以及其他难以单独分类的杂项（misc） 等，这些在工作中遇到的时候大家根据自己的app实际情况去分析就好。继续用商品卡片去说，首先我们将元素规范命名、建立成为symbol，命名原则比较像之前的图层样式及文字样式命名原则，以卡片上方的“热”和“特”标签命名为例，我是这么进行命名的：element/tag/card tag/hot以及element/tag/card tag/discount
（这里注意之所以在card tag前增加一个tag的分组是因为我的app中tag样式并不止这一种，所以为了进行快速选择和区分，多增加了一个层级）
然后就可以在选中这个tag标签的时候惊喜的发现，能够快速的进行这两个tag样式间的切换了!

（两个tag样式之间可以进行切换）

同理，我们也对页面中的占位图和商品图片，以及划去的原价文字进行建立symbol操作（为什么只有这里的文字为什么要建立symbol请往后看）。然后，我们对除了tag之外的商品卡片基础款（两种样式，商品名称一行时和商品名称两行时）分别进行symbol建立，当然卡片因为是由各种元素组成的，是一个组件，所以在命名上格式为component/card/2line（1line），在做完这一步之后，然后我们就发现当点击中卡片后，单行样式卡片和双行样式卡片可以进行切换了。

（卡片样式单双行进行切换）

同时，我们发现当选中被划掉的原价那一项时，除了更改里面数字的数值外，还能选择“none”不显示，然后该项就消失啦。

（选择none则此项不显示）

这样的商品卡片内容不正是前文中说的没有标签的“基本款样式”嘛。然后我们将商品卡片的symbol（这是一个component）和标签的symbol（这是一个element）组合为一个带标签的symbol，不过他本质还是一个商品卡片，所以在命名的时候依旧使用component来进行命名。这个时候我们的商品卡片完全可以用一个symbol来囊括所有卡片样式了。这样一个卡片的元素和组件库就算建立完成了。app中其他的部分同理用这个方式进行整理即可。最终得到的文件是一个元素和组件库混合而成的源文件。当我们打开symbol页面的时候可能会发现，所有的element和component都混在了一起，非常的混乱，怎么办呢？

（未经过整理的symbols页面）

打开symbols页面有可能是这个样子，当然如果内容特别多的话也有可能更乱这个时候给大家安利一个插件：Symbol Organizer，使用它进行整理后，他可以自动根据你命名时候的“/”对相同层级归类的内容进行整理，最终得到的是这样的一个页面。

（使用插件整理完毕后）

在整理完毕后将页面放在特定的文件夹里，建立为Libraries，组件的整理工作就算完成啦。至于模块库我并没有建立，如果大家想建立的话，方法同元素和组件库的建立。最后的最后在整理工作完成后，记得使用脑图软件去做一个元素库和组件库的梳理，因为无论是交接给同事还是自己在接下来的工作中配合app迭代进行不断的更新Librarie ，有可能会因为时间间隔太久或者负责的app太多而忘记之前所做分类的结构，所以与人方便也与自己方便嘛。

（归拢好的组件库结构图）

额外的：
设计师应该懂的 7 个技术知识点

APP / 网站是怎么运行的？

我们首先了解一下“前端”和“服务端”的概念，《产品经理必懂的技术那点事儿》中是这么描述的：

• 互联网产品技术架构整体分为两部分，分别是前端和服务端，前端和服务端通过中间网络进行数据传输。
• 前端就是用户使用的客户端，包括最初使用个人电脑通过浏 览器进行网页浏览，现在通过智能手机使用App进行一系列的操作。
• 服务端包括应用服务器和数据库，应用服务器用来部署服务端程序，处理前端请求并进行服务响应，数据库用来存储数据，服务器通过专门与数据库进行交互的程序对数据库进行读写操作。

——《产品经理必懂的技术那点事儿》

如果没有接触过技术方面的知识，光读文字可能有些不容易理解，举女生喜欢逛的淘宝APP的例子：
比如小红，小红打开淘宝进入首页会看到商品列表，商品列表包含了：商品图、商品名称、商品销量等等。

问：商品列表里的这些信息从哪里来的呢？

你可能会说“是卖家在后台创建的。”

没错，就是卖家在后台创建的，那么这些信息又是怎么跑到小红的淘宝APP里面的呢？

例子中的商品信息从后台传到淘宝APP的过程就是一个互联网的运行机制，数据不会凭空从后台跑到前台，数据的流动过程就是我们需要了解的知识点。

下面讲解小红淘宝里的商品列表中的数据的流动过程：
**

• 首先，卖家在后台创建一条商品信息，比如一条裙子。
• 输入商品基本信息：尺寸、颜色、板式等等
• 然后卖家提交了这些信息或者说叫数据，提交后这条商品数据去哪里了呢？
• 得有地方存储这些数据呀，存储这些信息的地方就叫做数据库。

这时候小红在淘宝APP里购买了这条裙子，这时候裙子的库存就减去了1，相应的卖家后台里裙子的库存也减去了1。

问题来了，为什么淘宝APP购买了后台的库存就相应改变呢？谁做的计算？
嗯，计算和处理这些信息的就是服务器。

商品信息存在数据库中，通过中间网络（也就是互联网）传到到了APP中，小红在APP购买了商品，APP发送请求原路返回到服务器进行处理，然后服务器返回请求给APP告诉他“你购买成功啦！”

再举个简单的例子

• 比如登录的时候，我们输入手机号和密码
  
• 点击提交后，前端就将信息传输到服务端，查询输入的手机号之前有没有注册过，密码是否正确
  
• 如果已经注册且密码正确，服务端就告诉前端“你可以登录啦”
  
• 如果没有注册过或者密码错误，服务端就会告诉前端“你没注册啦”或“密码错误啦”
  

iOS和安卓的布局原理

了解iOS和安卓的布局原理可以帮助我们更好的适配。

安卓的线性布局

由上到下依次排列的布局方式叫作“线性布局”，线性布局简单说就是按照顺序从左至右或者从上到下依次在界面上排列控件——《产品经理必懂的技术那点事儿》

上下线性布局比如表单填写界面的控件上下依次排列。

左右线性布局比如搜索页面的热搜词，很多时候热搜词的字数不一样。

设计师在描述换行的时候可能会标注大段文字比如“间距都为34，从左至右依次排列，遇到距离屏幕边界15时换行”。

现在我们了解了布局原理，直接说一句“线性布局，边界离屏幕15”就可以啦，是不是提升了效率的同时又让研发小哥哥对你刮目相看呢。

相对布局也是经常使用的，比如说下面的相对布局案例。

web APP和native APP

移动App的实现有两种形态，一种是通过Web的方式实现，也就是在App内部通过加载Web网页的方式实现产品功能；另一种是Native或者叫原生的方式实现，这种方式是使用移动平台原生的控件开发而成。
——《产品经理必懂的技术那点事儿》

web APP也就是H5，native APP也就是原生APP。

我们经常会听到这个词汇： H5，H5实际上是HTML的版本号，之前还有HTML4、HTML3等；HTML称为超文本标记语言，感兴趣的小伙伴可以在书里了解更多。

现在基于Web技术的开发基本都是基于H5技术进行的，web APP就是通过web/H5实现的界面，相当于在APP内部加载了一个网页界面。

那么为什么需要H5呢？

我们都知道APP的更新需要重新下载安装包，安装成本不低，而H5更加灵活，只要前端更改发布后，APP里进行加载后就更新了，是不是快很多。

比如说现在很多电商网站的活动运营页面，这些页面需要经常更换活动，如果靠下载APP更新的话， 那搞活动可太难了，但是如果用H5的话，今天双十一明天狂欢节天天剁手……

既然H5 这么棒，为APP里不全部使用H5 呢？

嗯，最开始我也是这么想的。其实H5虽然很灵活，可是H5的体验上不管是流畅度还是性能上都比不上原生。

H5 or 原生？

• 如果内容变更小，对流畅度和性能要求高，那么用原生。
• 如果内容变更大，尤其是一些运营内容，H5也许是更好的选择。
• 但是现在的APP很少用纯H5 或纯原生，用Hybrid APP开发更多。

Hybrid App是一种混合开发技术。

Hybrid App是一种混合开发技术，所谓混合开发就是指在一个产品中同时使用 Native技术和Web技术。根据产品使用场景的需要和技术框架设计，在不同的页面 或者同一个页面的不同模块同时使用Native和Web技术，这种通过混合技术开发实 现的产品就叫作Hybrid App。——《产品经理必懂的技术那点事儿》

意思就是同时使用原生和H5。

cookie 和 session的区别
Cookie是将信息存储在本地， 而Session是将信息存储在服务器端。

不知道大家有没有这样的体验，当你用谷歌浏览器登录一个网站的时候，输完账号密码后，谷歌浏览器会提示“是否保存账号密码”。

当你下次用你的谷歌登录这个网站的时候，输入账号就能够填充密码。

但是当你换了一个新浏览器进入这个网站的时候，输入账号时就不能填充密码。但是只要你账号密码输入正确了，你还是能进入网站。

谷歌存储的账号密码就是cookie，服务器存储的账号密码就是session。

所以当你换了新浏览器登录的时候，浏览器不会提示你的登录密码，当你登录进去网站后你的账号信息还在。

“接口”是什么？
接口这个名词我想除了技术，产品经理应该接触的最多，交互设计其次，UI设计应该接触得最少。但我觉得非常有必要了解接口的概念。

接口也就是API，估计API听过挺多次的，很多大厂都会出自己产品的API方便其他产品调用，比如百度地图的API。《产品经理必懂的技术那点事儿》中说“数据接口是指客户端与服务端进行数据传输和交互的数据协议，数据接口是一种数据交换的标准。”

我之前看过一篇文章，里面对接口的描述我觉得是最易懂的（这篇文章感兴趣的同学可以谷歌“API接口入门（一）：读懂API接口文档”）。

文章里说：

• 如果我们把常见的函数公式 y=x+2 看成一个接口，那么当x=2的时候，y=4。
  
• 此时我们把 y=x+2 称为接口，x称为参数，y称为返回的结果
  
• 那这个接口的功能就是能把我们输入的数加上2。
  

接口就是预先定义的函数逻辑，他是供其他系统请求，然后返回结果的一个东西。
是不是超级容易理解的！

下面举几个API的案例，相信大家在注册登录的时候都遇到过拼图等验证方式，大多数网站使用的技术都是第三方的，比较知名的是极验，直接使用极验的API借口就可以实现行为验证等多种验证方式，大大地节省了开发成本。

开发口中的“写死”到底是什么？
我刚进入互联网行业的时候对“写死”这个词还挺疑惑，为什么叫写死，感觉不是很“正经”的赶脚……

其实“写死”这个词的确不算是标准术语，它的意思从字面上也能大概猜出几分，“死”的意思就是不变的，不改动的。

互联网产品的数据分为前端写死和后端服务器传输。
举个例子，淘宝的tab栏切换图标应该就是写死的，数据是放在客户端也就是淘宝APP中的；

而淘宝商品列表的商品图、商品标题、商品价格就是“活”的，要专门写一个接口去获取服务器的数据，所以淘宝的商品才会千变万化而不是固定不变的。

在设计过程中需要考虑哪些数据适合“写死”，哪些数据需要接口传输。

一般来说，对于不经常变更的数据可以“写死”，比如tab切换栏、APP的导航栏架构等，数据的“写死”一方面减少前端的工作量另一方面也能提升APP的流畅度，毕竟可以减少获取数据的时间。

而对于一些经常变更的数据就不适合“写死”，比如说商品列表、运营位等。
控件和组件有什么区别？
说真的，控件和组件的区别我想还是有很大一部分设计师没有做过区分的，感觉听上去差不多呀。

任何一个网页或者App产品都是由大量的输入框、按钮、文本展示框构成的，产品中的这些最小界面元素组成单元就叫作控件。 件是一种功能更全面的升级版控件，或者可以把组件理解成多个控件的组合。 ——《产品经理必懂的技术那点事儿》

有点原子和分子的意思，原子组成分子，而控件组成组件。组件有一个“组”字，就意味着它是一个组合。这样就很好理解了。

1、Runner 使用命令行来提高你的工作效率
2、Cfaft 帮你提高效率的自动填充神器
3、Rename it 快速批量重命名你的图层
4、Remove Unused Symbols 一键删除未使用的
5、Artboards to PDF 批量导出选定画板为多页 PDF
6、ImageOptim 一键导出所有切片资源并自动优化体积
7、Sketch Measure 快速创建规范为开发者和团队协作提供方便
8、Midnight 增加替换主题功能及小工具
9、Flavor 给你的设计加点料
10、Sketch2AE 轻松导出 Sketch 资源至 AE 并自动定位
11、Anima 可以实现自动布局
12、Abstract Sketch文件版本管理软件