首页 文章 精选 留言 我的

精选列表

搜索[全模态模型],共10000篇文章
优秀的个人博客,低调大师

基于全志平台成功移植 Arm Ubuntu 桌面系统

以桌面应用为主的开源的Ubuntu桌面操作系统,为全球数百万的PC和笔记本电脑提供了生产力。 为方便用户选择合适的版本进行应用软件开发,我们发布了基于Ubuntu 64bit系统构建的Ubuntu16.04和Ubuntu18.04两个版本的 Ubuntu Desktop系统。 Ubuntu16.04和Ubuntu18.04 均具有资源占用少,稳定性强的特点。 采用简洁高效的轻量级Linux主流桌面环境Xfce4,为用户提供了一个默认GNOME 桌面环境之外的选择。 Ubuntu16.04和Ubuntu18.04 系统可定制性强,针对嵌入式平台,可以根据需求,增加裁剪系统服务。 基于Ubuntu系统,已经打通各通用底层接口。 提供基于Arm GE8300 GPU的OpenCL支持。 支持G2D加速 完美适配QT 目前宇芯已经应用Ubuntu16.04 和Ubuntu18.04 系统,开发了工业平板及智慧支付领域的系统解决方案,帮助客户产品快递开发并成功落地。

优秀的个人博客,低调大师

淘宝小部件 Canvas 渲染流程与原理全解析

