请教几个关于前端工作流程的问题

1.一般都是640，根据需要，主要也是方便设计，放到手机上可以直接图片看效果
2.大公司不知道，我们是前端切图，忙不过来的时候，设计帮忙弄下
3.device.width 适配比较多
4.没用过。。。

1 建议给320宽度的设计稿
2 自己抠。你可以以“没用PS”“不会PS”为借口不抠
3 参见1
4 新手别用，你至少要学两个月。

@jyz19880823 @FrankFang128 谢谢两位~~那看来我还是要认真学习下PS啊。关于viewport那个还是有点疑问，“device.width 适配比较多”是什么意思？其实我主要的想法是按照我的方法，我在页面开发的时候直接就可以用设计稿给的大小了不用再换算，在PC端直接一个max-width=640完事。如果是用设备宽度指不定在哪台手机上会出现奇奇怪怪的bug。。请再多指点指点

4. 用，请问单页有什么限制？

2. 可以偷懒，但不能不会。不是每个设计师都知道前端需要什么样的基础素材图片。其实很多时候，前端开发拿到设计稿的时候也不一一定能一次性处理完所有的基础素材图片。
4. 新手别用，这是个深坑。当然如果不怕被坑，也是可以跳进来。

@stranbird http://www.zhihu.com/question/20792064 参照下这个~

@isKira 使用 device.width，里边可以用百分比布局，flex 之类的，然后小手机到大手机都可以适配，至于 pc 端，还是加一个 media,限制一下最大尺寸就行了。一般网页里的字体图片都是在640的基础上除以2，然后使用 rem 宽度，根据 media 给不同的设备不同的 body的 fontsize，然后字体和图片在不同的设备上都能相应的放大缩小

@RaidNight 好的谢谢回答~现在公司比较小就我一个前端和设计，所以基本上磨合得还算默契，我慢慢学自己抠^ ^
用过一段时间Angular，也有做过一款产品级的移动应用，不算新手啦~但是现在在给一款PC端的产品做技术选型，觉得Angular还是不太适合，想放弃了。。

请考虑不同分辨率的手机、pad

@jyz19880823 感谢讲解！

我现在也正在做这一块。angularJS 这种框架更适合交互比较多的应用，如果是纯展示类型的应用就不太适用了。
至于知乎那个帖子里面的缺点，只有第一个 SEO 的问题有点超出了angularJS 的框架范畴。
这两个缺点
2、前进、后退、地址栏等，需要程序进行管理；
3、书签，需要程序来提供支持；
在angular中本身是不存在，因为 angularJS 使用Hash作为URL的补充。

1. 640相对好使，但关键还是要看设计自己要有“适应不同终端”的意识
2. PSD 组和层的名字和顺序有逻辑最好
3. 不觉得哪里费劲…… 或许是我不怎么追求“香酥鸡还原”吧
4. 不用，电脑上的页面我都嫌它重，单页的话以前backbone，现在exoskeleton挖掉Model和Collection。riotjs也不错

1. 按 640 (320@2x), 手 * 0.5.

2. 者都要, 要一份 SVG , 但 CSS sprite 之前端面的修改需要工程自己做.

3. 用 device width, 不同不是算比例等比放, 而是完全 responsive, 大屏幕示更多容. 以 4 inch iPhone 例, viewport 的度是 320, 因示是要 apply scale 的 (* 2). 地方坑很多, 不建非的做法. 例如某些 480 物理像素度的屏幕, 制定 scale 到 1.5 一 320 的 device width, 如果意指定 viewport 的度直接致示效果完全崩掉. (看起很吧但是很多就是的)
tldr: viewport 永使用量, 按 320 , 320@2x 的效果, 用百分比局, 用 background cover 代替 img 等等, 做到 fully responsive.

4. Angular 是很害, 但曲比陡, 慎重考.

@Elethom 看到这混排就确定是小爱无误了啊！谢谢回答~~(·ω·｀)

