前台开发和前端开发有区别吗

一、前台开发和前端开发有区别吗

1、“前台”一般来说和“前端”是一样的，就像“美工”和“设计师”。在多数人眼里前端就是切片仔（页面仔），前端为“前台”，认为前端的工作就是“切片”（切图片）。前端就是这样发展过来的，不过现在前端开放了新的技能树，有许多新技能。总的来说，要掌握的基础知识还是HTML(5),CSS(3),Javascript。

2、移动客户端的开发类型主要是三种：

3、NativeApp（原生APP），也就是完全使用移动设备系统语言写的客户端，iPhoneiPad就是纯Object-C，安卓就是纯JAVA,就是用户看到的界面啦体验到的交互啦都是原生的。

4、WebApp,这个就是在移动浏览器里打开的，纯HTML+CSS+JS，在浏览器里打开的页面。

5、HybridApp.[HTML5inmobiledevices]使用HTML+CSS+JS来实现用户界面和交互。

6、前端是个很大的概念，用户能够看到，直接接触到的层面都算是前端，比如IOS客户端界面，安卓客户端界面，网页界面，甚至PC/MAC桌面端软件界面，现在最常见的说法一般是指Web前端，也就是针对于网页端开发的工作。

二、Web前端开发与iOS终端开发的异同

前端和终端作为面向用户端的程序，有个共同特点：需要依赖用户机器的运行环境，所以开发语言基本上是没有选择的，不像后台想用什么就用什么，iOS只能用Objective-C，前端只能javascript，当然iOS还可以用RubyMotion，前端还能用GWT/CoffieScript，但不是主流，用的人很少，真正用了也会多出很多麻烦。

这两者有个有意思的对比：变量/方法命名的风格正好相反。苹果一直鼓吹用户体验，写代码也不例外，程序命名都是用英文全称并且要多详细有多详细，力求看变量和方法名就能知道是干嘛的，例如application:didFinishLaunchingWithOptions:。而js因为每次都要从网络下载，要力求减少代码体积，所以变量方法名是尽量用缩写，实际上有代码压缩工具，无论变量名写多长最终上线的效果是一样的，但大家也都习惯了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js里习惯的命名是:$()。

objc与js都是动态语言，使用起来还蛮像，但objc是编译型，速度快，很多错误也能在编译过程中被发现，js是解释型，性能依赖于解释引擎，即使在强劲的v8引擎下性能也赶不上编译型语言，语言太动态，变量完全没有类型，写起来爽，debug起来稍微费点劲。一直感觉js轻巧灵活放荡不羁充满各种奇技淫巧，objc中规中矩没c++ java那么严肃也没有js那么灵活。

前端开发几乎不需要线程这个概念，浏览器实现上页面HTML和CSS解析渲染可能与js不在同一个线程，但所有js代码只执行在一条线程上，不会并发执行，也就不需要考虑各种并发编程的问题。在新的JS特性中可以创建worker任务，这样的任务是可以另起一条线程并行执行的，但由于并不是所有浏览器都支持，不同线程传递数据各个标准定的还不一样，使用场景也少，似乎没有大规模用起来。对于数据库操作/发送网络请求这样的任务是在不同于js代码执行线程的，不过这些都由浏览器管理，前端无需关心也无法影响这些线程，只需接收事件回调，不需要处理任何并发问题。

终端开发需要大量使用多线程，iOS有一条主线程，UI渲染都在这个线程，其他耗时长的逻辑或者数据库IO/网络请求都需要自己另开线程执行，否则会占用主线程的时间，导致界面无法响应用户交互事件，或者渲染慢导致滚动卡顿。程序逻辑分布在多个线程里跑，需要处理好各种代码并发执行可能带来的数据不一致/时序错乱之类的问题，并发也导致有些bug难以排查，一不留神就掉坑，需要适当用一些队列/锁保证程序的执行顺序。iOS提供了一套多线程管理的方法GCD，已经把线程和队列封装得非常简单易用功能强大，比其他端或后台是好很多了，但还是会花大量功夫在处理多线程问题上。

终端开发需要大量的数据存储逻辑，手机APP不像浏览器，用户打开浏览器必定是连着网，但打开一个APP时很可能是离线，也很可能处于网络状况极差的移动GPRS，所以必须把之前请求回来的数据保存好。保存数据后又需要与服务端最新的数据同步，如果全量同步数据量太大，耗流量速度也慢，于是需要增量同步，需要与服务端一起制定实现增量数据返回的方案，需要处理好客户端与服务端数据一致性的问题。当数据存储量大结构复杂时，还需要利用好有限的内存做cache，优化各类存储查询性能。