作者:史健平(楚奕) 上篇回顾:《 淘宝小部件:全新的开放卡片技术!》、《淘宝小部件在 2021 双十一中的规模化应用》 本文主要从技术视角阐述 Canvas 在小部件下的渲染原理。 在进入正文之前需要先解释下什么是【小部件】,小部件是淘宝模块/卡片级的开放解决方案,其主要面向私域提供类小程序的标准&一致化的生产、开放、运营等能力,它有着多种业务形态,如商品卡片、权益卡片以及互动卡片等等,ISV开发的小部件可以以极低成本部署到店铺、详情、订阅等业务场景,极大提高了运营&分发效率。 从端上技术视角看,小部件首先是一个业务容器,它的特点是DSL标准化、跨平台渲染、跨场景流通: DSL标准化是指小部件完全兼容小程序的DSL(不仅仅是DSL,还包括原子API能力、生产链路等等),开发者不需要额外学习即可快速上手; 跨平台渲染顾名思义,小部件内核(基于weex2.0)通过类似flutter自绘的方案可以在Android、iOS等不同操作系统上渲染出完全一致的效果,开发者不需要关心兼容性问题; 最后跨场景流通是指小部件容器可以『嵌入』到多种技术栈的其他业务容器中,比如Native、WebView、小程序等等,以此做到对开发者屏蔽底层容器差异并达到一次开发,多处运行的效果。 无独有偶,Canvas 在小部件下的技术方案与小部件容器嵌入其他业务容器的技术方案居然有不少相似之处,那么下边笔者就从 Canvas 渲染方面展开来讲一讲。 原理揭秘 端侧整体技术架构 小部件技术侧的整体架构如下图所示,宏观看可分为 "壳" 与 "核" 两层。 "壳"即小部件容器,主要包括DSL、小部件JSFramework、原子API以及扩展模块比如Canvas。 "核"为小部件的内核,基于全新的weex2.0。在weex1.0中我们使用类RN的原生渲染方案,而到了weex2.0与时俱进升级到了类Flutter的自绘渲染方案,因此weex2.0承担了小部件JS执行、渲染、事件等核心职责,并细分为JS脚本引擎、Framework与渲染引擎三模块。JS引擎在Android侧使用轻量的QuickJS,iOS侧使用JavaScriptCore,并且支持通过JSI编写与脚本引擎无关的Bindings;Framework层提供了与浏览器一致的CSSOM和DOM能力,此外还有C++ MVVM框架以及一些WebAPI等等(Console、setTimeout、...);最后是内部称之为Unicorn的渲染引擎,主要提供布局、绘制、合成、光栅化等渲染相关能力,Framework与渲染引擎层均使用C++开发,并对平台进行了相关抽象,以便更好的支持跨平台。 值得一提的是,unicorn渲染引擎内置了PlatformView能力,它允许在weex渲染的Surface上嵌入另一Surface,该Surface的内容完全由PlatformView开发者提供,通过这种扩展能力,Camera、Video等组件得以低成本接入,Canvas也正是基于此能力将小程序下的Native Canvas(内部称之为FCanvas)快速迁移到小部件容器。 多视角看渲染流程 更多细节还可以参考笔者先前的文章《跨平台Web Canvas渲染引擎架构的设计与思考(内含实现方案)》 到了本文的重点,首先依然从宏观角度看下Canvas大体的渲染流程,请看下面图示,我们从右到左看。 对开发者而言,直接接触到的是Canvas API,包括w3c制定Canvas2D API以及khronos group制定的WebGL API,它们分别通过canvas.getContext('2d')和 canvas.getContext('webgl') 获得,这些JS API会通过JSBinding的方式绑定到Native C++的实现,2D基于Skia实现而WebGL则直接调用OpenGLES接口。图形API需要绑定平台窗体环境即Surface,在Android侧可以是SurfaceView或是TextureView。 再往左是小部件容器层。对weex而言,渲染合成的基本单位是LayerTree,它描述了页面层级结构并记录了每个节点绘制命令,Canvas就是这颗LayerTree中的一个Layer -- PlatformViewLayer(此Layer定义了Canvas的位置及大小信息),LayerTree通过unicorn光栅化模块合成到weex的Surface上,最终weex和Canvas的Surface均参与Android渲染管线渲染并由SurfaceFlinger合成器光栅化到Display上显示。 以上是宏观的渲染链路,下边笔者试着从Canvas/Weex/Android平台等不同视角分别描绘下整个渲染流程。 Canvas自身视角 从Canvas自身视角看,可以暂时忽略平台与容器部分,关键之处有两点,一是Rendering Surface的创建,二是Rendering Pipeline流程。以下通过时序图的方式展示了这一过程,其中共涉及四个线程,Platform线程(即平台UI线程)、JS线程、光栅化线程、IO线程。 Rendering Surface Setup: 当收到上游创建PlatformView的消息时,会先异步在JS线程绑定Canvas API,随后在Platform线程创建TextureView/SurfaceView。当收到SurfaceCreated信号时,会在Raster线程提前初始化EGL环境并与Surface绑定,此时Rendering Surafce创建完成,通知JS线程环境Ready,可以进行渲染了。与2D不同的是,如果是WebGL Context,Rendering Surace默认会在JS线程创建(未开启Command Buffer情况下); Rendering Pipeline Overview: 开发者收到该Ready事件后,可以拿到Canvas句柄进而通过getContextAPI选择2d或者WebGL Rendering Context。对于2d来说,开发者在JS线程调用渲染API时,仅仅是记录了渲染指令,并未进行渲染,真正的渲染发生在光栅化线程,而对于WebGL来说,默认会直接在JS线程调用GL图形API。不过无论是2d还是WebGL渲染均是由平台VSYNC信号驱动的,收到VSYNC信号后,会发送RequestAnimationFrame消息到JS线程,随后真正开始一帧的渲染。对于2D来说会在光栅化线程回放先前的渲染指令,提交真实渲染命令到GPU,并swapbuffer送显,而WebGL则直接在JS线程swapbuffer送显。如果需要渲染图片,则会在IO线程下载并进行图片解码最终在JS或者光栅化线程被使用。 Weex引擎视角 从Weex引擎视角看,Canvas属于扩展组件,Weex甚至都感知不到Canvas的存在,它只知道当前页面有一块区域是通过PlatformView方式嵌入的,具体是什么内容它并不关心,所有的PlatformView组件的渲染流程都是一致的。 下面这张图左半部分描述了Weex2.0渲染链路的核心流程: 小部件JS代码通过脚本引擎执行,通过weex CallNative万能Binding接口将小部件DOM结构转为一系列Weex渲染指令(如AddElement创建节点、UpdateAttrs更新节点属性等等),随后Unicorn基于渲染指令还原为一颗静态的节点树(Node Tree),该树记录了父子关系、节点自身样式&属性等信息。静态节点树会在Unicorn UI线程进一步生成RenderObject渲染树,渲染树经过布局、绘制等流程生成多张Layer组合成为LayerTree图层结构,经过引擎的BuildScene接口将LayerTree发送给光栅化模块进行合成,最终渲染到Surface上并经过SwapBuffer送显。 右半部分是Canvas的渲染流程,大体流程上边Canvas视角已介绍过,不再赘述,这里关注Canvas的嵌入方案,Canvas是通过PlatformView机制嵌入的,其在Unicorn中会生成对应的Layer,参与后续合成,不过PlatformView有多种实现方案,每种方案的流程大相径庭,下边展开讲一下。 Weex2.0在Android平台提供了多种PlatformView嵌入的技术方案,这里介绍下其中两种:VirtualDisplay与 Hybrid Composing,除此之外还有自研的挖洞方案。 VirtualDisplay 此模式下PlatformView内容最终会转为一张外部纹理参与Unicorn的合成流程,具体过程:首先创建SurfaceTexture,并存储到Unicorn引擎侧,随后创建android.app.Presentation,将PlatformView(比如Canvas TextureView)作为Presentation的子节点,并渲染到VirtualDisplay上。众所周知VirtualDisplay需要提供一个Surface作为Backend,那么这里的Surface就是基于SurfaceTexture创建。当SurfaceTexture被填充内容后,引擎侧收到通知并将SurfaceTexture转OES纹理,参与到Unicorn光栅化流程,最终与其他Layer一起合成到Unicorn对应的SurfaceView or TextureView上。 此模式性能尚可,但是主要弊端是无法响应Touch事件、丢失a11y特性以及无法获得TextInput焦点,正是由于这些兼容性问题导致此方案应用场景比较受限。 Hybrid Composing 在此模式下小部件不再渲染到SurfaceView or TextureView上,而是被渲染到一张或者多张由android.media.ImageReader关联的Surface上。Unicorn基于ImageReader封装了一个Android自定义View,并使用ImageReader生产的Image对象作为数据源,不断将其转为Bitmap参与到Android原生渲染流程。那么,为啥有可能是多个ImageReader?因为有布局层叠的可能性,PlatformView上边和下边均有可能有DOM节点。与之对应的是,PlatformView自身(比如Canvas)也不再转为纹理而是作为普通View同样参与Android平台的渲染流程。 Hybrid Composing模式解决了VirtualDisplay模式的大部分兼容性问题,然而也带来了新的问题,此模式主要弊端有两点,一是需要合并线程,启用PlatformView后,Raster线程的任务会抛至Android主线程执行,增大了主线程压力;二是基于ImageReader封装的Android原生View(即下文提到的UnicornImageView)需要不断创建Bitmap并绘制,特别是在Android 10以前需要通过软件拷贝的方式生成Bitmap,对性能有一定影响。 综合来看Hyrbid Composing兼容性更好,因此目前引擎默认使用该模式实现PlatformView。 Android平台视角 下面笔者试着进一步以Android平台视角重新审视下这一过程(以Weex + Hybrid Composing PlatformView模式为例)。 上边提到,Hybrid Composing模式下小部件被渲染到一张或多张Unicorn ImageView,按照Z-index从上到下排列是UnicornImageView(Overlay) -> FCanvasTextureView -> UnicornImageView(Background) -> DecorView,那么从Android平台视角看,视图结构如上图所示。Android根视图DecorView下嵌套weex根视图(UnicornView),其中又包含多个UnicornImageView和一个FCanvasPlatformView (TextureView)。 从平台视角看,我们甚至不需要关心UnicornImageView和FCanvas的内容,只需要知道它们都是继承自android.view.View并且都遵循Android原生的渲染流程。原生渲染是由VSYNC信号进行驱动,通过ViewRootImpl#PerformTraversal顶级函数触发测量(Measure)、布局(Layout)、绘制(Draw)流程,以绘制为例,消息首先分发到根视图DecorView,并自顶向下分发(dispatchDraw)依次回调每个View的onDraw函数。 对于FCanvas PlatformView来说,它是一个TextureView,其本质上是一个SurfaceTexture,当SurfaceTexture发现新的内容填充其内部缓冲区后,会触发frameAvailable回调,通知视图invalidate,随后在Android渲染线程通过updateTexImage将SurfaceTexture转为纹理并交由系统合成; 对于UnicornImageView来说,它是一个自定义View,其本质上是对ImageReader的封装,当ImageReader关联的Surface内部缓冲区被填充内容后,可以通过acquireLatestImage获得最新帧数据,在UnicornImageView#onDraw中,正是将最新的帧数据转为Bitmap并交给android.graphics.Canvas渲染。 而Android自身的View Hierarchy也关联着一块Surface,通常称之为Window Surface。上述View Hierarchy经由绘制流程之后,会生成DisplayList,并在Android渲染线程经由HWUI模块解析DisplayList生成实际图形渲染指令交由GPU进行硬件渲染,最终内容均绘制到上述Window Surface,然后与其他Surface一起(比如状态栏、SurfaceView等)通过系统SurfaceFlinger合成到FrameBuffer并最终显示到设备上,以上就是Android平台视角下的渲染流程。 总结与展望 经过上边多个视角的分析,相信读者对渲染流程已有初步的了解,这里稍稍总结一下,Canvas作为小部件核心能力,通过weex内核PlatformView扩展机制支持,这种松耦合、可插拔的架构模式一方面使得项目可以敏捷迭代,让Canvas可以在新场景快速落地赋能业务,而另一方面也让系统更加灵活和可扩展。 但与此同时,读者也可以看到PlatformView自身其实也存在一些性能缺陷,而性能优化正是我们后续演进的目标之一,下一步我们会尝试将Canvas与Weex内核渲染管线深度融合,让Canvas与Weex内核共享Surface,不再通过PlatformView扩展的方式嵌入,此外对于互动小部件来说未来我们会提供更精简的渲染链路,敬请期待。 关注【阿里巴巴移动技术】微信公众号,每周 3 篇移动技术实践&干货给你思考!