单页面至是 angular 的一个功能而已，重要的是写代码的方式，和 angular 的一些思想，可以说这是未来 ui 开发的趋势，
从 WebComponents 就可以看出来，对 dom 的操作的依赖会大幅降低，
而且github 的出现本身就让 ui 组件的维护变的简单，bower 等包管理的存在让 ui 库的复用性更好了，在大部分 ui 功能 通过 ui 开源组件完成的时候（不得不承认其实很多时候开源库的维护本身比自己维护更为靠谱），真正关心到的业务逻辑成了最重要也应该原本最该关注的问题，成为了主要工作，这个时候 angular 带来的开发效率和便利性是不可比拟的，
可以说是算是前端走向正轨的契机

如果真的写过 angular，会发现代码维护性会有很大一个层次的提高，组件，模块通过 directive 分离的非常好，单元测试也会更便利，复用性，维护性，开发效率显著提升，当然学习成本也是很高的，因为完全和现有的开发方式有了非常大的区别，我记得我开发一块挺复杂的交互功能的时候，近千行代码里没一行对 dom 本身的操作，可以想象

我们也算创业公司吧.. 问题有意思
1. 过
2. 我们用的 Skecth, 不过设计做得比较多, 图会切好再给我们, 不过我的项目图少
3. 过
4. 考虑到 Angular 中文站长在我们这.. 确实有几个项目在用, 而且上线. (但我是用 React 的..)

1. 现在已经开始用750px的图了，坑到不行＝＝直接出320px的图在R屏不能看，除非完全css实现不切图；
2. 虽然我也希望直接拿到jpg、png就能用，但实际上还是得自己切图；
3. 一般还都是device width吧，就像 @Elethom 说的，不同分辨率不是简单的缩放就能适配的；
4. 一般内部的项目会用，Angular学习曲线比较陡，如果想体验双向数据绑定可以先看看简单的，比如Vue.js。

1. 设计 640px 考虑到 @2x 需要保持一定的清晰度.
2. 前端手动切图, 因为设计师不知道你怎么实现和优化页面. (沟通成本很高
3. Width 不预设, 为适应更多设备应使用百分比.
4. Angular 大型应用可以考虑, 目前没有在线上项目用过, 不致评.

1. 设计稿一般 320~640 给手机用就可以了，如果要响应式（看你目前也用不到），应该至少三个版式（分辨率 320/720/1200）
2. 前端自己切图比较好，自己才知道需要什么素材（话说现在的趋势是少用图片，做相应式麻烦）
3. 你的页面是 1:1 还原设计图，然后通过缩放适配不同分辨率。这种做法是错的，你要用响应式的方法写页面，然后让页面不缩放显示在浏览器中
4. Angular 适合写 App，普通的展示页就用 jQuery 好了

题主去学习一下“响应式”吧，这个对你很重要。学完了去教给你们的设计师。

@isKira
@Elethom

回去考虑了一番，觉得有必要再拖 viewport 出来吊打一番。

我的结论是：viewport 的 width 应该只用 device-width 一个值，initial-scale 也应该只用 1，这样才能保证页面 1:1 显示出来（如此一来，也不需要用户再缩放页面，指定 user-scalable=no 即可）。

比如在 Nexus5(360*640 *3) 中，如果页面用 640px 写成，那需要设置 initial-scale 为 360/640=0.5625，就是需要将页面缩小到 360px 宽才能够完全显示（填充）在屏幕中，但这个并非整数倍缩放，会导致页面显示不清晰（只要是在非高分辨率屏幕上缩小，都会带来这个问题）。
所以，固定宽的页面通过缩放适应不同分辨率的屏幕，这种方法不好。

不过淘宝手机端是用类似的方式做的 http://www.html-js.com/article/2402 在 iPhone 5 上的 meta 片段：initial-scale=0.5, maximum-scale=0.5, minimum-scale=0.5, user-scalable=no 这里的 0.5 是算出来的。不过这种手段只适合高分辨率屏幕，低分辨率下缩放的网页各种毛边，你可以用 Chrome 模拟一下 iPhone5 来看 m.taobao.com 的效果。
body 的 font-size 和 screen 的高度也是通过 JS 计算的。

拙见，如错请指正。

@learnshare 综上所述都是用device width是主流~那就用device width吧_(:з」∠)_