前端在桌面端很少需要存储，除非是Single Page App，不存储自然就不需要数据更新的一系列工作，数据都是从后台取出拼接后直接显示到页面上，即使像微博有可以在页面内不断加载更多数据，数据也只存在于内存，不会持久化存储，因为桌面端网速稳定，不计流量，所有数据可以直接从后端拿取，客户端没必要再做一套存储。移动端那些做得很像原生APP的Web应用就跟终端开发一样了，数据同样保存到SQLite，存储逻辑以及要处理的问题都差不多。

在第三方框架上Web前端和iOS开发完全相反，Web原生弱小又十分开放，让大量第三方框架和类库可以施展拳脚，而iOS原生强大又十分封闭，导致第三方框架没有多少生存空间。

浏览器一开始只为内容型的网页而设计，js也只是这个网页上能加点小特效的脚本语言，在Web应用时代跟不上发展，需要很多第三方库和框架辅助，再加上前端开发是完全开放的领域，导致库和框架百花齐放多如牛毛，在初期多数库的作用集中在封装dom操作，大家不断重复造dom操作基础库的轮子，在一段时间百家争鸣后独尊jQuery，在有使用库的网站中90%以上使用jq，几乎成了个标准基础库。后期大家已经不再重复造这个基础库的轮子了，多了一些代码组织和前端架构的框架，例如一些帮助项目模块化的框架require.js，MVC框架backbone/angular.js等。

iOS开发苹果已提供了完整的开发框架cocoa，而这框架在每一代系统中都在升级优化和添砖加瓦，开发模式也已经定型，第三方框架没有多少生存空间，大量流行的开源项目是一些通用组件和库，像网络请求库AFNetworking，数据库操作库FMDB。而一些大的框架像beeFramework/ReactiveCocoa较难流行起来。

前端开发需要兼容大——量的浏览器，桌面的chrome，safari，ie6-ie10，firefox，以及各种套壳猎豹360等浏览器，移动端iOS/Android各自的浏览器，以及无限的不同的屏幕尺寸。看起来挺可怕，实际上也没那么难搞，只是拿出来吓唬下人。桌面端chrome/safari以及各种套壳的极速模式用的都是Webkit，差异很小，firefox也大体遵从标准实现，与Webkit差别不大，旧的ie6/7就需要特别照顾，不过很多网站都不支持ie6了，移动端更是一家亲，全是Webkit，除了新特性上的支持程度不一，其他差异不大。对于不同的屏幕尺寸，高端点的会用响应式布局，针对不同屏幕尺寸自适应到不同布局，一般点的桌面端定死宽度，移动端拉伸自适应宽度就搞定。

终端开发也需要兼容各种不同的系统版本和手机尺寸，Android不用说，iOS也有3.5/4/4.7/5.5/9.7英寸这些尺寸，不过兼容起来跟Web一样挺容易，就是自适应宽度，iOS的UIKit把这些都处理好了，还有autolayout，sizeClass等高级特性可用，在尺寸上并不用花太多功夫。系统版本上iOS7为分水岭，iOS7前后版本UI上差异比较大，需要做一些功夫兼容，不过iOS用户更新换代很快，预计再过一两年iOS7以下用户就可以忽略了。

终端和前端都是面向用户的，性能优化目的都是尽快呈现内容，以及让程序在用户操作下流畅运行。终端主要关注的是存储/渲染性能。当一个APP存储数据量大，数据关系复杂时，数据查询很容易成为性能瓶颈，需要不断优化数据存取的效率，规划数据IO线程，设计内存cache，利用好终端设备有限的内存，渲染上避免重复渲染，尽可能复用视图，寻找最高效的渲染方案。

前端关注页面加载速度，由于Web页面的结构/样式/程序/资源图片都是实时请求的，要让页面更快呈现内容，就要优化这些请求，让这些资源以最快速度加载下来，包括合并图片/合并代码减少请求数，压缩代码，并行请求，根据版本号缓存代码请求，gzip压缩，模块/图片懒加载等。此外跟终端一样也关注渲染性能，遵从一些规则避免页面reflow，避免使用CSS阴影这样耗性能的特效，用CSS3动画代替js等。

