首 页
网站建设
微信商城
功能定制
资讯中心
常见问题
行业知识
新闻动态
联系我们
关于我们
服务热线：
13215994088
服务热线
13215994088
您当前的位置：
网站首页
> 资讯中心
资讯中心
新闻动态
行业知识
常见问题
常见问题
更多 >
08
2019-11
做微信商城需要什么准备？
微信商城就是在微信公众号基础上开发出商城功能，方便客户支付、管理、影响。做微信商城需要准备、营业执照、法人身份证、手机号、微信、邮箱、对公账户（经营人银行账户）。以上资料齐全后首先申请公众号、认证公众号、申请微信支付账户。再由技术人员根据需求开发商城。
23
2017-06
当下对HTML5的产品思考
HTML5从质疑到重视 对当下H5的产品思考 2014年10月底，HTML5标准规范终于制定完成，并已公开发布。八年来，HTML5从饱受质疑到逐渐受到重视，经历了诸多起起落落，到现在这最后一只靴子也终于落地了。(相关技术介绍可阅读我的另一篇分享HTML5游戏发展和引擎介绍)。 “Adobe这家公司太懒，而Flash迟早被HTML5取代”，四年前，乔帮主炮轰Flash，给HTML5社区打了一针强心剂。但各家浏览器都有各自的小算盘，为了开发兼容性和响应性良好的网页，开发者和设计师仍然要为不同的浏览器适配版本。 标准分化的问题，在HTML5游戏被提出来的那天起就一直存在着，显然如果没有一个统一的Web平台，HTML5游戏也必将是空中楼阁。那如今，HTML5游戏的发展又如何呢? 一句话，其实过得并不好!或许当初吸引了太高的期望，而移动端HTML5技术的发展滞后于游戏的表现需求，各个浏览器的标准不统一导致碎片化也加剧了这个问题。 先看看市场份额：2014年占移动游戏用户比例达到23%(这个数据明显乐观，可能把一些支持运营的互动小游戏也计算在内)。付费率约1.3%，ARPU值较低，约1.1元，跟Banner广告收入近似。(数据来自Talking Data) 再看看HTML5的游戏类型：绝大部分是休闲益智类游戏，靠用户量来提升营收，缺少中重度游戏。游戏品质受制于硬件和HTML5标准的发展，表现力较差，画面效果粗糙，在移动网络会有非常多的加载延迟。产品周期大多呈爆发式、话题式，生命周期极短，现象级产品居多，主要是社交分享所转化的点击，呈指数级增长。 但同时我们也能看到一些变化：首先是渠道，HTML5游戏的导量方式不同于传统的手游分发渠道，由于缺少有影响力的Game Portal入口，所以更加依赖在社交网络上的传播，或者附着在APP中发布。 其次是产品形式： (1)常规游戏：桌面和手机游戏，也就是我们常见的HTML5轻游戏; (2)企业品牌展示：与企业形象展示结合，将品牌元素灵活的植入到游戏中; (3)客户积分消耗：玩家需扣除在企业运营活动中积攒的积分来为游戏“付费”，或购买道具(单向消耗)。 可见现阶段国内大部分HTML5游戏还是**进行辅助运营的补充工具，远未成为主流，这可能跟HTML5本身的技术平台有关，与**的运营需求比较契合。 毋庸置疑，HTML5是种新技术，相比于其它成熟的端游、页游、手游等平台，HTML5能带给玩家什么呢?HTML5又会给游戏领域带来什么新的革新呢? 如果套用SAMR模型(替代、增强、改造、重塑)，HTML5目前只能算是已有游戏技术的替代方案，而它产生的一种增强，或者说优势就是：“即点即玩”，只要打开一个链接就可以愉快的玩耍，无论你是在电脑前，还是在手机上，甚至在未来的电视旁，都无需任何插件。 在桌面市场，Flash Player和Unity Player几乎是浏览器的标配，且已耕耘多年，HTML5很难有所作为，所以HTML5的广大战场仍然在移动端。 有些HTML5游戏为了在标准碎片化中突出重围，改用了Hybrid模式(混合HTML5和Native)，采用APK或IPA安装包的方式发布，但由于游戏本身表现力欠佳，如果内容也没啥亮点的话那也是凶多吉少，很难与其它原生技术制作的游戏竞争，而呼声很高的《巴哈姆特之怒》后劲不足渐渐被人淡忘也是一个佐证，玩家最终关注的还是体验和游戏品质。 不过，随着HTML5标准的发布，WebGL、WebAudio、Web RTC等各种完善的组件加入，大量游戏引擎和开发工具的发布，许多酷炫的中重度游戏开始在酝酿，有开发商甚至喊出“Your browser will be a gaming consoles!”的口号。未来HTML5有望成为各个智能电视的标准前端框架，从而低成本的实现统一，云游戏的时代才真正到来，而这虽然是美好的展望但也是极有可能发生的。 HTML5仍是很有潜力的一种技术，“点开即玩的无缝游戏体验”仍然有很强的市场需求。整个市场对HTML5的期望值仍然很高。随着微信小游戏的风靡，《围住神经猫》、《试试你有多色》也狠让用户尝了一回鲜，但是仍然缺少能吸引玩家长久留存的中重度游戏，或许这也正是HTML5游戏需要证明自己的契机。 对微信而言，由于目前HTML5游戏还缺少一个完善的发布平台，神经猫的“小打大闹”让我们看到了微信作为一个HTML5游戏门户的潜力。由于微信浏览器本身对HTML5的支持已非常完善，如果附加更多游戏相关的特性，比如支付、登录、分享，甚至专为游戏做的优化等，将会成为下一代HTML5游戏引擎的强势标准，同时也可以与海量用户结合，进一步提升用户粘性。 目前比较缺乏低成本、便捷的HTML5游戏分发渠道，Game Portal或许在未来也有很大的市场，这也是许多创业者关注的焦点。
23
2017-06
HTML5改变我们未来生活
HTML 5：足以改变我们未来生活的十个方面 HTML5代表着Web发展的未来方向。无论大家身为开发人员还是高级用户，关于这一Web编程新基础的种种态势都值得各位高度关注。 如果大家还没有意识到，那我们先要强调一句——Web世界已经彻底改变了。时至今日，网络银行、实时视频聊天以及短视频共享已经成为Web领域的立足根基，而接下来还将有更多极具突破性的趋势及成果不断涌现。正因为如此，这一根基才需要迎接进一步升级。 超文本标记语言（简称HTML）正是浏览器所使用的语言。作为原本立足于面向文档的标准通用标记语言（简称SGML）的衍生产物，HTML在其早期的四个版本中只需要满足最初学术性用户对于Web功能的需求。但随着用户对于各类功能的进一步渴望——从安全加密传输到视频媒体——API、SDK、插件库以及外部应用程序全部被融入到了HTML当中，从而在最大程度上迎合个人及企业用户对Web提出的要求。因此2004年，Web超文本应用技术工作组（简称WHATWG）开始着手构建一套新的HTML版本，这就是HTML 5。 2014年10月28日，万维网联盟（简称W3C）——此前曾联手WHATWG共同开发出相关标准——发布了作为稳定推荐版本的HTML 5方案，换言之这套方案已经“彻底完成”。现在我们已经能够立足于自身系统，充分享受由HTML 5所带来的种种便利。 但这些便利具体包括什么呢？实际效果可能取决于大家到底身为开发人员抑或是普通用户。对于开发人员而言，HTML 5能够显著简化大家的日常工作——相较于HTML 4.1及以下版本而言，这是因为后者包含大量我们早已弃之不用的插件及额外内容。这绝对是件好事，不过从短期角度出发，我们仍然需要考量其它一些后续问题。 对用户来说，日常生活则会得到简化，这是因为由上述插件所带来的安全漏洞及兼容性问题将不复存在，因此我们再也用不着为了正常浏览网络内容而积累丰富的安全经验。此外，浏览器的使用体验也将被拓展到更多设备平台之上，这将使得桌面设备与移动设备拥有更为统一的观看感受。谁不喜欢这样呢，对吧？ 值得着重强调的是，HTML 5是一套尚处于早期发展阶段的标准。这意味着其前进道路上还将迎来多次飞跃，并将沿途带来诸多惊喜。正是考虑到这一点，我们认为它能够切实帮助整个业界以新的方式完成Web页面的构建工作。 如果大家本身正是HTML 5编程人员，那么前面提到的内容对您来说肯定属于陈词滥调了——而且大家当然也会希望能从我们这得到点更加新鲜有料的消息。希望各位能在评论栏中阐述您的体会与规划，相信这一切都将成为HTML 5向HTML 5.1进化的重要信息依托（这一升级将从明年正式开始）。好了，闲言少叙，咱们马上进入正题。 HTML5是一种新型语言 从HTML到HTML 4.2，HTML的每一次迭代都以SGML为基础——也就是由IBM公司在上世纪六十年**发出的这款文档描述语言。尽管HTML一直在不断发展演进，但其最为根本的出发点始终保持不变。然而如今这一情况得到了扭转。HTML 5是一种全新语言，不再立足于SGML。对于Web用户来说，这不会对他们的正常使用产生任何影响——大部分普通用户可能根本没听说过SGML，也不知道以此为基础会对HTML产生怎样的影响。不过对于开发人员而言，这意味着多年来在常用标签以及功能领域建立起的“肌肉记忆”需要再次更新甚至从头学习。这倒并不一定是件坏事，不过请各位记住，我们必须要在最后期限之前完成适应与学习，否则就会被历史的洪流所吞没。 好消息是，HTML 5仍然能够向下兼容其它早期HTML版本，因此去年才刚刚开始的代码编写工作仍然能够在今年提供正常的页面显示效果。这种延续性确实值得称道，不过根据经验，我们可以想见会有不少企业由于懒得升级而继续停滞不前。千万别这么做：不要再依赖于剪切加粘贴了，请从头开始重新开发新的HTML 5代码。事实最终会证明，这才是最明智的应对之道。 我们需要一款新的浏览器 还记得我们刚刚提到过的HTML 5向下兼容能力吧？这种兼容能力的确存在，但需要注意的是，面向HTML 4以及更早版本打造的浏览器方案将无法与HTML 5顺利对接。如果大家所在的企业一直将某套早期特定浏览器版本作为标准（没错，那些仍然在坚持使用IE浏览器早期版本的朋友，批评的就是你），那么HTML 5已经发出了冲锋的号角——是时候马上动手推动升级工作了。 目前的各大主流浏览器版本都支持HTML 5。它们在安全水平与可靠性方面也要比早期版本好得多。所以马上作出规划，别再坐以待毙啦！ 新的浏览器折衷途径 好的，如果您（或者您所在企业的CIO）对于采用“全新浏览器”始终保持固执的态度，那么咱们也可以通过折衷的办法加以解决。大家可以在早期HTML代码当中将HTML 5代码定义为块元素，并将HTML 5元素插入其中。这确实能够奏效，甚至效果还相当不错。但我敢肯定，大家自己对此不会太满意。 只要有合理的原因作为依托，大家完全可以通过以上方式暂解燃眉之急——无需升级即可拥抱HTML 5，简直机智！除非…… 大家仍然坚持使用IE 8之前的陈旧浏览器版本。在这种情况下，各位一定会遇到麻烦，因为微软公司并不允许我们在样式当中定义未知代码。在这种情况下，JavaScript也能够起到折衷的作用（大家在搜索引擎中输入‘HTML 5’再加上‘the siv’即可），但这无疑会让问题更为复杂，而且我们都知道最终会带来怎样的结果——对吧？ 视频播放更加轻松 在HTML 4上实现视频播放实在令人有些抓狂。这并不是说大家不知道该如何解决，但最糟糕的是仅有的几种可能性解决办法没有一样能够依靠语言本身来完成。换言之，所有工作都得依托于插件。虽然在大多数情况下，我们最终也能得到预期的效果，但相信每位朋友——无论是开发人员还是普通用户——都曾在浏览器上看到由视频引发的沮丧小脸图标，这代表着某款插件出了问题、需要更新或者暂时不可用。 HTML 5能够避免上述所有问题，因为现在视频能够作为媒体类型在语言内部直接加以定义。打算在自己的页面当中引入一段视频？在HTML 5中完成这项工作，其难度跟在HTML 4中插入一幅静态图片差不多。如果大家曾经花过大量时间研究如何向可定制视频播放器里添加代码，那么如今轻松易行的HTML 5视频页面编写方式绝对能让您长出一口恶气。而对于普通用户来说，这些可爱的短视频内容也将拥有更为稳定的播放效果。 现在HTML 5面对的几个主要问题是：并不是所有浏览器都能够为任何视频媒体类型提供支持。不过总体而言，只要大家坚持使用新的WebM视频格式，那么整个开发流程应该不会遇到任何阻碍。 动画已被包含于其中 不知道还有多少朋友记得自己为了在Web页面当中加入酷炫的动画效果而被迫学习Flash？如果大家没有接触过Flash，那就必须得跟专门的设计人员进行配合——后者会在原本稳定的页面当中加入大段神秘代码，而这有可能引发各类潜在问题。不过痛苦的时光已经过去，如今几乎每个人（包括Adobe公司在内）都对HTML 5的新能力感到振奋。 HTML 5当中包含有我们在页面内创建动画效果时所需要的全部功能。大家甚至可以在无需引入任何外部代码的前提下实现复杂的3D动画，这一点非常值得称道。此外，与早先的实现方式相比，如今的内置功能也把安全性与可靠性水平推向了新的高度。很显然，对于每一位开发人员来说，安全性与可靠性都跟开发成果的自身品质紧密相关。 另一大进步：我们用不着再考虑自己的页面会显示在哪些设备之上了。任何一款支持HTML 5的浏览器都能在全部设备上正常显示各位精心设计出的动画效果。 视频通话全面来临 动画效果当然很酷，不过基于浏览器的视频通话与协作模式如今亦可通过名为WebRTC（即Web实时通信）的协议得到实现——这几乎从根本上改变了游戏规则。尽管并不严格隶属于HTML 5协议范畴，但HTML 5浏览器确实能够发挥WebRTC所带来的功能优势。 想象一下，只需要三行代码即可为自己的网站带来视频会议功能——这是多么令人振奋的目标。不是做梦，现在我们已经可以通过WebRTC实现这一点。不过由于尚处于早期发展阶段，WebRTC仍然存在几个尚未解决的问题。首先就是其中的一项安全漏洞有可能影响到某些VPN。另外就是，WebRTC实际上是一套点到点系统——其调用不一定需要经由中央服务器。虽然这样的设计能够有效降低数据中心的实际负荷，但却有可能给全局网络流量带来难以控制的影响。这要么会带来大量小型数据流，要么会让未考虑到此类状况的网络规划模型面临沉重的传输负担。 但这个问题几乎肯定能够得到解决，因为WebRTC极具现实意义，业界根本不可能忽略其核心价值之上的这一点点瑕疵。将其引入HTML 5代码库，协作与客户支持工作将成为Web开发当中毫不费力即可完成的任务。 古董级语言仍能正常起效 .……而且我们也需要这样的结果。从JavaScript到Python，我们仍然需要使用这些工具来接入数据库、完成复杂的操作与处理流程、并对现实世界中的设备进行操控。它们也依旧能与HTML 5顺畅协作，从而继续为广大开发人员及普通用户效力。现在，我们需要对与这些语言相关的标签进行认真核对——因为大部分标签都在HTML 5当中经过了修改。但归根结底，它们仍然有效。 不过大部分浏览器插件以及我们过去已经习惯的外部工具就没那么好运了，特别是那些负责处理富媒体对象的方案。好消息是，HTML 5如今单靠自身就能实现全部媒体类型的原生处理，因此大家也将因此节约下可观的时间与精力。 设备平台差异仍然不容忽视 如果能够宣布HTML 5已然解决了由不同屏幕尺寸以及功能差异所带来的各类问题，我们当然会为之振奋——但遗憾的是，实际情况并非如此。虽然我们已经能够以前所未有的方式在不同设备之间顺畅往来，但开发人员仍然无法保证自己在台式机屏幕上设计出的页面成果同样能在智能手机上拥有良好表现。不同浏览器与设备平台之间存在着巨大差异，特别是在HTML 5兼容水平方面。页面将依旧需要查询浏览器及设备类型，而后再载入对应的方案及版本。对不起，现实就是这么残酷…… HTML5全面针对移动设备 前面刚刚提到，我们仍然需要认真思考用户在查看页面时实际使用的设备类型。而作为老牌语言家族的新成员，HTML 5当然也很清楚如今世界正逐步向移动平台倾斜。有了HTML 5，大家用不着再将移动设备当成是被全面阉割过的二等公民——我们完全可以编写动态代码，并使其在相当一部分移动设备的屏幕之上得到正常显示。 好消息是，我们向页面当中添加的全部要素，从视频到动画再到动态尺寸元素，在理论上都能够得到良好显示——即使某些设备上的显示尺寸偶尔有些奇怪。 那么最终结论是什么？别忙着抛弃自己的设备测试流程，也别想当然地认为每个人都会像咱们自己一样，在27寸显示器上查看Web页面。正如Steve Martin的经典语录，“让我们从小处着手。” HTML5相当复杂，但这是件好事 相较于HTML 4甚至是Flash，HTML 5都显得有些复杂甚至不易亲近。但这是件好事，因为这意味着HTML 5拥有充足的力量与功能，足以成为企业客户在构建基于浏览器的复杂而强大的应用程序时所需依靠的页面描述语言。这才是看待HTML 5的正确方式——它更像是一种应用程序语言，而非单纯的页面描述语言。 目前网络上有成百上千个相关站点，能够帮助大家学习HTML 5的对应知识，另有大量专业培训机构也为我们准备了理想的教程方案。从现在开始，HTML 5开始定义Web的未来发展方向，正如HTML当初定义网站页面之时一样。 大家是否已经准备好迎接HTML 5的降临了？您是否已经开始学习这一新型语言？希望各位能在评论栏中谈谈自己的情况。您的所见所想，包括您对于HTML 5的评价——无论好坏——都将极具参考价值。
23
2017-06
HTML5语义化总结
Html语义化理解 1、什么是HTML语义化? 基本上都是围绕着几个主要的标签，像标题(H1~H6)、列表(li)、强调(strong em)等等> 根据内容的结构化(内容语义化)，选择合适的标签(代码语义化)便于开发者阅读和写出更优雅的代码的同时让浏览器的爬虫和机器很好地解析。 2、为什么要语义化? 为了在没有CSS的情况下，页面也能呈现出很好地内容结构、代码结构:为了裸奔时好看; 用户体验：例如title、alt用于解释名词或解释图片信息、label标签的活用; 有利于SEO：和搜索引擎建立良好沟通，有助于爬虫抓取更多的有效信息：爬虫依赖于标签来确定上下文和各个关键字的权重; 方便其他设备解析(如屏幕阅读器、盲人阅读器、移动设备)以意义的方式来渲染网页; 便于团队开发和维护，语义化更具可读性，是下一步吧网页的重要动向，遵循W3C标准的团队都遵循这个标准，可以减少差异化。 3、写HTML代码时应注意什么? 尽可能少的使用无语义的标签div和span; 在语义不明显时，既可以使用div或者p时，尽量用p, 因为p在默认情况下有上下间距，对兼容特殊终端有利; 不要使用纯样式标签，如：b、font、u等，改用css设置。 需要强调的文本，可以包含在strong或者em标签中(浏览器预设样式，能用CSS指定就不用他们)，strong默认样式是加粗(不要用b)，em是斜体(不用i); 使用表格时，标题要用caption，表头用thead，主体部分用tbody包围，尾部用tfoot包围。 表头和一般单元格要区分开，表头用th，单元格用td; 表单域要用fieldset标签包起来，并用legend标签说明表单的用途; 每个input标签对应的说明文本都需要使用label标签，并且通过为input设置id属性，在lable标签中设置for=someld来让说明文本和相对应的input关联起来。 4、HTML5新增了哪些语义标签 HTML5的目标：书写更简洁的HTML代码，创建更简单的Web程序。 另人激动的新特性如下：新的html标签和属性，完全支持CSS3，视频和音频标签，2D/3D绘图，本地存储，本地SQL数据库。 为什么要引入语义元素：让开发人员更直观地了解页面每部分的功能表，同时搜索引擎以及视觉障碍人士使用的屏幕阅读器也能更方便地识别页面的每一部分。 区块标签： 标签article:表示包含于一个文档、页面、应用程序或网站中的一段独立的内容，也就是说，它能够独立地被发布或重新使用。 运用 一些使用article的例子：一片博客、一个论坛帖子、一篇新闻报道、一个用户评论。 标签header 一般被放置在页面的顶部，或者页面中某个区块元素的顶部，包含整个页面或某个区块的标题、简介等信息。 一个文档中可以包含多于一个的header标签;header标签不一定非要显示在页面的上方，它的内容决定这里需要使用header标签，位置并不重要;可以为body,article,section和aside增加header元素。 标签footer 一般被放置在页面的底部，或者页面中某个区块元素的底部。 标签nav 表示页面的导航,可以通过导航连接到网站的其他页面，或当前页面的其他部分。 搜索引擎或屏幕阅读器会根据nav标签确定网站内容，不是任何一组超链接都适合放在nav标签中。 标签aside 包含的内容不是页面的主要内容，具有独立性，是对页面内容的补充。 一些使用aside的例子：页面侧边栏;广告;友情链接;文章引语(内容摘要)。 标签section 一个主题性的内容分组，通常包含一个头部(header)，可能还会有一个尾部(footer)。 标签div和section的比较：标签div应用更广泛，只要你想为一个区域定义一个样式，就可以使用div标签;标签section包含的内容是一个明确的主题，通常有标题区域。 内容分组标签： 标签main 显示页面的主体内容;每个页面只能包含一个main标签;main标签中不包含网站标题、logo、主导航、版权声明等信息。 标签figure 定义媒介内容的分组，以及它们的标题。 标签figcaption 定义figure元素的标题。 文本级别的语义标签： 标签time HTML5的新标签。表示一个日期，或者一个时间，或者同时表示一个日期和时间值。 标签i和b HTML4中已经存在，在HTML5中被赋予了新的语义化功能的标签。 标签i 在HTML4中，是修饰文字样式的，将文字显示为斜体文本;在HTML5中，表示强调不同的情绪或声音，也可以表示技术术语、生物分类、来自另一种语言的成语或习语、一个想法等等。 标签b 在HTML4中，是修饰文字样式的，将文字显示为粗体文本;在HTML5中，表示文档中的关键字、商品名称等。 标签em和strong 在HTML4中就已经有了语义化的功能。 标签em：emphasis 强调，标签中的内容是用来强调的重点内容，会被浏览器显示成斜体文本。 标签strong：表示非常重要、严重性或内容的紧迫性;会被浏览器显示成粗体文本。 使用建议：如果你只是单纯的想把文字的样式显示为斜体或粗体，请不要使用这几个语义标签，W3C建议我们要在CSS样式表中定义文字样式。
21
2017-06
职场新人晋升全栈工程师的通关秘籍
什么是全栈工程师 全栈工程师一词，最早出现于Facebook工程师Calos Bueno的一篇文章 - Full Stack (需翻墙)。他把全栈工程师定义为对性能影响有着深入理解的技术通才。自那以后全栈这个词便流行起来，我看到过的就有全栈工程师，全栈设计师，全栈运维，全栈市场营销人员等等。而在很多针对互联网人才的招聘网站上，全栈工程师更是一跃成为热门招聘职位，其薪资水平也比一般的开发工程师职位要高出一截。那么，什么是全栈工程师，我们又应该如何定义一名全栈工程师呢? 百度百科对全栈工程师的定义是这样的：“掌握多种技能，并能利用多种技能独立完成产品的人”。我觉得这个定义还不够全面，我认为全栈工程师应该同时是一位资深开发工程师、架构师以及具有敏捷开发技能的程序员。全栈工程师对于软件开发的认识往往已经进化了，他们把特定的技术抛到了身后，明白技术的更新始终比计算机理论要快的道理，因此，他们注重强化自身的核心技能，关注并乐于实践其他技术。全栈工程师往往是某一方面的专家，同时通晓并善于在正确的场合运用其他语言、工具和技术。 全栈工程师的价值 随着时间的推移，全栈工程师的作用和价值在越来越多的产品或项目中得到了印证。那么，我们来看看全栈工程师对于个人或公司意味着什么。 - 个人价值及自由度的极大提升 —— 我曾看过一些介绍全栈工程师的文章，文中大多强调了全栈工程师对于公司与团队的价值。而我想说的是，没有一个优秀的全栈工程师是因为会对公司产生多大的利益，而努力学习各种技术的。我所认识的他们，都是那些有着一颗匠心，不断追求更高技能，并执着于做出更优秀产品的人。而当你成为一名真正的全栈工程师后，会感受到前所未有的个人价值与技术自由度的提升。试想当一个很好的创意出现时，你可以一个人或主导一个团队去实现并不断完善它，这是一件多么让人兴奋的事啊! - 全局思维与技术前瞻性 —— 由于具备了各个开发环节与技术领域的知识，全栈工程师往往具有更好的大局观和技术前瞻性，能够在项目初期就选择正确的技术，并很好地把控一个项目的整体方向。现代项目往往非常复杂，而全栈工程师往往能带来技术和质量上的保障，从而成为一个项目成功的关键人物。 - 降低沟通成本 —— 我经常听到有设计师抱怨前端工程师无法百分之百地还原他们的设计，而前端工程师又在抱怨后端工程师从接口返回的数据更本无法直接使用，后端工程师也在抱怨产品经理所提的需求根本无法完成。随着团队人数的上升，由于各自技能栈的不同，沟通成本一定会随之上升。全栈工程师除了能够独立完成前后端的开发(甚至包括设计)外，如果能够在项目初期提前介入，便能很好地规避技术风险，过滤不合理的需求，从而显著降低因不同技术差异导致的沟通问题，显著降低项目风险。 - 初创公司 —— 我们已经来到了一个万众创业，全民创新的时代。那些初创公司也如雨后春笋般不断涌现。初创公司往往都有了一个不错的创意，但经常会遇到“就缺一个程序员”的尴尬。我想说的是，他们其实并不是缺程序员，而是缺一位全栈工程师。初创公司往往资金有限，而一名优秀的全栈工程师能够帮助初创公司用最低的代价与最短的时间推出自己的产品。这是初创公司能够存活下来，拿到更多投资，甚至成为“独角兽”一员的最关键一步。 全栈工程师的技能栈 看到这里你一定会问，到底需要具备怎样的技能才能成为一名全栈工程呢?下面这张图来自Medium，作者将软件开发所涉及的各个方面分为层，又将每个层所包含的主要技术作为组件，制作了这张全栈技术图。 从上面这张图，我们不难发现，现在的技术体系是多么庞大，每一年又会有新的技术加入到这些层中，而已有的技术又在不断地更新。因此要掌握所有技术是根本不可能的，而成为全栈工程师也并不需要你真的掌握所有的技术，你应该将自己的精力聚焦于关键开发技能以及一些必须掌握的附加技能上。 关键开发技能(硬实力)： - Git / GitHub —— 你必须掌握如何使用Git来管理和分享你的代码。把Git作为关键技能的第一条，是因为它不仅仅是一个代码管理工具，更是一种推荐的工作方式。它使你能在任何地方进行开发，高效地管理任何大小的项目，通过Git你还能与其他团队成员进行分布式协作，大大提升工作效率。通过GitHub，还能将你与世界所有的开发者联系在一起。 - 至少一门编程语言 —— 你需要精通至少一门编程语言，JAVA 、PHP、C#、Python、Ruby、Perl 等，因为你的大多数核心业务处理都需要用这门语言来写。你既要掌握这门语言的语法，又需要非常熟悉如何基于这门语言进行项目的架构、设计、实现以及测试。如果你选择的是JAVA，那么你就需要掌握面向对象的设计和开发，设计模式的应用，基于J2EE各个组件的开发 等等。 - 运用开发框架和第三方库 —— 流行的开发语言，一般都伴有出色的开发框架，比如JAVA的Spring、MyBatis、Hibernate，Python的Django，PHP的 thinkphp、yin，nodeJs的 express 等等。这些开发框架往往都遵循软件开发领域的一些最佳实践，并由非常优秀的开发人员创建。熟练使用这些开发框架或第三方库能够避免重复发明轮子，使你的工作事半功倍。更重要的是这些优秀框架或第三方库的一般都得到持续的维护，是对你的产品或项目在质量与安全方便的最有效的保障。 - 前端技术 —— 之所以将前端技术独立出来，作为一项关键技术，是因为它在今天的项目和产品的研发过程中正变得越来越重要。一个产品除了实现所需的功能之外，是否好用(用户体验)也正在成为评判一个产品是否成功的重要标准。而这都依赖于前端技术的实现，你至少需要掌握 HTML5、CSS3、JavaScript 等基本前端技术，同时进一步学习 JQuery、LESS、SASS、AngularJS或REACT等前端框架或第三方库。 - 数据库与缓存 —— 任何产品或项目都需要一个数据库来存储数据。作为全栈工程师，你也需要至少掌握一到两个数据库，并知道怎样与数据库进行交互。目前流行的数据库主要有MySQL、MongoDB、Redis、Oracle、SQLServer等。MongoDB作为文档型数据库，在互联网产品中正被越来越多地使用，对于规模稍大一些的项目，我仍推荐使用MySQL或商用的Oracle作为后端数据库。而Redis这样的内存数据库则可以用于缓存，以提升系统的性能。 - 基本设计能力 —— 大部分关于全栈工程师的文章或讨论中，都不会将设计能力做为全栈工程师的关键技能，但我却认为这项技能非常重要。我曾被邀请评估一些软件工程师自己开发的产品，这些产品都有不错的创意，功能实现也很到位，但一看就不是一个好的产品，用户根本没有使用欲望，原因是这些产品的设计太差了，而往往那些开发者完全没有意识到问题的存在，比如色彩的不一致，排版的凌乱，不恰当的图标 等等。我所建议的基本设计能力，并不要求你像专业设计师那样能够P出神图、制作奇妙的视觉效果等，但你需要掌握最基本的UI设计原则，如 色彩的搭配，基本的排版，并具备良好的审美能力，和一些基本UI设计能力，这样你做的产品就不会太差了。 在掌握了这些核心技能之后，你可以根据自己的兴趣与发展方向，学习其他方面的技术。比如，如果你对数据处理感兴趣，那么你可以学习大数据方面的技术。如果你对移动互联网更感兴趣，那么你可以学习Swift，开发ios应用。知识总是相通的，在有了良好的技术基础后，学习其他知识将会变得非常容易。 附加技能(软实力)： - 沟通 —— 除非你是在做个人项目，对于稍大一些的项目，你总是需要与同事、干系人或是客户进行沟通的。而成功的沟通往往是获得有效需求，与建立团队信心的第一步。在项目的进行过程中，你更需要通过有效的沟通去确定方案，消除误解，与项目成员协同前进。良好的沟通能力将使你在团队中更具影响力，收到更多尊重和关注。 - 问题解决能力 —— 全栈工程师首先是一名工程师，他必须掌握工程化的方法来解决遇到的各种问题。我在职业生涯中的几乎所有亮点，都与解决问题相关，大到提供整个项目的架构方案，小到以最快的速度解决生产问题 等。其实有很多提高问题解决能力的方法，但没有一种比实践更有效。我所见到的优秀工程师，往往能够凭借直觉以最短的时间给出正确的解决方案，但你可能没有看到的是，在这背后其实是经过大量实践累积而来的经验。 - 时间管理 —— 作为全栈工程师，你可能会被安排同时在不同的项目中承担不同的角色。你需要合理地分配时间，保证所有的工作能够按时交付。同样在你的业余时间，你还需要花时间阅读和学习，同时你还可能会有自己的Side Project。因此，合理地进行时间分配，并对一些关键任务，进行计划是很重要的。你或许会感到一些压力，但这反而会激发你的创造力，并能让一切都有条不紊地进行。 - 好奇心 —— 对任何工作都抱有好奇心，并愿意不断学习和改善是那些优秀工程师的共同特性。软件开发领域汇集了世界上最聪明的人，各种类型的技术、产品、框架更是日新月异，层出不穷。优秀的全栈工程师需要不断地学习来抓住这些变化，跟上计算机领域发展的脚步。时常有人会问我，做计算机这一行一直会有新的东西产生，要去不断地学习，是不是会很累。我要说的是，对于将持续学习作为一种生活习惯的人来说，学习新东西并不会成为一种负担，反而是一种乐趣。 - 领导力 —— 优秀的全栈工程师往往会被赋予技术Leader甚至项目管理者的角色。成为管理者并不是让你去支配其他人，或让其他人替你做事。管理者需要理解你的团队成员的长处与不足，并知道如何以服务的态度使团队获得最大化的产出。我见过一些非常优秀的工程师，当他们被安排去管理团队时，他们是排斥的，他们往往更愿意独自工作。但我想说，成为管理者，将会使你更加睿智、可靠和值得他人信赖，也会对你未来的职业生涯带来极大的益处。因此，当机会到来时，请将它视为挑战，不要排斥它。 - 有经验的技术领导者在招聘时，往往会同时考察应聘者技术能力与上述附加技能，而对于初级程序员的招聘来说，那些附加技能往往更被优秀的技术公司所看重。开发技能是你的硬实力，而附加技能则可以看作是你的软实力，只有同时具备这两方面技能，才能成为一名优秀的全栈工程师。 优秀的全栈工程师需要走出去 优秀的全栈工程师不应局限于自己的工作，他更应该走出去，接触不同的技术，分享自己的经验和心得，认识更多的朋友。下面便是我的一些做法。 - 参加技术大会 —— InfoQ、CSDN、GITC、优设、TED 等网站都会定期举办各类技术大会。在这些大会上，你不仅能够听到技术大咖们带来的各自领域最佳技术实践，而且能认识很多行业内的朋友。这对你开拓思路，扩大技术社交圈都很有帮助。因此，如果公司没有安排你去参加这些技术大会的话，那就自己买票参加，作为对自己的一种投资吧。 - 作公开演讲 —— 全栈工程师并不需要是一个公开演讲者，但作为团队的核心成员，他一定需要在团队内部做技术、管理等方面的进行演讲。如果你是一个乐于分享的技术达人，那么也可以尝试录制个人课程(视频或音频)，并在慕课、网易课堂、优酷 或 像 荔枝、喜马拉雅 等各种媒体分享自己的技能和知识，不要因为自己并不是专家就不愿尝试，相信我，你用心制作的内容，会获得大家的认可，并收获一大批粉丝的。 - 个人博客 —— 每天进步一点点，一年以后你便会获得质的飞跃。优秀的全栈工程师懂得如何进行知识的积累，而技术博客就是一个很好的方式，将自己平时的实践、思考记录下来，配以tag标签方便日后的回顾。最有意思的是，当你在不断记录和更新你的博客同时，世界各地的程序员也会通过你的博客认识你。 - 参加线下活动 —— 与以前程序员总是宅在家里不同，现在的年轻程序员们更愿意分享和交流。很多网站也会组织不同技术主题的线下活动，在这些活动中你可以听到一些技术牛人的分享，还可以找到很多和你一样对技术富有激情的人。而我现在所做的开源项目中的很多团队成员，正是我在这些线下活动中结识的。 - 全栈工程师决不是一夜练成的，你需要打好技术基础，强化核心技能，并持续学习。相信有一天你也能像我一样，感受到自由地运用技术，开发出优秀产品所带来的乐趣的。
21
2017-06
HTML5要如何达到原生性能
编者按：HTML5应用被视为让本地软件云端化的利器，HTML5游戏也被视为一片新的蓝海，然而，HTML5远逊于原生的性能让众多开发者望而却步。本次InfoQ中文站便就此问题采访了英特尔(中国)开源技术中心负责crosswalk runtime和H5优化、硬件加速的两位工程师。 InfoQ：请先做个简单的自我介绍 余枝强：我是英特尔中国开源技术中心的软件技术经理余枝强，主要负责HTML5引擎 -Crosswalk在安卓平台的开发, 以及一些新兴Web技术的研发 顾扬：我是英特尔中国开源技术中心web研发经理顾扬，负责web图形相关功能(CSS, Canvas2D和WebGL等)的实现和优化 InfoQ:大家都很期待H5达到原生性能，那么从硬件层面和浏览器层面来说，H5能否达到原生性能呢? 余枝强：其实现在轻度、中度游戏/应用如果能够通过一些全栈式的优化(包括应用层，软件库，Web引擎层)，某些场景下可能还需要一些Hybrid实现， 这样，HTML5应用接近或达到类似原生应用的性能应该问题不大。但重度、计算量大的应用(比如复杂的3D游戏，包括物理引擎等)目前确实还是有不少差距的。 我这里可以分享几个例子，它们都是一开始性能有较大的差距，但通过相应的优化性能达到了质的提升。 其中一个例子是和腾讯Alloy团队合作的，针对HTML5图像处理库的优化。原先这个图像处理库在移动端性能不理想，比如说对一副图像实现一个木雕效果需要十几秒甚至几十秒的时间(其中涉及到较为复杂的计算)，后来我们在应用里引入并行 (WebCL, 它可以利用CPU 以及GPU中的多核的能力)，通过对图像处理库相应的部分用WebCL重新实现，另外在Crosswalk引擎里加入WebCL的支持以及相应优化，最后这个图像处理时间在安卓平台上从几十秒降低到2秒以内。 另外一个例子是和触控科技合作了， 针对一个游戏-“进击的小怪物”的 HTML5版本做优化，其中涉及到比较酷炫的消除/爆炸效果，而这些效果在最新的Chrome里跑只有十几的fps 。通过引入Crosswalk 的游戏模式，把上层相对耗时的API通过原生的实现再桥接到HTML5引擎中，使得酷炫效果的性能比Chrome好5倍左右。 另外最近我们在调研一种典型的用户场景：大规模的图片的加载和滑动的性能问题， 以及和原生应用的性能区别。经过初步的调研，我们发现性能的差距有几个方面的原因：没有做更好的缓存，没有利用系统服务，不必要的事件处理，不必要数据转换，以及大量的数据缺少高效的数据传输机制，这中间有很多开销，会影响到用户体验。我们打算做一个参考实现来解决这种类型应用的性能问题。 总结来说， HTML5的性能问题，可能是多重原因组成，比如应用本身设计不合理，加了不必要的事件，没有用更好的缓存等等，另一方面引擎也可能有问题，比如数据传递，比如没有利用上更好的硬件特性。再加上Javascript语言的动态性，相对不容易写出优化的代码。这些问题，如果能够有全局的角度出发做相应优化，性能会有机会提升非常明显。另外对应用开发者来说，尽量用一些成熟的框架，最好也要对对底层引擎有一定的了解从而避开javacript 里的坑。成熟的框架相对来说已做了一些Javascript层面的优化，再通过引擎本身针对应用的场景做相应优化，同时让Web引擎更好的利用到底层的硬件能力，这些层面做好了，就容易有好的体验。 顾扬：从我的理解来说，native应用直接跟硬件打交道，web应用则是通过web引擎跟硬件打交道，多了web引擎这个中间层。正因为这个中间层，带来了一些性能差异： 1， web引擎相对native发展来说还很年轻，对CPU，GPU这样的计算资源还不能充分应用。 2，web引擎是一种通用平台，日益增强的能力也带来了日益复杂的架构和更多的overhead。当然除却web引擎带来的性能损失，JS语言本身也有一些局限性，比如数据类型不明确，不支持多进程等。我们的优化主要针对web引擎的上述两个短板： 1， 充分发挥硬件，主要是CPU和GPU的能力。比如充分利用Intel CPU的特殊指令集，GPU的特殊extension。 2， 因为我们熟悉web引擎的各个阶段，通过对典型应用场景的性能评估，了解瓶颈所在，从而优化引擎逻辑。 InfoQ:顾扬可否再详细地介绍下你们所做的优化? 顾扬：目前的很多web引擎都是基于Chromium项目。我们的优化工作基本都是直接提交到Chromium，而且跟图形相关。具体涉及的软件仓库，主要是Skia和Chromium(Blink已经跟它融合)。 Skia方面优化 : 1，很多操作还是通过CPU进行的，Intel CPU有特殊指令集，用好这些指令集会有很多性能提升。 2，我们会做图形也是因为web的趋势是越来越多地用GPU而不是CPU来渲染。移动平台的GPU能力，近年来增长非常快，很多以前只有CPU能完成的任务，现在都能用GPU完成，而且性能更好。Skia代码中有些GPU的逻辑，要么有bug，要么还不够优化，我们消除了很多这样的正确性和性能问题，从而可以顺利的从CPU切换到GPU。 3，对路径渲染的一些优化。 4， CSS的很多优化，比如transform，box-shadow。 Chromium方面优化: 1，针对特殊场景的优化。比如Canvas2D被用在轻量级应用时，一些overhead可以忽略。但当用于一些heavy的游戏，比如一帧要画成百上千的东西时，引擎的一些overhead就突然成了瓶颈。 2，针对WebGL的各种优化，比如上传canvas/video到WebGL，GPU到GPU的纹理拷贝等。 3，一些场景下DOM操作的优化。 4，针对反锯齿效果性能的优化。 InfoQ:很多游戏厂商不使用现有的引擎，可能会选择自己写一个。对于这些开发者，有没有什么可以分享给他们的性能优化方法呢? 余枝强：的确有这个现象，有很多HTML5游戏引擎厂商都是自定义的一套 API，实现上其实是完全绕过了HTML5引擎，直接调到了底层的库。开发者就围绕这些API来开发，这在某些情况下的确有更好的性能，但也丧失了HTML5的一些优势，包括通用性，以及与HTML5 API的交互能力 (比如DOM)。不过这也是一种做法，但我觉得另一种可能更好的路是把HTML5 和 原生实现更高效的融合起来， 在把HTML5 本身的优势发挥出来，把标准的API以及丰富的HTML5 库利用起来，同时也能有和原生实现类似的性能。 InfoQ:对于浏览器而言，有无什么可从Web 引擎借鉴过来的优化理念? 余枝强：这个是有的。但首先我们要理解一下浏览器和独立的Web 引擎之间的区别。比如对于浏览器，你不知会访问哪个页面，所以为了防止潜在的恶意代码，在安全方面需要做很多检查，增加额外的开销，不同的页面也需要做相应的隔离。同时，浏览器需要更通用一点，来满足不同应用的需求，而通用也就意味着不容易做一些特定的优化。而作为一个独立应用，代码是可控的，场景是特定的，相对容易做一些针对性的优化。另外，在交互方面，比如浏览器里网页前进后退、手势，这些对于独立应用是不需要甚至有冲突的，这方面也是不小的区别。 但对于基础渲染，GPU加速等，浏览器和web引擎的基本是一致的. 还有，比如说把指令级的并行如SIMD带入到Web平台，这个也是通用的。SIMD.JS最先是在Crosswalk中有完整的实现，然后变成一个web标准，目前主流的浏览器厂商比如Google/Microsoft等都在加入相应支持。 InfoQ：因为IOS上无法使用第三方runtime，所以有开发者觉得使用runtime会减少很多用户。对于IOS这个问题，有没有什么解决办法? 余枝强：对于runtime会提供打包工具，可以将H5应用可选地打包成Android或IOS应用，所以不会减少用户。 只是在IOS上实际使用的是它自身的WKview引擎，而不是我们的加速引擎。但是考虑到IOS硬件不错，自带引擎加速也还可以，所以其实IOS上的H5性能问题没那么严重。 InfoQ:CSS和DOM操作算H5一个瓶颈吧?这方面的性能优化可否再具体讲讲? 顾扬：我们在这两块做的优化不算多，主要针对一些特殊场景。比如上面提到CSS有个效果是box-shadow，计算非常耗资源。我们通过cache机制，把中间相对通用的计算结果保存下来，这样很多后续运算就不需要从头来过，很好的提升了性能。当然，做好这样的优化，需要做大量实验，对数据的典型性有很好的把握，也要对Skia的cache机制有很好的了解，并做很多增强。DOM的一些优化也是针对某些场景。比如在packaged app里，可以节省一些cache获得很大的性能提升。 InfoQ：关于H5的优化和硬件加速，还有什么需要补充的吗? 顾扬：优化是很难做的，我们从12年开始做优化，碰到的最大问题不是怎么修复瓶颈，而是压根不知道哪是瓶颈。你想，H5有很多关于功能的标准，但却没有关于性能的。H5涉及的面很广，包括JS，CSS，Canvas2D，WebGL，Web Audio， Web Video等。这些领域在不同的硬件配置，比如CPU，GPU，内存，屏幕尺寸和分辨率上，表现都会有很大不同。怎么设计benchmark，既cover典型的应用场景，又能充分测出每个领域的瓶颈所在，是最难的事。我们从一开始就做好了长期作战的准备，比较系统的为优化做准备。我们收集，开发和评估各种benchmark，不断积累测试方法，自主开发一系列工具帮助我们自动化测试和明确问题。在这些benchmark帮我们明确了问题之后，就需要依赖我们对web引擎的了解，分析问题所在。有些问题是比较好解决的，比如有些局部代码写的不好，或者说有些regression，也就是说以前是好的，现在不好。另一些问题是比较系统性的，解决它们需要大量的改动，甚至改动底层架构。我们通常会积极跟upstream讨论，寻求最佳的解决方案。 这是我们整体做优化的一个思路，一个过程。优化不是一蹴而就的，需要长期的积累和很多很琐碎的工作。 InfoQ：再问一下，对于耗电，该如何优化? 顾扬：耗电和性能，很多时候是一对矛盾，需要很好的权衡。 有的时候很少的性能损失或者不损失，就能省很多电。比如通常的web应用，每帧的显示通常要经过CPU处理，然后交由GPU渲染。如果GPU是瓶颈，那么CPU再快也没有用。这个时候可以通过一些聪明的调度算法，减少CPU端的操作。再比如有些video的解码工作，交给GPU处理不仅快，还能大大节省整体耗电。 但决定并不是每次都这么容易。当省电的代价是比较大的性能损失时，就需要很好衡量了。有时可以在web引擎里面设置一些启发式规则，根据系统当时的情况，作出合适的选择。 InfoQ：对未来的展望? 顾扬：web发展很快，越来越多的人贡献idea和code。这些贡献主要在两方面，能力和性能。 能力方面，很多native的能力正在很快的加到web中，像蓝牙，NFC，AR，VR等。我们想要打通native和web的界线，native能做的，web都要做到。之前web是在追赶native的能力，今后要慢慢lead这些能力。世界不断发展，不断有新技术出现，这些新技术以后先在web还是先在native落地，则看谁基础更好，实现更经济了。哪边发展快，哪边就能引领行业发展。 第二类是性能。上面已经谈的比较多，主要是JS语言本身的性能，以及web引擎本身的性能。至于能不能达到native性能，坦白说很难，但可能有了足够好的性能之后，这个问题就不那么重要了。比如说web有个常用的指标FPS(一秒几帧)，对人眼来说60FPS就已足够好，再高人也不易察觉了。所以如果web可以达到60帧一秒，native可以到80帧，虽然web还是不如native，但已经足够好。这个时候，web在其他方面的优势，比如统一的标准，高效的开发，方便的更新等，将秒杀这些很小的劣势。web就会变成一个很适宜开发的成熟平台。所以性能发展的目标，不一定是要达到native，而是足够好。 InfoQ：有言论说，随着从C/S到B/S的转变，未来我们只需要浏览器就足够了，客户端软件会被浏览器上的云端软件取代，你怎么看? 顾扬：我做web这么多年，非常热爱web，也对它很有信心。但是我认为世界上的统一是不可能的，也是不适合发展的。总有需要native存在的领域，比如有些对性能要求非常高的地方。做个类比，我们看一下计算机语言的发展历史，高级语言在慢慢侵蚀低级语言的地盘，从汇编到C/C++，Java，以及很多的脚本语言，但低级语言并没有消失。在很多底层库中，还用了大量的汇编，C/C++有更多的领域在使用，更不用说Java之类了。 web的使命，不是彻底取代native，而是补充了多样性，把应用这个蛋糕做大了。以前的人，哪有这么多应用可以用。可预测的是，在经历了高速发展期后，它跟native的在应用中的比例会趋于一个稳定的状态，native仍会有相当可观的比例。 被访者简介 余枝强，目前是英特尔开源技术中心的软件技术经理。 主要负责HTML5 引擎 – Crosswalk 在安卓平台的开发，以及一些其他和Web有关的新兴技术的研发工作(如HTML5 并行技术, HTML5 游戏优化，3D Camera等)。他坚信Web是未来， 也非常希望和大家一起努力，让这个未来能够更快更好的到来。 顾扬，英特尔中国开源技术中心web研发经理，负责web图形相关功能(CSS, Canvas2D和WebGL等)的实现和优化。2013年硕士毕业于浙江大学，后加入Intel从事编译器开发5年，转而主攻web。在web领域，带领团队完成Android Chrome 32位到64位的移植，负责英特尔移动平台web支持，更是贡献400多个patch到Chromium Upstream (包括Chromium, Blink, Skia等)和Khronos Github，实现和优化图形相关功能。业余爱好羽毛球，曾任上海英特尔羽毛球俱乐部主席7年，获奖颇丰。
21
2017-06
Java程序员最亲睐的Web框架
这是关于Java的第二个调查,第一个调查是关于Java程序员使用的20多个大数据工具。 这一次，我们要讨论的是 web 框架。 只有少数几种语言像 Java 一样提供了各种各样的 web 框架，上面的统计图就是一个证据。下面是其他开发者所使用 web 框架列表： - Spring MVC/Spring Boot ：Spring 可以帮助各地的开发团队构建简单轻便、快捷灵活基于JVM 的系统和应用程序 - Vert.x ：一个用于在 JVM 上构建反应式应用程序的工具包 - JSF ：官方的 Java EE web 框架 - Play Framework ：更容易地使用 Java & Scala 构建可拓展的、快速又实时的 web 应用程序 - Grails ：Java 版本的 Ruby on Rails，建立在 Spring 和 Hibernate 之上，用 Groovy 编写 - Spark ： 一个受 Sinatra 启发的小型框架，帮助使用最小的努力在 Java 8 中创建 web 应用程序 - Apache Struts ：一个 MVC 框架，用于创建优雅的、现代化的 Java web 应用程序 - Dropwizard ：一个用于开发操作友好、高性能、REST 风格 web 服务的框架 - Vaadin ：一个服务器端框架，用于构建单个页面的 web 应用程序 - JHipster ：一个生成 Spring Boot+ AngularJS 项目的应用程序生成器 - Wicket ：使得简洁、分离关注点和简单化开发到一个全新水平的 web 应用程序框架 - JAX-RS ：JDK 的内部框架，用于创建 REST 风格的 web 服务 - Stripes ：让使用 Servlet 和 JSP 工作时变得轻松 - Sling ：一个使用 Java Content Repository，并得到 OSGIt 支持的 web 框架 - GWT ：Google 开发的一个框架，可以编译 Java 代码为 JavaScript 运行在浏览器中 - XSLT ：用于转换 XML 文档为另一种 XML 文档的语言 - Ratpack ：用于构建现代化 HTTP 应用程序的 Java 库系列 - Express ：这不是 Java web 框架，而是建立在 Node.js 上的 Javascript 框架 - Ninja framework ：全栈 web 框架，协同 GAE 工作很好 - Compojure ：用于 Ring 和基于 Clojure 的 web 应用框架的小型路由库 - ZK ：一个开源的 Java 框架，用于构建企业级 web 和移动 app - Symphony2 ：用于 web 开发的高性能 PHP 框架 - Java 企业版 ：是社区驱动企业软件的标准
21
2017-06
CSS 各种定位（position）方式的区别
static：静态定位是position的默认值，元素框正常生成，也就是没有定位时的正常显示。 relative：相对定位 用法一：元素相对自身的原位置偏移某个距离，但是原本的空间依旧保留，表现为空白。 用法二：把一个元素设置为position: relative; 可以使该元素的子元素相对该元素绝对定位。 absolute：绝对定位 元素从文档流删除，并相对于包含块定位。元素在原本的空间关闭。元素定位后生成一个块级框，不论它原来是行内元素还是块级元素。 包含块：最近的position值不是static的祖先元素(块级或行内)，一般会指定一个元素作为绝对定位元素的包含块，将其position设置为relative而且没有偏移。 fixed：固定定位 元素从文档流删除，并相对于浏览器视窗定位，因此不随文档滚动而移动。元素在原本的空间关闭。元素定位后生成一个块级框，不论它原来是行内元素还是块级元素。与绝对定位的区别仅仅是包含块不同。 包含块：浏览器视窗。 absolute/fixed和float对比 类似：元素都会从文档流删除，但是依旧会影响布局;都会生成一个块级框，无论原来是不是块级元素。 区别：float的包含块是最近的块级祖先元素。 偏移属性：top/right/bottom/left，初始值是auto。 采用position定位之后必须采用偏移属性定义偏移量，也就是相对包含块的偏移。注意应用于position值不是static的元素。 有时也需要定义width和heigth，但是可能会和偏移属性的定义冲突，因为四个偏移属性实际上已经定义了元素的大小。此时，根据width和left属性定义左右，根据top和height属性定义上下。 内容溢出overflow: visible/ hidden/ scroll /auto/ inherit，初始值是visible。 一个元素的大小固定，但是其内容放不下，就会导致溢出。overflow控制溢出部分的可见(visible)、不可见(hidden)、滚动可见(scroll)。 元素可见性visibility: visible/ hidden/ collapse/ inherit，初始值是visible。 visibility:hidden和display:none的区别：visibility:hidden设置元素不可见，但是元素依旧会影响布局，只是元素部分呈现为空白;display:none元素不显示并且从文档流中删除，对文档布局没有任何影响。
共8条 共1页 第1页
首页
上一页
1
下一页
尾页
版权所有 © 2017 郑州方果电子科技有限公司
做网站:方果科技
营业执照展示
豫ICP备16029994号
