参加第十届D2前端技术论坛，你有什么收获？
日在杭州阿里巴巴举办
按投票排序
我没有像民工叔那样现场速记的能力，不过乘着记忆还热乎，写一下。本次D2共0x10场分享。其中移动hybrid/native解决方案相关的分享有4场，分别来自百度、淘宝、手淘团队的工程师和GeekZooStudio的老郭。组件和应用框架相关的分享（不包括react native）有3场，分别来自腾讯、蚂蚁金服、碉堡了（strikingly）的工程师。node.js架构相关分享有4场，分别来自天猫、360、阿里云、腾讯的工程师。特定平台主题分享有2场，分别来自阿里数娱、阿里智能云的工程师。其他API管理、可视化、国际化各1场。主题的分布还是很有代表性的。当然因为主题如此丰富，所以又是同时有三个会场，我想很多人都会有选择困难。后来跟圆心聊了下，主要是现在前端议题多，又不想分两天（增加参会者出行负担），又不想每年两次或者收费（主办方控制成本），所以还是选择了现在的方式。至于说为什么分会场不是按主题（比如node.js主题、hybrid/native主题等）分，圆心说是故意的，但没有细说原因。因为我本人的工作并不侧重hybrid/native方向，所以优先选择了其他主题，包括死马、朴灵的两场node.js的相关分享，杨文坚的组件化设计的分享，听鸿的TV平台的分享，黄高岚的react的分享。先说死马的。天猫从php切换到node的架构层面改造我以前就听过一些分享，这次只是增加了一些运维层面的细节。还有关键的一点，就是通过天猫的真实数据说明新架构相对于老的php架构的巨大优势。（死马虽然在QA环节说部分提升来自于重构而不是php=&nodejs，但我认为那只是说说而已，继续使用php却要抛弃php的传统模型是非常困难的。）不过我对于死马讲的koa的一些优点并不完全认同。我个人认为koa是比express在api设计和middleware开发上更方便一些，但大部分benifit是相对次要和只惠及框架developers而不是框架使用者的。因此其他框架比如thinkjs也还是有机会跟koa去竞争的，呵呵。BTW， 作为thinkjs的主要作者在D2上也有一场分享，其实主办方应该让成银跟死马pk一下。当然这个部分不是重点。重点是nodejs大法好。然后说一下朴灵的。简单说就是alinode的广告。然而我狠happy能看到这广告。因为虽然我从2010年开始就是node.js的坚定支持者，但在实际生产环境中一直只将node.js用于工具链，而很少将node.js用于主要的服务。最大的原因就是缺乏node.js运维的信心。而朴灵的广告可以说给我提升了狠大的信心。希望朴灵团队早日进入node.js的core contributor和node基金会！下面说下腾讯杨文坚的组件相关的分享。这是又一个借鉴WebComponents规范的尝试。作为一个对React体系持保留态度的人，我个人其实一直期待这个方向能看到更多的可能。不过遗憾的是文坚的尝试并没有能让我惊喜的部分，简单说，就是把容易做的事情都做了（做得可能还是不错的——特别是已经用于生产环境），但是困难的部分都没有做。当然这有一个难题。用于生产环境固然好，但也因此，特定工程上的需求就获得了更高的优先级。我不是说来自于实践的工程需求不重要，可是，组件化是非常复杂的架构问题，要优先考虑特定的工程需求，最简单的办法就是牺牲掉一些在特定工程中相对不重要的特性。然而要判断某种特性裁剪是临时性的措施还是永久性的架构约束，是非常困难的。延伸开来说，在这一点上，各种hybrid/native方案也是如此。虽然我没有听这次所有的hybrid/native解决方案的相关分享，但是总体上我对所有目前类RN的方案有一个判断。它们其实本质上是重造浏览器渲染引擎。js是不动的，html/dom被裁剪，css被裁剪。其中尤以CSS为改造重点。像表单交互、动画、无障碍性等也是被牺牲的，但是这些部分是临时性的，像react生态里，这些问题已经得到解决或缓解。唯有对CSS的改造是本质性的改变。CSS大体可分为三个方面：1. selector和cascade机制2. 布局模型3. 其他特性（比如css单位、transition/animation、透明通道、渐变、filter、svg等）如React官方的CSS in JS方案，是完全干掉了1。React Native进一步裁剪了2和3。说到底，现今浏览器的复杂性，80%来自于CSS。像html parser、dom接口、各种device api这类，麻烦管麻烦，但是都是可以模块化，可以做到解耦和正交，因而实现和维护并不算特别难。但CSS部分就不是。尽管CSS规范也是模块化的，互相之间是正交的，但是那是从使用者（web开发者）的角度正交，而不是从实现者的角度。对于实现者来说，CSS特性错综复杂，互相影响。渲染引擎的许多优化，实际上很多是很dirty的。这导致渲染引擎（相对于native来说）又慢bug又多。可是简化CSS就是solution吗？我对此其实一直有所保留。所有强调工程实践需求的，可以试想，回到CSS1的时代，我们也可以解决80%的页面样式需求的嘛，但是我们难道会满足于CSS1吗？所以问题是，各种类RN的方案如果一直停留在今天的样式相关特性集，我们是否真的能满足于此？如果它们也不断扩充特性集，我们怎么有信心说CSS发展中踩过的坑它们就会避免？我个人倾向于，样式相关的复杂度是所谓本质复杂度，也就是长远看无法完全避免的。这是为什么我对RN或类似方案给出的评价一律都是：（目前来看）工程上是可行的。但是长远来说，它们是不是答案，我存疑。回到文坚在组件化方面的尝试，虽然说借鉴了WebComponents规范，但实际上的实现却如React一样是牺牲了CSS的selector和cascade机制（当然如果在现有技术上很容易做到，那也不需要新标准了）。而保持原有DOM/CSS架构正是WebComponents相对于其他组件化方案的核心优势（至少对喜欢WebComponents的人来说是这样）。所以这大概也只能评价为一种尝试。另一方面，文坚可能花了不少精力在打包优化上面。从工程实践的角度来说，这一点是非常重要的。然而从未来组件方案的角度来说，现在条件下所做的优化都是不重要的。原因我在晚场的分享和交流里讲了，我认为整个前端构建/部署即将发生重大的变革。组件的构建、打包自然不会例外。整个下午我一直在白马山庄听分享，前面提过的朴灵的分享是第一场，第二场是阿里数娱的听鸿的「TV前端开发解决方案」。这一场听的人比较少，这也可以理解，这毕竟不是热点。不过对我个人来说，这场我是很有共鸣的。因为他讲的正是我2006年期间在盛大工作时参与盛大盒子项目时研究过的领域。作为一个TV Web框架的先驱（烈），我很高兴看到后继有人。当然也有一点伤心，因为当年盛大盒子推出的时候，Apple TV第一代还没有推出；今天Apple TV已经是行业标杆，而我以及当年近百人的工程师团队所有的努力却早已灰飞烟灭，没有留下一点痕迹……如果那时盛大更牛逼一点，并且没有广电总局这样恶心的机构，说不定今天听鸿参考的就不是Apple TV的文档而是我写的文档了，呜呜……最后补充一点，问答环节hehe123建议结合无障碍领域是非常到位的，当年我在写交互Guideline的时候其实也参考了许多W3C WAI的文档。白马山庄的最后一场是碉堡了的黄高岚的分享。整个presentation准备充分、条理清楚，代码演示很顺畅，还有彩蛋。在听了一整天之后，以这样一场轻松但又扎实的分享结尾，让人一点也不会有疲倦之感。其实之前碉堡了的CTO郭达峰就给我提起过他们有位员工技术出色，但因行动不便所以很少出来参加技术活动。没想到那么快就能看到本人。希望以后能看到黄老师的更多分享。流水帐报告完毕。至于晚场我在台上即兴讲的内容，以后再整理成文，这里就不赘述了。（更新：已经在另一个问题下写了：）
实时手机记录，随时更新：第一场听了百度的blend uicss3切换动画没有办法跟手，做手势相关操作多个webview切换，产生的问题是原先在一个页面作用域中的代码被分散到多个，业务代码麻烦很多，通讯是个问题，内存泄露等方面也有不少困扰。最终方案：webview上面盖native，比较固定或者高性能的部分用native，动态内容用web，一起拼装。问题是，比如滚动，native和webview不能同步，考虑限制native部分为fixed，对业务有较大限制。最后，用webview只做js执行引擎，然后结果扔给native渲染。。。为什么不用rn：国内很多用户安卓手机不支持，编译的js core通过jni调用，有些大。实现原理，用js封装web和native组件，外加bridge通信。创建一个ui，js到native，使用树形组件树，从顶层往下逐步创建。两边通过id建立组件映射，相关资源也是通过id做索引。除了view tree，还有css node，每个css node创建之后对应一个view，布局跟web相比是简化的，比如不需要float之类，主要支持flexbox之类。原理是，从视图组件树创建对应的css node树，渲染的时候，css node树计算出布局信息，然后设置回来到视图组件树。性能优化：创建组件不反射，而是固定，加switch case，java写组件的时候添加注解，从这个注解构建出这段创建代码。web和native的组件层级对应，但是web中会有辅助布局的容器，所以这里在native渲染时候做一些合并，减少组件层级。此外，还移植了一些dom api和css选择器之类的。第二场，腾讯的人讲组件化幻灯片字体不适合阅读。Ques为什么不用开源方案，当然理由也是中国现状啦，这次是跟网络有关，还有浏览器。MVVM，gzip之前10多k，兼容ie6到移动端各种浏览器。内部实现，组件使用特定class标记内部结构，应该是用来做类似transclude之类的功能。Ques的组件可以继承，为什么说可以继承就有aop的感觉？？？然后演示怎么组合各组件。。。好吧，没有继续听了。下午第一场，听承玉讲react组件方案最近一两年前端发展快，需要重构组件，并且兼顾非专业前端。对比了spm，npm的优缺点评价了browsify和webpack综合提出了一套整体方案。底层有基础模块的管理，未来模块的合并不一定是现在cdn combo这种方式，有更多考虑。组件库antd基于react，加上蚂蚁金服的设计语言ant design，使用es2015编写，发布时候构建成es5。还包含了名为g2的图形库。另外做了一套名为roof的组件通讯方案，对比了flux和redux的缺点和推广难度，提出了一些解决办法。这里讲太快，不太好记录了。在数据通信层，对比了relay和falcor，用一个oceanbase的监控界面举例，说明优化之后的性能提升，主要是通讯数据的合并。未来的探索，typescript，ant-mobile，relay。提问：会考虑vue吗？这个。。。只能说偏好了。另外个提问：为什么是基于react而不是基于web components？承玉觉得标准不一定好用。这个我赞同。下一个，手机qq空间的分享，主要讲的是一些离线策略，预更新策略之类，工程方面的事情讲得挺好的，配图典型腾讯风格。。。再下一场听的是国际化美杜莎平台，三年前我其实也在考虑这个事，大致思路是差不多的，除了考虑多语言集中管理，命名空间分隔，还有构建阶段的控制，另外还要做那些脱离研发过程的文案替换，让运营或者业务人员自行修改文案，嗯我就记录了这么多，剩下的场需要看其他朋友的记录了，或者看录像和相关资料补上。今年是第十届d2，主题是融合，确实，今年的主要话题有三块，一块仍然是新框架和前端方案的探索，一块是node相关的深入应用，一块是最贴近主题的融合，也就是多端合一的技术方案。下面是我的流水账，仅供娱乐，道德感极强的建议pass：去年鼓动公司的同事们来参加过D2，反响很好，处于封闭环境中的人应当走出来看看外面世界是怎样的，前端是需要交流，需要活力，需要跟随社区脚步的，因为发展很快。今年照例是鼓动大家报名，我团队的人基本都是今年新入职或者转岗，所以也都是第一次来。据说，今年报名的时候，大家填的理由都是：五花肉的前男友……感觉有几百个人填的这样的理由。因为周五还要来参加别的活动，所以就调休了，早上直接来杭州，本来订的8点44的高铁，人生中第一次错过了，然后就是改签，到了杭州东站之后直接打车到阿里，12点准时到的，一路畅通。中午跟着庄少和小雪在食堂感受了一下，分量太足，远超我的正常食量，口味也不错，有些咸，不纠结了，很少能碰到刚好适应我那种完全淡而无味口味的地方。下午去8号楼参加weex conf，勾股的心血，他跟一群人一起努力了好久的成果，能坚持下来真不容易，能被邀请作为嘉宾，压力好大，因为自己其实不太搞移动端开发，只能纯粹作为朋友角度来支持……晚上去印象城吃饭，winter请客，重口味，各种三文鱼，海胆之类东西，我吃了一些熟的东西，刚好也不饿。。。周六早上，跟百度的两个人一起打车去阿里，到得不算早，刚好9点，下车发现团队的小伙伴们正好也刚到，然后就四处找认识的人聊了聊。早上开始之前，找到了
，之前从未见过，很厉害的。后来中场休息又见到了三水清，这个也是第一次见，都是百度的。今年有三个场，很多主题都不太好取舍，只能尽可能找自己更感兴趣或者刚好想要了解的东西去听了。按照惯例，我实时记笔记，不过，被
发现了，她开始发挥战斗力，狂记录了一大堆……兔八哥
也记录了一些。嗷嗷和五花肉的主持风格简直太搭，都是狠命黑，抽奖过程也是各种搞怪。在听分享的同时，大家在微信群里也一直在讨论得很热烈，顺带还有各种黑。我今天又黑了不少人，哎呀。。。中午又用餐券体验了一下食堂，就三个菜的标准套餐，难得我这么挑食的人每种都喜欢吃，想起夏天时候在CSSconf，四个菜有三个不吃的，真是。。。我算是理解了，为什么好多来了阿里的，体型都发生了翻天覆地的变化了……下午在alinode的摊位见到了
，打了个招呼，实力非常厉害的女生，现在在朴灵团队，感觉在这个团队比在业务团队更适合发挥。晚上跟
夫妇，张秋怡，圆心，贺老，袁源，刘骥还有图灵的两位朋友一起吃了饭，然后去参加夜场，跟
几个人聊了好久，坐在地上的背影被偷拍了，那张照片的名字叫做：落寞的老男人们，年轻的吉姆同学不幸被误伤在内……。后来又组团去吃火锅，不知怎么就变成了红包大战，微信群和支付宝两边乱扔红包，大家的手机电池基本都挂了，充电宝基本也全部阵亡，只好把电脑打开充电，
的手机也插过来充了一会。元彦自我介绍的时候被我补刀了一把：从腾讯跳到阿里，结果造成两家公司的平均颜值都上升了，咳。。。快12点了才散场，照例，每次前端领域的大会都会发展成为见面会，也照例要补上一篇流水账以示纪念，以后每次我参加的都这样吧，一半严肃内容，一半水。糟了，到最后才发现，今天忘记去找
见个面了，只能下次……
写点感想，我主要关注 nodejs 作为服务器端的话题：1. 不四老师的 「用 Node.js 构建海量页面渲染服务」其实我觉得这个案例不是很好，不能很好地说明 nodejs 的优势，那两张曲线图容易迷惑不明真相的群众。那不是 nodejs 和 php 的对比图，更像是新架构和老架构的对比图，20k 的 CDN 服务器啊，把主动的推模型改成被动获取的模型很明显会把系统吞吐提高一个等级。不四老师应该也意识到这个问题了，所以在 QA 环节说，也许老系统用 php 重构，结果也许不会比 nodejs 的曲线差到哪里去。如果一个 php 系统非要用 nodejs 重构，那一般有 nodejs 非常擅长而 php 不擅长的事情，比如 WebSocket 协议支持，长连接，异步 io （网络/文件），而如果这些都没用到，那唯一的理由可能就只是 js 语（qing）法（huai）问题了。本来我想交流几个关于 koa 的问题的，无奈这一场人太多，找不到机会。不四老师说 koa 能轻易修改 body 和 header 是一种优势，但我们遇到的问题是，middleware 太容易修改 body 会引起一些诡异的问题而无法排查，你必须确保第三方的 middleware 是绝对「可控」的，还有 koa 2.0 beta 的问题，不过这不是重点，略过不提了。2. 李成银老师的「使用 ES6/7 特性开发 Node.js 项目」内容基本是手册讲解，错误捕捉和异常处理部分我看不清屏幕所以也不知道在说啥。。。QA 环节我问了两个问题：（1 为啥没提 babel require hook？在线上是否有坑？说实话我一直不确定能否把这玩意布到线上，虽然我看了下源码，有 cache 不会一直编译。（2 thinkjs 我没用过，但看过一些源码，代码质量还不错（ 至少比 thinkphp 好多了2333 ），但 js 社区一直推崇小而美，他们更喜欢搭积木而不是开航空母舰，thinkjs 是否会显得格格不入？有没有拆分的计划（类似 php 的 laravel，每个部分其实都是独立的 composer 包）？成银老师说会考虑的。3. 朴灵老师的「alinode与Node应用性能管理」这是我挺期待的话题，也是我一直很想做的事情，nodejs 的调试和定位，一直都是 nodejs 作为服务器端最大的痛点，没有之一。举个例子：写一套复杂 nodejs 程序可能会遇到的问题是，某些内存泄露会来得令人措手不及，而我们唯一能做的是利用类似
这样的东西，把 heap dump 出来然后对着密密麻麻的文字找到可疑的变量查问题。alinode 做的（我猜的）：跑一个 agentx 的常驻程序，发回 nodejs 的内存，CPU之类的日常使用情况，把 nodejs 改成 alinode，让其具备 heapdump （增加了 node-kill ）的能力，搞了 node-profiler 来搞 cpu profiling ，并与服务器端连动。比如内存泄露了，服务器会向 alinode 请求日志，拿到 headpdump 的文件，然后 alinode 的云平台跑着一个日志分析程序，自动定位到可疑的问题。agentx 算是开源的，alinode 和 node-profiler 只有二进制文件，最最重要的这套日志分析程序跑在服务器端，是个黑盒。所以 QA 环节我站起来问朴灵老师是否有开源这套日志分析系统的计划，朴灵老师含蓄地表示如果我们线上开发出一套更先进的系统，这套老的会开源的 23334. 「Node.js加速Qzone」这个我唯一的感想是打日志谁不能打，nginx + lua 打起来效率即使不能完爆 nodejs 也肯定能和 nodejs 不相上下。我觉得唯一的理由就是前端要增加话语权，控制住后端 API 和前端页面之间这层代理层，这样前端就能在自己的职责范围内有更多的想象空间，这不是一个关于技术选型的问题，而是一个关于技术话语权的争夺。总结：1. nodejs 不止因 npm 作为工具链蓬勃发展，在服务器端也前途无量，毋庸置疑。2. 大力发展 nodejs 的原因各异，有因为前端对 javascript 的偏爱，也有因为前端需要话语权，nodejs 正好可以担当这样的武器。3. 希望看到更多发挥的 nodejs 本身特长的成功案例，例如大规模的 WebSocket 服务器，国内肯定有，希望下届 D2 能挖掘一下。
-写在前面：请注意本题的主要是：「你有什么收获？」。谈收获这种问题最适合像我等肚子空空的小白踊跃回答了。想不通楼上的各位高T、高P们在此等高度上，千尺杆头，更近一步是很难得的事情嘛。各位武林盟主华山论剑，发发红包，再跟前任叙叙旧也就差不多了嘛。这大篇大篇的谈「收获」是几个意思咩？也正是题主「谈收获」的初心，我也才赶放放心心地发表一下自己的浅薄的看法。各位前辈要是挥斥方遒之余，顺便斧正一下我等小辈所谓「收获」中存在的谬误，让我们少走点弯路，给偶们一点跪舔的空间才有宗师气度嘛。因此呢，以下就是按听讲（这个词用得真准）的顺序记录下课堂笔记，难一点的题目（有 repo 的）做一点阅读理解，请各位老师们从「学术研究」的高度批阅一下，感激涕零~---一、 通过 React Native 技术变革无线开发-- 元彦 & 水澜 - 淘宝前端工程师
依次介绍了无线 Native 和 Web 各自的痛点，进而引出在双平台结合的技术 —— Portal；紧接着水澜作为 Portal 使用方用手淘【我的衣帽间】项目内实施落地。我认为 Portal 最大的亮点是：衣帽间业务层代码在无线 Web 和 Native 双平台上实现了 100% 复用率。是怎么做到的呢？截止到目前，
还未公布任何的细节，
说在本月底开源，在 2016 年会放出 RNgenerator、RNpack、App，我谈一下自己的理解：--- 1. RNgenerator业务层代码要 100% 复用，Portal 采用的方案是：用在一个项目内，利用构建工具，对一套业务代码根据规则分别打包发布至CDN。这个方案要求多平台有统一而规范的目录结构，因而 RNgenerator 就是目录结构生成工具，生成的目录结构大概如下（手敲的，大概意思是这样）：// File Structures by Protal generator
├── src/
├── CloakRoom.js // 单一入口
├── Home.js
// 业务代码 1
├── Item.js
// 业务代码 2
└── // ...
├── node_modules/
├── react-web/
├── react-native/
├── // ProtalReact // 脑补了一下至少有这个plugin
└── // ...
├── webpack.config.js
└── package.json
可以看出 RNgenerator 的特点是：单一入口 文件。这种方案的难点在于，预处理工具需要依赖 react-web 和 react-native 两个模块，分别针对双平台进行兼容处理，其中包括抹平各自平台的 DOM 结构，样式的注入方式，事件的调用机制，数据的传递等等。从命名上可以看出，react-web 的职责就是对 react 再封装，抹平组件差异的功能模块。---2. React Web 模块2.1 组件结构的一致性我们直接从放出的示例代码中分析兼容的解决方案（都是手动敲的）：//
var React = require('react');
var React = require('ProtalReact');
= require('ProtalView');
var Image = require('ProtalImage');
= require('ProtalText');
var Item = React.createClass({
render: function () {
&Image source={{url: 'picURL'}} &
&Text&Text&/Text&
注意：这段代码中没有出现 RNgenerator 的：react-web 模块，猜测此模块是封装了 Protal 开头的一系列模块在 render ，等 Repo 放出来了再核实下。首先，我们注意到代码中 ProtalReact 是原生 react 模块的二次封装，很可能是在 render 时加入了一些 AOP 功能，方便多平台 render。其次，示例代码中全部使用了类似 ProtalImage 组件（ProtalText 和 ProtalText 两个 PPT 中没写全，应该是一个意思）。PPT 中介绍，以上几个组件在 Platform Render 阶段，根据平台返回不同的 DOM 结构，如：- &View&
- &Image& =& &img&
这应该是代码跨端最为关键的地方了：借助预编译机制，在 parsing 阶段编译为可用的 JsDom。我个人认为，从结果上看，这个方案从实现层面上是肯定能做到的。不过，在使用过程中，可能有以下几点需要特别注意：1. 在 HTML 标准方面能否达到一致性：对于 `span` `img` 这样常用的容器类标签，从功能方面抹平平台差异问题不大。可是对于复杂一点的标签，极端一点说如 `&canvas&` 将来是否要支持 `&ProtalDrawImage&`，若支持各种属性和方法支持到什么程度，是非常难以权衡的事情。这和工程师水平没有关系，而是标签库在标准层面没有实现一一对应。因此，最终的 `Protal` 很可能会是两个平台模块取交集后的子集，在一些权衡和取舍后，满足绝大多数通用的场景。这一点我个人认为是可以接受的。2. 在调试和维护方面的便捷性：我们知道 `Protal` 的使用方在代码中写了 `&View&` 会被渲染为 `&div&`，随着复杂度的增加，嵌套关系过多，并且事件 Handler 绑定（例如 React Event 支持的 `onDragEnter`或`onMouseOver`） 可能经过渲染后就不太直观了，这可能会增加 Debug 和后续扩展的难度。主要的原因，可能限于我只是一个小前端，对 iOS 的标签和事件不够熟悉所致。如果是跨端的开发，业务场景不会特别复杂的前提下，使用者又特别熟练的情况下，兴许是一个不错的选择。2.2 样式的一致性示例代码样式的写法如下：var StyleSheet = require('PortalStyleSheet');
var styles = StyleSheet.create({
width : '2.3rem',
container: {
flexDirection: 'row'
首先将布局方案确定为 flexible，保证布局规格的一致性。我们注意到，和 radium不同， PortalStyleSheet 计量值主要使用 rem 为单位。水澜解释到他们团队移动端默认是700px，所以把rem基准值定为 7rem。如此这般，前端工程师【量一下】某个元素宽高是230px，内联样式就写 2.3rem。整除这个实现思路很讨巧，赞一个 ~我比较关心的是，多个设计尺寸稿，或者不太好整除的情况下，也许 winter 团队移动单位转换工具，或者简单的布局走栅格化也是不错的选择。2.3 数据获取的一致性这一块应该和跨端兼容没有太多关系，数据层使用的 GraphQL。这一块我不是特别懂。个人判断业务数据拼接整合，刚好交给了更接近具体业务的 View 层。传统 Action 层的前移，服务端专心标准标准的 API 。数据特别复杂，量级特别大的项目，无疑是大势所趋。---总得来说：这套方案整体没有用到特别惊艳的技术，但在特定通用布局和场景中，对于于业务级别的代码复用走在了很靠前的位置。由于详细的代码还没有公开，Portal 开头的组件从数量和完备性方面都还只是我的个人猜测。兴许到明年，RNgenerator、RNpack 整套体系经历更多的磨合时，这一套方案会越来越趋于完善。参考资料- - - - ---（每一个议题，都是演讲者数月甚至更多的结晶，只凭借听一个小时的演讲，对我而言不敢轻易谈[收获]的，目前在看第二份演讲者的 repo，稍后陆续更新中 ^_^）
从组织者的角度谈谈感受吧，原本是准备在夜场分享的，也好当面感谢一些人，但因为宝宝们生病了，不得不在夜场开始前赶回家，小小的遗憾。今年在从圆心那接过了D2组织的任务，可以说这是我的一个夙愿，也是一步一步实现梦想的故事。10年前入行，只是个半路出家的页面仔，在一个广州的小公司打杂。当时既没有前端这个称呼，也没有像现在业界的环境。后来知道了第一届D2，感觉就是一个圣地，如果能去看一下就好了。摸爬滚打几年到了腾讯，开始有机会参加到D2现场，当时想如果我能站在台上就好了。在腾讯做了三年来到阿里，角色也发生了变化，虽然自己没有上台，但也让组内的优秀工程师站到了D2的台上，自己也每年都积极参与到D2志愿者的工作中。（之前在现场手绘二维码的SB就是我）其实组织D2还没想过，但今年圆心把第10届D2组织的这个任务给到我，可谓是意外之喜，当时就暗暗的下了决心一定要把这件事情做好，也因为过于强烈个人的意愿为后续一些没做好的工作埋下了种子。回到正题谈组织工作：难点一：讲师招募+分享主题评选内部的讲师和外部讲师采取了公开招募+定向邀请，共收集到50+的主题，经过阿里前端委员会的认真评选，选出了现场嘉宾名单。经过一轮又一轮的试讲提升质量，到最后一周我们还在为提升分享质量而努力。过程中得罪的人可不少啊，例如不四就被我烦死了。难点二：今年强行参会的同学真的很多我们发出了1000+的电子票，在线完成确认动作的只有700+，按往年的经验拿到票的人还有相当一部分会临时变卦不来。所以午餐、茶歇等都是按600人准备的。（浪费可耻）但当天实际到场的厂外同学就有1000+，有很多没票也大老远跑来参会。幸好临时追加入园人数，解决了这个问题。难点三：现场组织工作这也是做的最不好一点，因为前面提到的过于强烈的情感和自己狮子座的性格使然，有很多事情都是自己在跟进，别人做了，我也必须去看一眼才放心。结果就是我不在的时候事情的扭转就会出问题，志愿者都很热情，但往往不知道现在该做些什么。磕磕碰碰的总算完成了一天的工作，结果面基的时间都完全没有了。。。如果没有嗷嗷、花肉、重鱼的临场应变，以及各位嘉宾的激情演出，大家的抱怨可能会多得多。除了嗷嗷、五花肉、重鱼大家都看得见以外，还有很多大家看不见的幕后功臣，例如负责票务、签到、抽奖的百景，负责大会官网的星凯、少园，还有更多和大家默默差身而过但为大家提供服务的志愿者们，我就不一一细数了。
大叔实时记录。第一场去听了React Native，人太多，会场小。听了一半走了，一是因为感觉话题有点浅，前半程可以总结为“react介绍”，一直没等到native部分和实践经验，二是因为确实有点冷得受不了。回到主会场，听天猫Node双十一的实践，听到了一些Node常见的话题，比如保证不挂，上CDN分不弃之类的，中规中矩。（此时某群里对测试部分展开了激烈讨论。）第二场继续主会场，手机淘宝hybrid实践。性能标准：2G 10s内占 80%3G 6s内占 60%4G 3s内占 70%图片省流量：WebP 一个活动页的实例，转成webp之后体积455 k-&133k，一个banner节省了70%，不过看了一眼那个图，感觉本来也应该有优化空间，这里有一点怀疑空间。省内存：一个像素4个字节，雪碧图不合理拼接会增加内存占用，尽量使用与显示尺寸匹配的图片尺寸省请求：只加载需要使用的字体（手机端只加载一种字体格式）网络链路优化DNS单个域名解析时间可达3.7s，使用HTTPDNS预解析解决使用SPDY协议，但一开始效果不明显，因为域名太分散（15个），无法充分利用多路复用的特性。后面做了域名收敛。（不过这个时间点，可以考虑用HTTP2来替代了。）动态数据优化：要求服务端200ms以内响应。合并首屏动态数据请求接口。效果：平均加载时间由10多s降到1.6s。2G也基本上2、3秒完成（但是看前面一张图，好像并没有那么明显）第二场下半场换人了，讲hybrid的加载策略。通过server预发，客户端主动拉或者接收推送，预先加载页面。配合个性化下载什么的策略。这块没做过，听得也就不那么细。然后是《React-Native 5分钟简介》（这是我为中间的一段脑补的标题）再然后是《如何用native弥补H5 component组件的不足》（这也是我脑补的标题，有人说是乱入第一场blend UI的内容了）整个第二场的两个主题都基本没有具体做法，没有实例。只有“我们做了这些，很牛逼”。而且内容覆盖很散，并没有集中的主题。（并引起了某群的集体吐槽。）下午第一场：五花肉开场，一上来强调了两件事：一，“不要黑我”，二，朴（pu3）灵，not朴（piao）灵一，Node现在由Node.js基金会打理，生态繁荣，高手出入。全面拥抱ES 2015。LTS发布机制。世界上最大的模块仓库npm。按下来出现了微博剧透的PPT“然并卵”。二，问题。很萌的来了一句“那么它的问题是什膜咧？”CPU离奇飙高、内存无故泄漏、GC频繁。Node对开发者来说是一个黑盒，黑盒中还有libuv、v8等黑盒。缺少分析和排查工具。现在有一些工具也不能深入内核。出现了微博上的“如何修复线上bug”的gif图。三，alinode内核可监控，提供更好的工具。修改内核，使CPU 内存 GC等数据暴露出来。然后数据可视化。接入报警系统（实现中）。接下来开启奶爸模式，“做后端的像照顾孩子一样，写完了还要每天看他哭，看他笑，看他成长。”安利CNPM，“不用不是中国人”，因为在中国用起来特别快。大家都喜欢中午安装模块，有一台低配机经常CPU
100%。(演示CNPM的CPU分析，教学profile面板用法，哈哈)(又演示了分析html minify的案例)(又演示了淘宝收藏夹某个业务的案例)(又演示了koa的案例)总结，alinode改变了线上问题分析的流程，分析不是依靠线下重现，而是靠线上实时收集CPU和内存数据分析。未来：免费提供给开源和公益项目 加入Node.js基金会 成为node core contributor 推动Node稳定性可靠性，使之真正成熟下午第二场：Node.js加速QZone第一部分产品体验还在想上一场的问题，五花肉没让我提问，就重新组织了一下。所以前面一段没仔细听。大意是手机QZone对内容做了离线策略，在无网和弱网条件下能快速打开。为了保证更好的体验，对部分内容由APP部分做预离线。甚至使用了聊天通道（长连接，质量好）来预离线资料。（这个想法太疯狂了……佩服……）(第一部分我还没get到node的点在哪里……原谅我……)第二部分问题定位Node接入层来做抓包，可以存为saz格式供fiddler查看。第三部分开发效率Node中添加一个window，保存跟请求相关的所有东西，每一次请求的window是不同的。因为request对象是局部的，直接使用上下文对象会更方便。（深以为然，不过这种方法很容易显得山寨。）（这一场感觉老丢细节，不知道是讲漏了还是我听漏了……略遗憾）下午第三场 多语言文案处理方案语言包方案 -& 文案管理平台管理平台负责维护wording，并提供导入导出东西，以及自动导出为资源文件的功能。（这里有不少疑问，无效wording会积累不敢删除如何处理，导入导出时key如何处理，导入导出谁来操作，发布与代码不同步怎么处理？）写了一个页面模板内联JS中内嵌后端变量输出模板的方式。（实名反对后端模板乱入js代码）（听了一半走了，听到的内容感觉用起来还是会有些问题，不知道后面是否有讲更好的方案）然后乱入到了react场，听说很精彩，只听到了一点点：
他们做了一个“上帝模式”，即把所有状态保存到一个全局的地方，然后重现用户场景时只需要更新这个状态，就可以完美复现用户当时的场景。还是很牛的。然后我又乱入回主会场，在讲数据可视化的东西，主要是讲自己做过一些什么，当时是怎么把它可视化出来的（并非技术），还是挺有意思的。
的号召下，我们小组这次基本上全员出动（除一个小伙伴临时有事没来），来膜拜大神，学习新姿势。（貌似我没有写是五花肉的前男友就顺利通过D2申请了，哈哈[骄傲脸]）这次D2的主题是融合，演讲主题主要分两大块，一块是 Node.js，一块是 React + React Native（果然是2015最火技术），然而在我们这边的实际项目中并没有用到这两个，所以估计对我们小组的人员来说，全听懂还是有困难的（经验丰富的大师兄和乔大师除外）。好在自己之前做过一些跟 Node.js 相关的，在来之前也稍微补了一下 React ，写了小demo，所以也还能勉强听懂一些。上午第一场听的是不四老师的用《Node.js 构建海量页面渲染服务》，看到了在阿里，Node.js 确实是被广泛使用的（仅次于PHP，不知道有没有记错。。。），并且用来承载一些核心业务（比如淘宝首页促销页等），并能经得起双十一这样高峰值的考验。这场主题印象比较深的主要有下面几点（因为是自己要么没听过要么没用过的。。。）1. koa 和 express 的对比。在 express 里中间件顺序执行，而 koa 是一个包裹在后面所有中间件的装饰器（比如将charset、gzip这些都放到各中间件完成），所以核心代码也比较精简2. 编写可测试的代码，持续集成。记得当时不四老师问了一句，你们 Node.js 的开发都写了测试吗，举一下手，结果没几个人举，然后不四老师说，没测试的代码你们真的敢放上去跑吗。。。想想我自己就是其中一个[羞愧脸]3. 使用 cluster 进行多核处理。master 只做进程管理，worker 异常退出后自动重启，http 服务优雅退出4. 日志管理。所有请求都有 accesslog 追踪，所有异常统一处理分类输出5. 基于 CDN 的 URL 统一，在 CDN 识别设备类型，为 pc 和移动端缓存不同页面第二场一开始是去听杨文坚老师的《Component 化设计与实践》的，去到发现人爆满，站的位置都没有。。。听了一会，发现在飞哥之前的几篇组件化方面的文章里面已经看过，所以就出来了，想换场听李成银老师的《使用ES6/7特性开发Node.js项目》，结果发现根本挤不进去，于是就回报告厅听《Hybrid APP 框架的架构演进》了，去到的时候晓田老师已经讲完，主要听隐风老师讲如何将 Native 组件覆盖到 webview 上，觉得还是要以后自己做了相关的东西才能理解更深刻。中午跟几个小伙伴去食堂吃了饭，然后用飞哥拨的经费集体去喝了星巴克，回去之后还打电话叫飞哥出来一起在门口拍了张合照。。。因为上午主听了一场 Node.js 的，下午第一场选择了听承玉老师的《React 及其生态圈在蚂蚁金服的实践》，主要记了以下几点。1. Ant Design，一个基于 React 构建的一套 UI 组件库。听过但是没用过，打算以后使用 React的时候深入了解一下。。。。2. 了解了在蚂蚁金服内部是如何进行组件化实践的，像购物车、表单处理等，让后台人员也可以在简单培训后使用组件进行前端开发。3. React Native 的一些优势。比如 100% 的 Native UI 和 API，编程语言能力，布局和样式能力，开发体验，开源，社区等。其实同时进行的另外两场，朴灵老师的《alinode 与 Node 应用性能管理》和 霍雍老师的 《Web接口管理工具 RAP》（最近刚好在做一个类似的 demo）也很想去听的，无奈冲突了，只能后面跟其他想听的主题一块看录像学习了。。。下午第二场先是去听了郭虹宇老师的《融合 Web 技术的 Native UI 架构》，后来还是发现自己没有进行过实际的 React Native 开发听起来感受不强烈，就换场去听了黄友昆老师的《Node.js 加速 Qzone》，首屏离线，点开就有，消除白屏，确实让体验更好了。然后是介绍了 使用 window 对象而不是直接传 request 和 response，做一个log工具，很有借鉴意义。话说友昆老师的 PPT 做的好冷，比如提到最难点的时候那张 最南点500米。。。最后一场是听了宁朗老师的《DataV 数据可视化引擎》，最大的感觉就是很酷炫，不过对 WebGL没什么了解，所以没法对他们开发过程中踩的坑和解决方案感同身受，就当开眼界了。。。一天听的内容大概就是这些了，主要有几点感想：1. 前端技术果然是日新月异的，越来越丰富，能做的事情也越来越多，Node.js，让前端工程师使用 javascript 进行后台开发，也就更有了话语权，而且就算不使用 Node.js 开发，大多前端构建工具也是基于 Node.js 环境的，所以不了解的可以了解一些，感兴趣的可以深入一下。2. 组件化确实是一个很好的理念，不过我们目前的开发主要是基于 MVVM 的 Angular，所以体会不是很深刻（其实也用 directive 进行了一些组件化实践）。了解各自的特点及应用场景，才能进行更好的技术选型，多进行技术储备肯定是没错的。3. React Native，结合了 Web 应用和 Native 应用的优势，使 IOS/Android 的开发具备 Web 开发的体验，后面应该会有更多 React Native 的应用出现，因为一直想尝试做 APP 玩，所以对这个技术很感兴趣。。。综上，这次的 D2 之行让第一次去参加技术论坛的我大开眼界，收获颇丰，以后类似的活动也一定积极参加，强烈建议各位前端小伙伴有机会尽量去~~
白天的场次各有干货，而给我最深的感触来自于夜场。参加夜场的人数比白天要少许多，流程安排上也似乎没有怎么用心。基本上就是几位自愿上台的小伙伴即兴分享，以及之后的自由讨论。可是这一番看起来很『乱』的场景，让我的脑海中浮现出了一个词：百家争鸣。就因为是即兴，在台上，有痴狂的求学者大胆地冲上台向众人咨询职业发展的迷茫，有阿里的大大们将自己对web前端发展的感受和经验和盘托出，也有前端的新秀勇敢地说出与前者不同的意见和新的观点。就因为是自由，在台下，小小的不足50平米的夹层间里，百来人大大小小围了十几个圈子，大家热情洋溢的表情下，都在热烈讨论着各式不同的话题。其中印象最深的，就是已工作十八年的 对web开发的展望以及一名的94年新秀实习生因对其有不同观点而上台~这种年龄界限的对冲，大有长江后浪推前浪之势呀~简单附着一点， 认为此后最有潜力的web开发技术有三：1. http22. service worker3. jspm loader规范(抱歉，之前一直听错成了js npm...)并且对前端开发的未来大胆地做出了一个预言，具体的还是大大自己来说吧 我觉得，这个世界有这么一群志同道合的人，有这么一个专业可爱的盛会，是node社区之福，是javascript语言之福，是我web前端工程师们之福呀！---------------------------这种百家争鸣的场景，自我刚入门前端，到北漂追梦，到返乡创业，从来都没有经历过，所以感触可能比经常出入这类会场的同学们要敏感、要深刻。不过我不能全怪二线城市技术氛围的短板，因为我自己也深深地感受到了自己视野的狭隘，和求知动力的匮乏。不管怎么说，能够让自己重新审视自己，让自己对自己的行业有了全新的视野和信心，不虚此行~也不论阿里巴巴有多少负面消息，感谢阿里塑造的这么特别的前端氛围~-------凌晨1点34--------睡了一半想起来今天有个近距离的抓拍，拿起手机就扔过来了。
2013年第一次来杭州，赶上ADC，那会D2是个分论坛，那是我第一次参加技术会；2014年，在 SegmentFault 作为赞助方，参与了D2，看着台上的嗷嗷，觉得是很自然的主持风格，技术人自己做的交流就该这样；2015年，加入D2 2015组委会，也终于能够配合嗷嗷，真的很靠谱很专业，接手D2官微；主人翁的感觉，让我看不下去每个站在门口因为没有票进不了场的同学，还私自申请了几张访客号，让他们进来12.19活动还没开始的时候看到他们在知乎开了帖子「参加D2 2015是怎么样的体验」，不敢看可能很多部分没有照顾到，参会者/赞助商/朋友们，感谢你们的配合，一直到九点多散场都还在讨论，夜场出乎意外的没有冷场，每个人都很积极踊跃，就算我们没有麦克风，也丝毫不影响效果；没有照顾到的抱歉，如果你能收获一些，我们就觉得很有价值了爱你们，还有愿圣光与我们同在（比如最后一张自拍），明年见！?( ?? ?)?部分志愿者合照，大家平时工作都是前端开发，一起做了很多事情，扛袋子，在大门口寒风里签到，还有很多很多...对我来说，能看到每一年不一样的自己，能够在不同的位置不同的角度参与同一个技术会议，还有能认识更多的可爱的人，这就够了勿忘初心，D2 会本着技术为本，做的越来越好，祝福 D2，也祝福我们（关于前男友的梗，大家不要再纠结了，就是玩笑而已，为了活跃现场气氛，前一天晚上嗷嗷跟我说让我想两个段子，想不出来就这个了，So ... 如果引起大家不适，道个歉）
现场有两波人，一波来看望前女友，一波观望前端圈著名女媛。夜场是前男友经验交流圈。--------------------------#D2 2015# 贺老夜场的那句话很有共鸣，勿忘初心，还记得当年写第一行HTML时的那股觉得可以改变世界的心情。幸好自己还未曾改变，这把年纪了，昨天在那张桌子上coding的时候依旧是那么的满足和简单的快乐。--------------------------居然中奖了---------------------------西厂的办公环境真心不错。
已有帐号？
无法登录？
社交帐号登录}