优秀的个人博客,低调大师

AuthPass —— 基于 Flutter 的全平台密码管理器

AuthPass - 适用于所有平台的基于 Flutter 的密码管理器。Keepass 2.x (kdbx 3.x) 兼容。 下载: Mac 桌面:Mac App Store Android:Google Play 商店或F-Droid iOS:应用商店 Linux 桌面:查看博客文章以获取安装说明 Windows 桌面:Microsoft Store或Windows 安装指南 特性: 使用密码读取/解密 kdbx 3.x 通过url下载kdbx文件 解析解密的 XML/处理受保护的值 Flutter 移动脚手架 (ios/android) 使用密钥文件解密 与生物识别技术(指纹)集成 编辑现有条目 将更改保存到 kdbx 文件中。 创建新的 kdbx 文件。 与 Dropbox 或 google drive 等云服务同步 CI 管道/持续构建、发布 kdbx 4 支持兼容性 Android:自动填充

优秀的个人博客,低调大师

KeePassXC 2.6.6 发布,全平台密码管理工具

KeePass 2.6.6现已发布。KeePassXC是由 KeePass 密码管理器的一个分支发展而来的,相比原版 KeePass,KeePassXC 除了适配 Windows,还适配了 Linux 和 macOS。通过KeePassXC可以存储和管理个人的敏感信息。保存在 KeePassXC 上的信息全部都会进行离线加密,借助于云存储服务可以实现跨平台同步。 本次具体更新内容如下: Fixed 修复了按 hotkey 时的focusing search#6603 在处理之前从 TOTP 键输入中修剪空格#6604 修复在 macOS 上的构建#6598 解决未使用的返回值的编译器警告问题#6607 更新说明:https://keepassxc.org/blog/2021-06-11-2.6.6-released/