终端开发需要编译的过程，把程序编译成机器语言，再与各种库链接后生成平台对应的可执行文件，最后由操作系统调度执行。在iOS终端开发中编译和链接的规则苹果已经在xcode这个开发工具上封装好，一般开发可以不用关心，但有深层需求时还是需要跟编译打很多交道，例如用编译前端Clang自定义静态代码检测规则，写编译脚本做自动化编译和持续集成，打包生成静态库，根据链接后的可执行文件的组成优化APP体积等。

前端开发的程序则不需要编译过程，只需要把代码扔给浏览器，浏览器边解析代码边执行。虽然js/css代码写完无需做任何事情浏览器就可以解析执行，但为了上面说的性能优化，前端代码上线前会对所有代码和资源文件进行处理，这些处理包括：压缩合并js/css，合并css sprite图，处理模块依赖，处理代码资源版本号，处理资源定位等。这个过程很像传统程序的编译，把给人看的代码优化处理成给机器看的，并解决一些依赖关系，可以算是前端的编译过程。像grunt.js/fis这些工具可以帮助完成这个编译过程，通常前端编译跟上线部署结合在一起，作为上线系统的一部分。

前端和终端的安全性问题上虽然不需要像后端考虑得那么多，但还是有些需要注意。在请求的安全上，终端和前端都一样，用户向后端发送的请求都需要经过层层路由，不知道在哪里就被截获篡改或回放了，于是需要做一些措施防御这些情况，最常见的就是身份验证，多是采用会过期的token形式代替用户名密码，防止被抓包后黑客可以永远登陆这个账号。数据安全要求高的会用加密传输，或者使用https，另外还需要看情况处理一些DNS劫持，运营商广告植入等问题。

其他安全问题终端很少考虑，在未越狱的iOS机器上系统已经帮忙保证了整个APP运行环境的安全，而在越狱的机器下恶意程序拥有root权限可以做任何事情，APP也难以防范。前端方面浏览器的特性使前端开发有几个安全隐患，一是Web页面上任意位置都可以动态插入js代码，浏览器会无区别地执行这些代码，二是身份验证信息都统一保存在cookie里，三是页面上可以随意通过iframe嵌入其他网站的页面。造成XSS、CSRF、cookie劫持这些攻击手段，所以前端写代码时都需要考虑还这些安全问题，做好相应的防范，最简单和重要的防范就是对所有用户输入输出的内容做完整的过滤，避免页面内被嵌入恶意代码。

最后说下对这两个领域在交互和开发上的个人感触。以前在做Web前端时，感觉Web让人机交互倒退了十年，交互都是硬邦邦的点击—啪一下出来结果，滚动是一格格地刷新，很多人当时在鼓吹html5可以做出多么炫的效果时，实际上FLASH在十年前就可以做出来了，还比最现代的浏览器更流畅。iPhone流行后，人机交互终于恢复了应有的水平，体验上比Web流畅太多，指尖交互/流畅的动画/便捷的滑动手势/无限制的实现，主流终于恢复或超越了十年前Flash的水平。

但人机交互提升了，开发方式却大倒退，Web的开发方式非常先进，用户用到的都是最新版本，发现bug可以马上上线秒修复，特别适用于互联网环境下的快速迭代，而终端APP不行，撇开iPhone的审核不说，Android也无法做到保证用户用的是最新的程序，用的都是传统的客户端更新的方式，bug的修复版无法及时给到用户，无法一天上线几十次，需要维护很多旧版本，开发方式倒退回Web时代以前。这都是因为移动网络不稳定以及流量有限造成的，移动端无法像桌面端浏览器那样完全依赖网络，所以在移动网络稳定流量免费之前，开发方式都不会有多大变化。

另外并不看好HTML5，网络上说它可以取代APP说了三四年，到现在也没什么战绩，我看不到它的优势，原生APP可以获得更多的系统资源，更流畅的人机交互体验，HTML5在这方面永远比不上，而它在移动端网络和流量的限制下也无法发挥Web的开发优势，所以它不会成为主流，只适合做一些轻量的小东西。

三、开发客服端前端写页面应该用什么开发,需要注意什么吗

1、首先我们来看看webkit内核中的一些私有的meta标签，这些meta标签在开发webapp时起到非常重要的作用

<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" name="viewport">

<meta content="yes" name="apple-mobile-web-app-capable">

<meta content="black" name="apple-mobile-web-app-status-bar-style">

<meta content="telephone=no" name="format-detection">

第一个meta标签表示：强制让文档的宽度与设备的宽度保持1:1，并且文档最大的宽度比例是1.0，且不允许用户点击屏幕放大浏览；

第二个meta标签是iphone设备中的safari私有meta标签，它表示：允许全屏模式浏览；

第三个meta标签也是iphone的私有标签，它指定的iphone中safari顶端的状态条的样式；

第四个meta标签表示：告诉设备忽略将页面中的数字识别为电话号码

在开始编写webapp时，哥建议前端工程师使用HTML5，而放弃HTML4，因为HTML5可以实现一些HTML4中无法实现的丰富的WEB应用程序的体验，可以减少开发者很多的工作量，当然了你决定使用HTML5前，一定要对此非常熟悉，要知道HTML5的新标签的作用。比如定义一块内容或文章区域可使用section标签，定义导航条或选项卡可以直接使用nav标签等等。

在项目开发过程中可以会遇到内容排列显示的布局，假如你遇见这样的视觉稿，哥建议你放弃float，可以直接使用display:inline-block;

这个按钮有圆角效果，有内发光效果还有高光效果，这样的按钮使用CSS3写是无法写出来的，当然圆角可以使用CSS3来写，但高光和内发光却无法使用CSS3编写，

这个时候你不妨使用-webkit-border-image来定义这个按钮的样式。

-webkit-border-image就个很复杂的样式属性。

请保证将每条数据都放在一个a标签中，为何这样做？因为在触控手机上，为提升用户体验，尽可能的保证用户的可点击区域较大。

在编写CSS时，我不建议前端工程师把容器（不管是外层容器还是内层）的宽度定死。为达到适配各种手持设备，我建议前端工程师使用自适应布局模式（支付宝采用了自适应布局模式），因为这样做可以让你的页面在ipad、itouch、ipod、iphone、android、web safarik、 chrome都能够正常的显示，你无需再次考虑设备的分辨率。

上一节，我们说过自适应布局模式，有些同学可能会问：如何在移动设备上做到完全自适应呢？很感谢webkit为display属性提供了一个webkit-box的值，它可以帮助前端工程师做到盒子模型灵活控制。

8、如何去除Android平台中对邮箱地址的识别

看过iOS webapp API的同学都知道iOS提供了一个meta标签:用于禁用iOS对页面中电话号码的自动识别。在iOS中是不自动识别邮件地址的，但在Android平台，它会自动检测邮件地址，当用户touch到这个邮件地址时，Android会弹出一个框提示用户发送邮件，如果你不想 Android自动识别页面中的邮件地址，你不妨加上这样一句meta标签在head中

<meta content="email=no" name="format-detection"/>

9、如何去除iOS和Android中的输入URL的控件条

你的老板或者PD或者交互设计师可能会要求你：能否让我们的webapp更加像nativeapp，我不想让用户看见那个输入url的控件条？

答案是可以做到的。我们可以利用一句简单的javascript代码来实现这个效果

请注意，这句代码必须放在window.onload里才能够正常的工作，而且你的当前文档的内容高度必须是高于窗口的高度时，这句代码才能有效的执行。

我曾经也想禁止用户旋转设备，也想实现像某些客户端那样：只能在肖像模式或景观模式下才能正常运行。但现在我可以很负责任的告诉你：别想了!在移动版的webkit中做不到！

至少Apple webapp API已经说到了：我们为了让用户在safari中正常的浏览网页，我们必须保证用户的设备处于任何一个方位时，safari都能够正常的显示网页内容（也就是自适应），所以我们禁止开发者阻止浏览器的orientationchange事件，看来苹果公司的出发点是正确的，苹果确实不是一般的苹果。

iOS已经禁止开发者阻止orientationchange事件，那Android呢？对不起，我没有找到任何资料说Android禁止开发者阻止浏览器orientationchange事件，但是在Android平台，确实也是阻止不了的。

11、如何检测用户是通过主屏启动你的webapp

看过Apple webapp API的同学都知道iOS为safari提供了一个将当前页面添加主屏的功能，按下 iphoneipodipod touch底部工具中的小加号，或者ipad顶部左侧的小加号，就可以将当前的页面添加到设备的主屏，在设备的主屏会自动增加一个当前页面的启动图标，点击该启动图标就可以快速、便捷的启动你的webapp。从主屏启动的webapp和浏览器访问你的webapp最大的区别是它清除了浏览器上方和下方的工具条，这样你的webapp就更加像是nativeapp了，还有一个区别是window对像中的navigator子对象的一个standalone属性。iOS中浏览器直接访问站点时，navigator.standalone为false,从主屏启动webapp时，navigator.standalone为true，我们可以通过navigator.standalone这个属性获知用户当前是否是从主屏访问我们的webapp的。