优秀的个人博客,低调大师

十全十美,10款chrome神器

来源:恒生LIGHT云社区 前言 对于从事IT行业的我们来说,几乎无时无刻都在用chrome浏览器,因为它给我们的工作和生活带来了极大的便利。今天给大家分享我用过的 10款牛逼的 chrome插件,你看完前 3个可能就会忍不住想 点赞了。 1. 谷歌翻译 很多小伙伴,英语不太好,包括我自己,英语刚过四级。从事软件相关工作时,有时有些吃力,因为很多优秀的技术网站、书籍或者文章都是老外写的,如果因为看不懂就放弃阅读,我们将会少了很多学习和进步的机会。 今天分享的第一个神器就是:谷歌翻译。 在没使用谷歌翻译之前,访问docs.mongodb.com/drivers/jav… 使用 谷歌翻译插件(其实现在已经是chrome浏览器的内置工具): 之后看到的页面,变得毫无违和感: 页面内容一下子变成了全中文,幸福来得太突然了,哈哈哈。 2. github加速器 github号称是全球第一大同性交友网站,它是程序员的乐园,里面有各种好玩的开源项目。很多编程爱好者,秉承share精神,喜欢把自己优秀代码提交到 github上,能够让更多的人看到,帮助更多的人。 但是,在国内对 github访问非常慢,是很多程序员非常头疼的一件事。 这时可以用 github加速器插件:开启插件功能后,再访问该页面: 2秒后就能非常愉快的访问 github了。 3. Octotree github上默认的项目展示页面,对用户不太友好。如果想要查找某个文件,必须一层层点击往下找,默认是平铺展示内容,无法用树形结构展示。 默认的页面是长这样子: 如果安装了Octotree插件: 之后,多了一个树状目录: 可以非常方便的查找某个文件。 4. Infinity 不知道你有没有过这种想法: 觉得自己的浏览器首页太low,想换个背景,不知道怎么换。 想把自己收藏起来的网站,放在显目的地方,让自己方便访问。 想把搜索引擎放在首页一下子就能看到。 恭喜你,这些需求chrome神器:Infinity都能帮你实现。 需要安装Infinity插件: 之后打开浏览器时,就会自动弹出如下页面: 可以自定义你喜欢的任何网站: 此外,首页右下角的小风车,点击一下就能自动切换一张漂亮的背景图片。据说每天点一下小风车,每天都会拥有好心情。 vue.js devtools 如果有接触过前端的朋友会发现,现在基本上是:react 和 vue 的天下。我本身是做后端开发的,相较而言,使用更多的是 vue,它配合Element UI一起使用,大大提升了开发页面的效率。 如果代码运行时出问题了,想调试怎么办?使用传统的debugger模式,不是说不行,不过我在这里推荐一个更牛逼的调试方法。 需要安装vue.js devtools插件: 之后,访问页面时,就能调试了: 你想看到的大部分内容,这里都有。是不是很神奇? 6. ImageAssistant 在平时的工作或生活当中,我们经常需要上传和下载图片。如果在浏览网页的时,喜欢某些图片,我们需要一张张手动下载,非常不方便。 有时候需要对上传的图片进行编辑,调整文字大小、样式,加一些水印效果等。我们一般需要先使用专业的图片工具,把图片编辑好,再重新上传,很麻烦。 有没有一款软件,可以帮我们解决这些问题呢? 答案是肯定的,这时可以使用google的ImageAssistant插件: 之后,访问网页时选择 提取本页图片: 就会出现如下网页: 该网页中展示了之前页面中的所有图片,包括尺寸等信息,可以批量下载。 此外,还能对上传的图片进行编辑: 看到这里,你爱上它了没?反正我是爱不释手。 7. LastPass 随着互联网的蓬勃发展,出现了越来越多的网站,其中大部分网站为了保持用户的粘性,需要用户自己注册和登录。为了安全起见,用户密码一般要求包含:数字、字母、特殊字符、还要区分大小写等,并且要求密码长度少则8位,多则十几位。 为了方便,你可以将所有密码设置成一样,但是如果一旦泄露,所有网站上你相关信息都可能会被泄露,风险太高。所以,还是把密码设置成不一样吧,这样我们睡觉也安心一点。 如果你只注册了一两个网站还好,但如果你过注册过几十个,甚至上百个网站,那么多密码你都能记得住? 答案是否定的,这时就急需一种安全管理密码的工具。 这时又一个chrome神器:LastPass出现了。 它需要先注册,这一步很容易完成。然后添加想访问的网站地址、用户名和密码,以后想访问该网站,直接点击一下即可,就不用再重复输入用户名和密码,方便快速访问,并且自动登录。 LastPass的功能非常强大,其他类似的插件还有:1Password、Bitwarden等。 8. adblock 我们在浏览网页的时候,经常会发现广告像狗皮膏药一样,无处不在,如影随形。有些页面甚至广告就占了整个屏幕的一半,真正的有价值的信息,我们每次都需要用肉眼一一分辨出来,相当让人抓狂,大大增加了搜索资料的时间。这也是很多人喜欢用google搜索资料,不喜欢用baidu的主要原因。 有没有办法,屏蔽掉一些多余的广告,让我们能看到净化后的页面内容呢? 答案是有的,可以使用AdBlock,它是目前世界排名第一的免费广告拦截程序。 需要安装 AdBlock插件: 之后,就能使用 AdBlock拦截广告了。一种方式是自定义拦截规则,不过有些复杂,需要仔细研究一下。还有另外一种手动的方式,这种方式相对来说更简单,在需要屏蔽的广告上右键,在弹窗的工具窗口中选择AdBlock中的选项即可。 好了,世界终于清净了。 9. markdown nice 对于有些写公众号的朋友来说,在文章排版上花费的时间,有可能比写一篇文章的时间还多。为了解决写文章时的排版问题,一些强大的排版工具应运而生,比如:md2all 和 markdown nice ,能够解放他们的双手,让他们可以把更多的时间花在文章内容上。 需要安装markdown nice插件: 之后,在公众号后台写文章时,你只用专注于写 markdown语法的文章即可,然后选择一种主题和代码主题,其他的交给插件。 最终文章会自动生成左半部分的样式,是不是很nice? 10. JSONView JSON数据格式简单,结构化,层次分明,是开发人员最常用的数据格式,目前是大部分接口返回值的首先。 有时我们在浏览器中访问get请求数据,由于接口返回值太多,一眼根本无法看出数据的层次和结构,顿时有点懵逼。针对这种情况,很多人可能会想到,将数据复制到一些在线的Json工具,或者使用postman发送请求,这样就能非常愉快的浏览格式化的数据。 这样不是不行,我想说的是,其实不用这么麻烦,还有更简单的方式。只用安装一款chrome插件,在浏览器中,就能轻松访问浏览格式化的数据。这款插件的名字是:JSONView。 之后,再访问接口时,就能看到更人性化的数据了:

优秀的个人博客,低调大师

KeePassXC 2.6.4 发布,全平台密码管理工具

KeePassXC是由 KeePass 密码管理器的一个分支发展而来的,相比原版 KeePass,KeePassXC 除了适配 Windows,还适配了 Linux 和 macOS。 通过KeePassXC可以存储和管理个人的敏感信息。保存在 KeePassXC 上的信息全部都会进行离线加密,借助于云存储服务可以实现跨平台同步。 KeePass 2.6.4 发布,本次更新内容如下: 新增 自动随系统明暗主题更改而切换(仅适用于 Windows/macOS) 更改 在系统托盘上显示窗口标题作为工具提示 将 Snap 以 LZO 压缩以加快初始启动速度 密码生成器:将最大可选密码长度设置为 999 修复 修复了使用 SSH 代理时将应用程序关闭引起的崩溃 修复了使用 Argon2id 时 KDF 选择显示错误项目的问题 如果“关于”对话框在数据库锁定时仍处于打开状态,则自动关闭该对话框。 Linux:修复了 AppImages 下开机自动启动的问题 Linux:修复了使用菜单时在空白区域上激活的点击移动 Linux:修复了系统托盘栏尚未准备好时,多次显示托盘图标的问题 macOS:修复 KeePassXC 阻止关闭的问题 更多内容请查看:https://keepassxc.org/blog/2021-01-31-2.6.4-released/

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册