在Android中从来没有添加到主屏这回事！

我们知道在iOS中，当虚拟键盘弹出时，默认情况下键盘是开启首字母大写的功能的，根据某些业务场景，可能我们需要关闭这个功能，移动版本webkit为 input元素提供了autocapitalize属性，通过指定autocapitalize=”off”来关闭键盘默认首字母大写。

13、iOS中如何彻底禁止用户在新窗口打开页面

有时我们可能需要禁止用户在新窗口打开页面，我们可以使用a标签的target=”_self“来指定用户在新窗口打开，或者target属性保持空，但是你会发现iOS的用户在这个链接的上方长按3秒钟后，iOS会弹出一个列表按钮，用户通过这些按钮仍然可以在新窗口打开页面，这样的话，开发者指定的 target属性就失效了，但是可以通过指定当前元素的-webkit-touch-callout样式属性为none来禁止iOS弹出这些按钮。这个技巧仅适用iOS对于Android平台则无效。

14、iOS中如何禁止用户保存图片＼复制图片

我们在第13条技巧中提到元素的-webkit-touch-callout属性，同样为一个img标签指定-webkit-touch-callout为none也会禁止设备弹出列表按钮，这样用户就无法保存＼复制你的图片了。

我们通过指定文字标签的-webkit-user-select属性为none便可以禁止iOS用户选中文字。

桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的，但在iOS中你会发现这两个属性是未定义的，为什么呢？因为在iOS中没有滚动条的概念，在Android中通过这两个属性可以正常获取到滚动条的值，那么在iOS中我们该如何获取滚动条的值呢？

通过window.scrollY和window.scrollX我们可以得到当前窗口的y轴和x轴滚动条的值。

当你指定了一个块级元素时，并且为其定义了边框，设置了其宽度为100％。在移动设备开发过程中我们通常会对文本框定义为宽度100％，将其定义为块级元素以实现全屏自适应的样式，但此时你会发现，该元素的边框(左右)各1个像素会溢了文档，导致出现横向滚动条，为解决这一问题，我们可以为其添加一个特殊的样式-webkit-box-sizing:border-box;用来指定该盒子的大小包括边框的宽度。

18、如何解决Android 2.0以下平台中圆角的问题

如果大家够细心的话，在做wap站点开发时，大家应该会发现android 2.0以下的平台中问题特别的多，比如说边框圆角这个问题吧。

在对一个元素定义圆角时，为完全兼容android 2.0以下的平台，我们必须要按照以下技巧来定义边框圆角：

1＼-webkit这个前缀必须要加上（在iOS中，你可以不加，但android中一定要加）；

2＼如果对针对边框做样式定义，比如border:1px solid#000;那么-webkit-border-radius这属性必须要出现在border属性后。

3＼假如我们有这样的视觉元素，左上角和右上角是圆角时，我们必须要先定义全局的(4个角的圆角值)-webkit-border- radius:5px;然后再依次的覆盖左下角和右下角，-webkit-border-bottom-left-radius:0;-webkit- border-bottom-right-border:0;否则在android 2.0以下的平台中将全部显示直角，还有记住！-webkit这个前缀一定要加上！

19、如何解决android平台中页面无法自适应

虽然你的html和css都是完全自适应的，但有一天如果你发现你的页面在android中显示的并不是自适应的时候，首先请你确认你的head标签中是否包含以下meta标签：

<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;"/>

如果有的话，那请你再仔细的看清楚有没有这个属性的值width=device-width，如果没有请立即加上吧！

20、如何解决iOS 4.3版本中safari对页面中5位数字的自动识别和自动添加样式

新的iOS系统也就是4.3版本，升级后对safari造成了一个bug：即使你添加了如下的meta标签，safari仍然会对页面中的5位连续的数字进行自动识别，并且将其重新渲染样式，也就是说你的css对该标签是无效的。

<meta name="format-detection" content="telphone=no"/>

我们可以用一个比较龌龊的办法来解决。比如说支付宝wap站点中显示金额的标签，我们都做了如下改写：

<button class="t-balance"style="background:none;padding:0;border:0;">95009.00</button>元

HTML5,CSS3,JAVASCRIPT,JQUERY前端开发进阶教程前端开发推送欢迎关注互访！