2017年11月30日星期四

开源美图 2017 12 01


Linuxeden 开源社区 --

The post 开源美图 2017 12 01 appeared first on Linuxeden开源社区.

http://ift.tt/2BpyEuk

Android 全面屏如何做适配


Linuxeden 开源社区 --

作者 覃云

小编最近入手了一台小米 MIX 2,单看手机外表,觉得很惊艳,因为一眼望去,手机都是屏,但是使用过程却有一个小问题,让我很不舒服,就是由于有些应用没有和全面屏适配,导致在使用过程中屏幕上下方都有黑框,所以小编特地去搜集了一些资料以解决这个问题。

苹果今年发布的 iPhone X 比全面屏多了一个“刘海”,不过苹果有特别针对“刘海屏”给出了适配方案,详情请跳转阅读 iPhone X 交互设计官方指南 。但是与苹果统一生态不同的是,国内的安卓市场碎片化十分严重,这让 Android 软件开发工程师叫苦不迭。

什么是全面屏手机?

该怎么定义全面屏手机呢?小米最初也只是对其有一个抽象的定义「正面几乎全是屏幕,仿佛握着一块透明玻璃」,全面屏顾名思义就是一整面都是屏幕,理想中的全面屏就是达到 100%的屏占比,同时能够满足当前的日常需求,如摄像头,听筒、指纹解锁等。但随着 iPhone X 的出现,有越来越多的人都在争论“全面屏”,认为有刘海就谈不上无边框,甚至大家开始疑问全面屏的真正含义。

根据目前的技术水平和业内大部分人的说法,认为目前的全面屏手机要同时符合两个条件才能称为真正的全面屏:

  • 屏幕纵横比大于 16:9
  • 屏占比大于 80%

例如在业内率先提出全面屏概念并完全去掉机身正面半顶部边框设计的的小米 MIX,它的屏幕纵横比为 17:9,今年小米推出的 MIX 2 屏幕纵横比为 18:9。

从人体工程学角度分析,18:9 的比例更适合用户单手持握,更重要的是,全面屏的高屏占比可以给用户在游戏和视频观看上带来极致的视觉体验。然而,市面上很多厂商却因此偷换概念,认为手机配备 18:9 的比例屏幕就是全面屏,故在手机设计上只保留了 18:9 的比例,而边框依然宽大,这显然忽视了全面屏最本质的特征。

目前,业内较为认可的全面屏手机主要有以下几种:

机型 屏幕纵横比 屏占比 上市时间
LG G6 18:9 80% 2017 年 2 月
三星 S8 18.5:9 84.26% 2017 年 3 月
Essential Phone 19:10 84.85% 2017 年 8 月
小米 MIX 2 18:9 84.02% 2017 年 9 月
iPhone X 13:6 81.49% 2017 年 9 月

移动应用适配全面屏情况

手机全面屏带来的极致体验必须在应用和屏幕完全适配的情况下才可以充分发挥出来。而根据华为终端开放实验室对国内千款安卓主流应用进行的测试数据显示,目前仅约 17%的应用适配了全面屏,这意味着 83%的应用在全面屏手机运行时会出现黑边现象,这样用户就无法享受全面屏手机的带来的极致体验,其中在国内 TOP150 的应用中,有 44%已经适配全面屏,如下图所示。

全面屏适配方案

由于全面屏手机在追求更小的边框设计、更高的屏占比,这些变化导致了手机发生两种变化,即更大的屏幕纵横比和导航键变成了虚拟键,所以应从这两个方面进行适配。

声明 Maximum Aspect Ratio

随着大量的手机厂商将目光投向全面屏,为了顺应市场需求,谷歌向开发者提供了官方的 Android 全面屏适配指南。

(左)18.5:9 设备上的最大纵横比设置为 16:9 的应用程序
(右)18.5:9 设备上最大纵横比设置为 18.5:9 以上的应用程序

1. 在 AndroidManifest.xml 中可做如下配置:

<meta-dataandroid:name="android.max_aspect"android:value="ratio_float"/>

其中 ratio_float 为纵横比,官方建议设为 2.1 或更大,因为目前市场上出现的全面屏手机屏幕纵横比最大的为三星的 18.5:9=2.0556,但是如果以后要是出现纵横比更大的手机,设置值就要更大。

2. 若没有声明该属性,而且

android:resizeableActivity

也为 false 的话,则应用支持的应用的最大纵横比的默认值为 1.86,小于 2.0556,即无法支持全面屏,屏幕的上下就会留有黑框,如上图左。

怎样防止图片变形

当使用 layout 布局实现界面类 APP 时,容易出现图片被拉伸的情况,如打开淘宝的页面就会变成如下所示:

对于这种情况,解决的办法是:

  • 使用相对布局设计界面
  • 为对应的分辨率提供相应布局、图片等资源(drawable-xxhdpi-2016×1080、drawable-long 等)
  • 使用颜色填充布局、.9 图片填充背景

虚拟导航键设置

为了保证虚拟键和 App 的界面风格一致,应注意设置虚拟键颜色与主题协调,所以在进行虚拟键的设置时,要注意以下几点:

  1. 使用沉浸式虚拟键时,用原生标准方法设置虚拟按键的背景颜色;
  2. 在夜间模式和主题切换的时候,重新设置一下虚拟按键背景颜色;
  3. 看图界面使用全屏布局,并设置半透明虚拟按键背景。

具体操作如下:

根据金立 18:9 全面屏虚拟键的适配说明,具体的设置虚拟键背景色的方法有:

方法 1:在主题中添加以下设置项:

<item name="android:navigationBarColor"> 要设置的颜色值 </item>

方法 2:通过使用 Window 类的 setNavigationBarColor API 进行控制。

注意,要想设置虚拟按键背景色生效,必须要设置 FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS 并且不能设置 FLAG_TRANSLUCENT_NAVIGATION,即要先执行:

例如:

getWindow().setNavigationBarColor(Color.TRANSPARENT); //设为透明 
getWindow().setNavigationBarColor(Color.BLACK); //设为不透明 
getWindow().setNavigationBarColor(0x80000000); //设为半透明(Color 类中没有半透明的常量定义,同时暂不考虑修改框架代码,所以使用的具体数值)

修改虚拟键的样式

根据小米开发者中心给出的方案:

调用以下接口即可 window.setNavigationBarColor (int color)。在调用该接口时,还需要设置一些 flag,详见该接口的注释说明(即下文):

/**
* Sets the color of the navigation bar to {@param color}.
*
* For this to take effect,
* the window must be drawing the system bar backgrounds with
* {@link android.view.WindowManager.LayoutParams#FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS} and
* {@link android.view.WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION} must not be set.
*
* If {@param color} is not opaque, consider setting
* {@link android.view.View#SYSTEM_UI_FLAG_LAYOUT_STABLE} and
* {@link android.view.View#SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION}.
* <p>
* The transitionName for the view background will be "android:navigation:background".
* </p>
*/
public abstract void setNavigationBarColor(@ColorInt int color);

结语

根据今年苹果、华为、小米等手机厂商的一系列动作来看,全面屏手机将会成为未来几年的主流,所以,开发者应该以积极地态度应对这个趋势,为自己的应用做好全面屏适配,才能与时俱进,为用户提供更好地服务。

参考链接

谷歌官方全面屏适配指南

小米全面屏及虚拟键适配说明

金立全面屏底部虚拟按键适配

转自 http://ift.tt/2ita1Jw

PS: 一般简单的套路是中间是图片 上下 2 端使用纯色做自适应过度层

The post Android 全面屏如何做适配 appeared first on Linuxeden开源社区.

http://ift.tt/2Av1BYM

AI 与 Android 漏洞挖掘那些事儿


Linuxeden 开源社区 --

作者 覃云     

11 月 17 日,由阿里云主办的首届先知创新大会在京举行。来自量子技术、信息安全和人工智能等领域的技术专家齐聚一堂共同探讨中国原创安全技术,大会的初衷是希望成为中国原创安全技术的舞台,让安全研究者看到未来,让他们在安全技术上获得更多的创新和突破。更重要的是,为产业带来贡献助力解决社会问题是阿里一直以来对技术研究的坚持。

当前,最热门的技术非 AI 莫属,事实上,AI 已经在一些领域上展示了自身的应用潜力,在美国国防部高级研究计划局举办的“网络安全挑战赛”上,我们已经看到 AI 在网络安全上的应用,那么在移动端的安全方面,AI 可以发挥怎样的效力呢?蚂蚁金服巴斯光年安全实验室技术专家仲花和此彼就在本次先知创新大会上发表了《漏洞挖掘的工业时代尾声,Android 系统代码审计新思路与 AI 漏洞挖掘的结合》的主题演讲,介绍了一种批量挖掘 Android 系统漏洞的全新角度,关注被忽视的底层数据结构,以及通过代码审计发现 Android 系统中攻击面的方法,并展示相关实例。本文是对两位老师演讲后的专访整理。

受访嘉宾简介:

仲花 (温瀚翔),专注于 AOSP 漏洞挖掘与制作提权漏洞利用。发现并报告 CVE-2017-0418,CVE-2017-0665, CVE-2017-0681,CVE-2017-0737 等多个 Android 系统漏洞并获得 Google 致谢。现于蚂蚁金服巴斯光年安全实验室从事 Android 漏洞挖掘及利用相关研究。​

此彼 (吴潍浠) ,专注于研究 Android 安全。第一位 Google Android 安全奖金获得者。2016 年用自己发现的 Android 漏洞成功 root 当时 Google 官方搭载最新的 Android 系统的手机 Nexus 6 。曾从事 Android 恶意软件分析、反混淆、加密和漏洞挖掘利用等,现于蚂蚁金服巴斯光年安全实验室从事 Android 漏洞挖掘及利用相关研究。

Android 的漏洞有哪些?

仲花和此彼两位老师主要从 Android 漏洞的类型、高发点和触发途径为我们介绍了当前 Android 系统中的安全问题。

漏洞类型

Android 系统常规漏洞类型有内存拷贝不当导致的堆栈溢出、计数器溢出导致的整形溢出、越界的读和写、UAF、类型混淆、TOCTOU 等,还有一种是缺少权限检查,不过这种漏洞一般出现在 framworks 层的代码中,让我们比较容易地以高权限执行代码。

漏洞高发点

Android 系统漏洞的高发点一般在系统服务进程如 system_server 或 mediaserver 中;应用所依赖的一些 framework 层调用比如 WiFi 的 API 调用,跨平台的第三方库如 Skia,以及各种多媒体解码库,还有厂商的一些硬件相关的音视频编解码以及图形图像加速解决方案的支持库。

漏洞触发路径

触发路径主要有以下三种:

  1. 浏览器中的漏洞。这是最具有攻击性的,可以远程触发还可以造成代码执行;
  2. 文件解析漏洞。这种漏洞在 stagefright 后已经被 Android 系统的安全策略不断削弱,会造成影响但却不容易进行远程代码执行。
  3. 在手机本地的提权。应用程序通过与高权限的进行进行 Binder 通信,从而尝试以高权限进程的上下文执行代码。

AI 怎么进行漏洞挖掘?

AI 用于漏洞挖掘是基于遗传算法,遗传算法需要找到一个用例,能触发漏洞。首先,有一个用例的集合,变异函数就是先把一个或一个以上用例拿出来变异,放到适应函数里面进行运算,看这个新变异出来的用例是否是有价值的,如果有价值,就放到用例集合里面去,这是模拟生物进化的原理,通过变异和适应函数来筛选用例,即生物繁殖和适应环境。变异筛选逐渐把用例演化成能走入未走过的代码的用例,我们直接就相当于攻击者,就像军事演习一样,自己攻击自己的代码,模拟攻击者,攻击自己的软件,找出薄弱点即安全漏洞。

人工漏洞挖掘 vs AI 漏洞挖掘

传统的漏洞挖掘其实就是人盯着源代码看,通过反汇编别人编译已经完成的产品,分析运行原理,推算在哪种情况下可能会出现问题,然后试着去实践一下看看是否会真的产生问题,如果会,说明这有安全问题,从而达到发现漏洞的目的。

而 AI 是基于遗传算法、进化算法,它是根据程序内部的反馈运行的。如果发现当前用例促使程序内部在工作流程上有新的动作,从而推测新的动作可能会发生一些问题,那么我就重复进行这样的动作,并在这种动作的基础上稍加修改,其实就是自我尝试改进的过程。

由于 AI 在每秒中都会尝试成百上千次,并且可以快速地进行迭代,而人在跟踪代码执行的过程是很缓慢的,人为了弥补这样的不足,一般会通过类似符号类符号执行来猜测,必须进行高度抽象地猜测,就像下围棋一样,要在很高的层次上进行判断,是自我感觉的过程。而 AI 不一样,它可以把全部可能走入分支都尝试去走。再者,AI 可以全天候地工作,这是人无法做到的。

为何选 Android 而不是 iOS

虽然在苹果系统和 Android 系统上的漏洞挖掘大体上没有什么区别,但目前来看,在实践和适配的过程中,由于苹果有一些黑盒的程序,还是需要大量的人工参与的,而因为 Android 是开放的,而且文档很丰富,操作起来更方便。而且由于 Android 一直开源,文档也多,所以攻击 Android 的成本要比 iOS 低,所以大家都比较热衷于攻击 Android,Android 上的安全问题也就更加险峻,所以目前暂时选择在 Android 上用 AI 进行漏洞挖掘。

AI 漏洞挖掘与逃逸攻击

所有的攻击都是有场景的,逃逸攻击也不例外,逃逸攻击的场景一般指存在一个判别网络,逃逸攻击就是欺骗这个判别网络,让他识别成另一个东西。而漏洞挖掘是挖掘自己产品的漏洞,在这个场景中攻击者并没有参与来进来,也没有使用神经网络的判别,所以就没有逃逸攻击的问题。

AI 未来还能在安全领域做些什么?

机器漏洞挖掘还将在 PC 端和服务器上进行大规模训练。还有就是 Google 在手机上引入的 TensorFlow——手机上用的训练网络, 可能会产生新的安全问题,因为 AI 本身也是一个系统,它本身也会产生安全问题,就像上文提到的逃逸攻击那样。AI 经过大量训练之后,它内部会有训练出来的类似于算法的一个东西,然后可以通过生成对抗网络,训练出这个算法的逆算法去跟它进行对抗。

AI 为何受热捧?

目前的算力已经达到了一个瓶颈,摩尔定律已经可能不起作用了,过去,算力在疯狂地膨胀,代码可以随便写写,可以不注重效率的方式,但是现在很多问题已经无法用算力解决,只能通过人工智能的方式,像经验主义,向实际的解决方法逼近,在这种情况下去近似地解决一个问题,不可能是完美解决。

从国家的层面上来讲,现在人工智能已经成为了国家的战略,这是一个新的时代方向,是一个大趋势,大家都在投入。一个新的技术的投入会导致什么呢?这个技术的门槛会大大降低,为什么这么说呢?众所周知,现在很多框架都有了,直接调算法就行了,你只需要判断这个环境是否适用于这个算法,然后再调参数就 OK 了,所以说它的门槛已经被大大降低了。

从行业的角度来看,谷歌、微软和国内互联网巨头 BAT 起到了很好的带头作用,他们搭建了一些好的平台给一些创业型企业使用,不仅打开自己的知名度,也培养了大量的 AI 人才,在这一点上,我们国家的人才实力是有机会超越美国的。

传统开发人员应何去何从?

未来既懂传统技术又懂人工智能技术的开发人员将会很受市场欢迎,在现实中,我们需要专精于一个技术,但同时是我们还需要了解人工智能技术,因为了解人工智能的某些算法在将来可能会在你这个领域派上用场。

虽然很多人工智能技术会取代人类之前低效的工作,但是它毕竟还没有发展到超过人类智慧的程度,人类看事情的纬度会比机器多,我们知道这个东西什么时候该适用于什么经验,然后调到一个合适的点让机器去学习经验而不是完全地委派出去。所以机器还不能完全取代人,开发人员能做的就是保持一颗积极向上的心态,继续学习,跟紧时代的步伐,而不是过多地忧虑。

转自 http://ift.tt/2Ashn71

                   

The post AI 与 Android 漏洞挖掘那些事儿 appeared first on Linuxeden开源社区.

http://ift.tt/2ixhXJz

Kevin Webber:Java 的云迁移


Linuxeden 开源社区 --

作者 Srini Penchikala     ,译者 陈亮芬

Kevin Webber 在开始演讲的时候说,企业软件构建应用程序的形式比较散碎,不够系统,集成很复杂。传统的基础架构(Traditional infrastructures)具备主动/被动的粗糙故障转移(crude failover),支持在主动和被动系统之间复制复杂的状态。

在一个现代化项目中,架构师必须做出的最初几项决定(“第一英里(The First mile)”)是至关重要的。他不仅谈到了关键的架构决策,也提及了如何根据领域驱动设计(Domain-Driven Design)的原则来做出这些决策。为了定义所涉及的业务过程以及如何将这些过程转换为事件驱动(event-driven)系统, 事件风暴(Event storming) 将关键的利益相关者聚集到一个协作的环境中。团队应该关注在业务中已经发生的最有趣的事件。

在从遗留系统(legacy sysems)到反应系统(Reactive systems)的迁移中,其他一些诸如 防护层 (ACL) 和 Strangler 模式 的概念也同样有用。

洋葱架构(Onion architecture) 与领域驱动设计(Domain Driven Design)的概念非常吻合。该架构中的以下几个层可以帮助实现不同方面的需求。

  • 基础架构: 我们可以使用该层来实现诸如健康检查、跟踪和身份验证等交叉需求(cross-cutting requirements)。
  • API: 用于路由和数据验证
  • 域: 管理这个层中的有界上下文
  • 核心: 这就是我们管理聚合(Aggregates)的地方

Webber 讨论了云原生对于应用程序的意义。应用程序需要是容器包装的、动态管理的和面向微服务的。

Webber 还谈到了 微服务架构 ,他推荐道:团队首先应该从 整体模型 开始着手, 并使用微服务作为重构技术将系统分解成多个微服务。微服务模型不仅有助于分布式系统, 也有助于分布式团队。

很多团队专注于在服务级别上分解系统,但却在数据层保持耦合。在这样的架构中,任何数据模型都将影响多个服务。

在会议结束后,InfoQ 与 Kevin 进行了交谈,了解了有关将 Java 应用程序迁移到云基础架构上的更多详细信息。

Kevin 说到,一旦微服务有点对点的交互,那么在服务管理方面就会混乱。重要的是要记住, 如果一个微服务发生改变的时候影响了另一个,那么这种情况下它们就不算真正独立的微服务,两者应该整合为单一的服务。

微服务的构成可以利用 PubSub 模型来实现,PubSub 使用像 Kafka 之类的服务器, 先将事件发送到队列,再使用诸如 Cassandra 的 NoSQL 数据库将事件存储在事件日志存储(Event Log Store)中。

如果读者想要了解更多关于该话题的细节,可以在奥莱利(O’Reilly)中查阅 Webber 的 Mini 书《Migrating Java to the Cloud

查看英文原文:Kevin Webber on Migrating Java to the Cloud

转自 http://ift.tt/2ixhUxn

                       

The post Kevin Webber:Java 的云迁移 appeared first on Linuxeden开源社区.

http://ift.tt/2AshlvV

Kubernetes 1.8 改进安全性、稳定性和 Workloads API


Linuxeden 开源社区 --

作者 Unni Sathyarajan ,译者 大愚若智

Kubernetes 团队刚刚发布了 1.8 版 Kubernetes,新版在改进安全性的同时提供了更好的稳定性,并将 Workloads API 升级到了 Beta 版本。此外还对原本已经成熟的功能进行了更新,包括基于角色的访问控制(RBAC),为卷挂载选项提供支持允许特权提升 ,以及 对高级卷操作度量提供的支持

在合规方面, RBAC网络策略 是两个非常强大的功能,有助于帮助客户满足管控和安全方面的需求。集群管理员可以根据 Kubernetes API 资源 的作用范围,使用 RBAC 为用户和应用程序(服务帐户)定义不同级别的细化访问权限。网络策略可以在异构集群环境中针对不同 Pod 提供不同级别的隔离。

举例来说,如果只有一个应用程序服务器(源)连接到数据库服务器(目标),管理员可以定义两条策略,第一条应用于数据库 Pod,只允许在特定端口接受来自应用程序 Pod 的入站流量;第二条应用于应用程序 Pod,只允许将流量发送给数据库 Pod 的指定端口。这种策略可针对 名称空间CIDR 的范围生效。默认情况下,同一个 Kubernetes 集群内的所有 Pod(例如前端 Pod、后端 Pod、数据库 Pod、缓存 Pod 等)可以毫无限制地相互随意通信。

此外新版本还包括一些重要的 Beta 版功能,例如可通过 网络策略 对来自 Pod 的出站流量进行筛选,可以为 KubeletWorkloads API 配置自动进行的传输层安全(TLS)证书轮换 。Kubernetes 团队称,Workloads API“可以对现有工作负载向 Kubernetes 进行的迁移,以及以 Kubernetes 为原生目标的 云原生应用程序 开发提供所需的抽象和稳健的基础”。

Workloads API 包含 Daemon Sets(Pod 管理)、Replica Sets(管理 Pod 的跨节点复制)、Deployments(管理 Pod 的更新和复制集)、Stateful Sets(对数据库等有状态应用程序提供 Pod 管理)。例如 bootkube 项目就使用了 Workloads API。对于大数据工作负载,Workloads API 还为 Apache Stark 提供了 原生的 Kubernetes 支持

Kubernetes 社区对于 1.8 版本的发布表现的极为活跃,这是今年内的第三次发布,总共为 Kubernetes 增加了 40 个功能,这些功能(目前)来自 29 个特殊兴趣组(Special interest group,SIG) 以及 6 个工作组(Working group,WG)SIG 是一种很多贡献者为了让项目更完善,围绕共同目标和具体的主题做贡献的群体,WG 的成员则主要负责新概念的实现,以及协调于不同 SIG 的合作。

Kubernetes 目前的开发重心主要围绕可以进一步改善稳定性的功能,并非围绕全新的功能。目前功能的生命周期主要分为三个阶段:Alpha、Beta 和 Stable。Alpha 阶段主要面向处于初步阶段的功能,这些功能都是实验性的,并且可能在后续版本中取消。Beta 阶段更进一步,会针对各种功能收集反馈并进一步完善。处于 Stable 阶段的功能通常已经不太可能继续改动,已经可以准备好用于生产环境。

1.8 版约有 40 个新功能,其中 4 个处于 Stable 状态,16 个为 Beta 状态,其余均为 Alpha 状态。预计这些功能将在 1.9 版进入 Stable 状态:Workloads API、与 Prometheus 更完善的集成、自定义资源定义(CRD)、在资源管理方面更丰富的节点级改进,以及常规的 Bug 修复。

阅读英文原文Kubernetes 1.8 Improves Security, Stability and Workloads

转自 http://ift.tt/2kdShlR

The post Kubernetes 1.8 改进安全性、稳定性和 Workloads API appeared first on Linuxeden开源社区.

http://ift.tt/2Ash9Nd

值得在 2018 年尝试的 11 个 React 组件库


Linuxeden 开源社区 --

React 的普及似乎在不断增长,在 Stack overflow 2017 年最受欢迎的组件库中,React 处于领先地位:

React 的虚拟 DOM,声明性地描述用户界面和模拟界面状态的能力,以及相对较低的门槛,都使 React 成为构建 UI 很好的入门库。使用 React 的另一个重要原因是组件。组件让你把用户界面分成独立的,可重复使用的部分,并且将每个部分分开考虑。

以下推荐 11 个可考虑在后续应用中使用的优秀 React 组件库,其中有一些已经十分流行,也有一些是新出现的库。希望能对大家有所帮助。

1、React Material-UI

React Material-UI 是一组实现了 Google 的 Material Design 全新设计语言的 React 组件。在 GitHub 上有超过 3 万个 star ,可能是最受欢迎的 React 组件库,其 v1 版本即将发布。

2、React-Bootstrap

React-Bootstrap 是一个可重复使用的 React 组件库,也是最受欢迎的前端框架之一。目前同样是在为 1.0.0 版本而积极开发中。也正因此,在 1.0.0 正式发布之前,带来的弃用或重大更改可能会给使用之前的版本的开发者带来困恼。

3、React Toolbox

React Toolbox 也是一组实现 Google Material Design 规范的 React 组件。基于 ES6、Webpack 和 CSS 模块 (使用 SASS 编写) 构建。React Toolbox 很好的集成了 Webpack 工作流,非常容易定制也非常灵活。

4、React Belle

React Belle 是一套经过优化的 React 组件库,可以在移动设备和桌面设备上使用。 样式是高度可定制的,因此你可以配置所有组件的基本样式,也可以单独修改其中的每一个。 参考示例

5、React Grommet

React Grommet 号称企业应用最先进的 UX 框架,它提供丰富的用户分类组件,所有组件都简单易用,跨浏览器兼容,且支持主题自定义。

6、React Components by Khan Academy

这是 Khan Academy 构建的一些可重复使用的 React 组件的集合,带有内联 CSS 和注释。单个组件也可通过 Bit Scope 来安装。

7、Material Components Web

Material Components Web 是由 Google 的核心工程师和用户体验设计师团队开发,其组件使用可靠的开发工作流程来构建漂亮而实用的 Web 项目。它已取代被弃用的 react-mdl 。

8. Ant Design React

遵循 Ant Design 规范,React Ant Design 是一个开箱即用的高质量 React 组件,包含一系列的组件和 demo 。 它是用 TypeScript 编写的,具有完整的定义类型,并提供 NPM + webpack + dva 前端开发工作流程。

9、Semantic UI React

Semantic UI React 是 Semantic UI 的官方 React 集成。目前已被 Netflix 和亚马逊采用。

10、Onsen UI

结合 React 和 Onsen UI 框架,以最快的方式构建漂亮的高品质混合移动应用程序。这是一个值得考虑的有趣的库。

11、React Virtualized

这是一个可以高效地渲染大型列表和表格数据的 React 组件库,具有很少的依赖性,大多数都是由 NPM 自动管理。

整理自:medium.com

转自 http://ift.tt/2AjSuIb

The post 值得在 2018 年尝试的 11 个 React 组件库 appeared first on Linuxeden开源社区.

http://ift.tt/2iumVGV

抢先一步,Rust 构建版支持直接编译 WebAssembly


Linuxeden 开源社区 --
Rust

Infoworld 消息,如果有关注 Rust 的每日构建版,你会发现 Rust 已不再需要额外的工具可直接编译为 WebAssembly 可移植代码格式。该特性是通过一个将 WebAssembly 作为默认后端的下拉请求而添加的,目前尚未合并到正式版本中。

Mozilla 表示 Rust 每日构建版的 WebAssembly 编译功能是对现有的使用 Emscripten 工具进行 WebAssembly 支持的改进。

WebAssembly 源自 2015 年,是一种实验性的程序语言,提供二进制文件格式标准,使网页应用程序或多媒体可在浏览器的客户端执行;开发团队分别来自 Mozilla、Google、微软、苹果,也代表着四大浏览器── Firefox、Chrome、Microsoft Edge、Safari 共同投入开发。WebAssembly 的优点不少,由于字节码(Bytecode)较一般程序代码小许多倍,意谓着这项标准可节省移动设备的使用带宽,有助于改善网页加载速度,且字节码更适合浏览器读取。

转自 http://ift.tt/2BzUBrv

The post 抢先一步,Rust 构建版支持直接编译 WebAssembly appeared first on Linuxeden开源社区.

http://ift.tt/2ke1v1q

Fedora 25 将于今年 12 月 12 日 停止支持


Linuxeden 开源社区 --Fedora Linux
Fedora Linux

去年 11 月 22 日,Fedora 25 正式上线,是第一个将 Wayland 作为默认显示服务器的 Fedora 版本,全新的 Fedora Media Writer 也首次在 Fedora 25 中出现。时隔一年,Fedora 25 也到了和我们说再见的时候,该发行版本将于 12 月 12 日停止支持,之后将不再继续提供支持。

同之前很多 Fedora 版本一样,结束支持后,Fedora 25 发行版本的所有软件将不再接收安全、BUG 修复或者增强更新,也不会添加任何新的软件包。开发团队建议依然使用 Fedora 25 的用户在 2017 年 12 月 12 日 之前升级至 Fedora 27 或者 26 版本。

Fedora 有着固定的更新和支持周期,老的版本会支持到之后的第二个新版本发布后的一个月。 例如,Fedora 26 的更新会一直持续到 Fedora 28 发布后的一个月;在 Fedora 29 发布后的一个月内,Fedora  27 将继续得到支持。

转自 http://ift.tt/2BoNdy5

The post Fedora 25 将于今年 12 月 12 日 停止支持 appeared first on Linuxeden开源社区.

http://ift.tt/2j6hQlb

为减少崩溃,Chrome 将阻止第三方软件注入代码


Linuxeden 开源社区 --
Chrome

Chrome 开发团队昨日 发博 表示,为减少由第三方软件造成的 Chrome 崩溃,从 2018 年 7 月起,Chrome 68 将开始阻止第三方软件在 Windows 上向 Chrome 注入代码。

据悉,大约三分之二的 Windows 用户在他们的机器上有安装其他与 Chrome 交互的第三方应用,例如屏蔽或防病毒。在过去,这些软件需要在 Chrome 中注入代码才能正常运行,但这也造成了使用 Windows Chrome 浏览器的用户,遇到崩溃的可能性高出 15%。通过 Chrome 扩展程序和本地消息传递,这些软件现在可以在 Chrome 进程中运行代码。因此,2018 年 7 月的 Chrome 68 将开始阻止第三方软件在 Windows 上向 Chrome 注入代码。

计划将分三步逐渐推进:

  • 2018 年 4 月,Chrome 66 将在受到代码冲撞后向受影响的用户发出警告,提醒他们其他软件正在向 Chrome 注入代码并引导更新或删除该软件。

  • 2018 年 7 月,Chrome 68 将开始阻止第三方软件注入 Chrome 进程。如果此屏蔽功能导致 Chrome 启动失败,Chrome 会重新启动并暂时允许代码注入,但同时会显示一条警告,指导用户删除该软件。
  • 2019 年 1 月,Chrome 72 将彻底阻止代码注入,不再给选择的余地。

不过,开发团队也表示,虽然大多数将代码注入 Chrome 的软件都会受此影响,但也有一些例外, 比如 Microsoft 签名的代码,屏蔽拦截软件和 IME 软件。

转自 http://ift.tt/2zBVVsn

The post 为减少崩溃,Chrome 将阻止第三方软件注入代码 appeared first on Linuxeden开源社区.

http://ift.tt/2nk1bzh

CoffeeScript 1.12.8 发布,脚本语言


Linuxeden 开源社区 --CoffeeScript
CoffeeScript

CoffeeScript 1.12.8 发布了,CoffeeScript 这一门编程语言构建在 JavaScript 之上,其被编译成高效的 JavaScript,这样你就可以在 web 浏览器上运行它,或是通过诸如用于服务器端应用的 Node.js 一类的技术来使用它。编译过程通常都很简单,产生出来的 JavaScript 与许多的最佳做法都保持了一致。

该版本暂未提供更新内容,后续更新请关注 ChangeLog1.x 文档

下载地址:

转自 http://ift.tt/2Aw7GVf

The post CoffeeScript 1.12.8 发布,脚本语言 appeared first on Linuxeden开源社区.

http://ift.tt/2iuk1lJ

Element 1.4.12 发布,基于 Vue 2.0 的组件库


Linuxeden 开源社区 --Element
Element

Element 1.4.12 发布了,Element,是饿了么开源的一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的桌面端组件库。

主要更新内容如下:

  • 修复未指定 size 的 Select 输入框高度错误,#8460

下载地址:

转自 http://ift.tt/2is5PcK

The post Element 1.4.12 发布,基于 Vue 2.0 的组件库 appeared first on Linuxeden开源社区.

http://ift.tt/2AsULmN

Activiti 7-201711-EA 发布,工作流引擎


Linuxeden 开源社区 --

Activiti 7-201711-EA 发布了。Activiti 是一个业务流程管理 (BPM) 和工作流系统,适用于开发人员和系统管理员。其核心是超快速,稳定的 BPMN2 流程引擎。它易于与 Spring 集成使用。

该版本更新内容请关注 发布主页提交记录

下载地址:

转自 http://ift.tt/2iudMOM

The post Activiti 7-201711-EA 发布,工作流引擎 appeared first on Linuxeden开源社区.

http://ift.tt/2AuvMiX

Redis 4.0.4 发布,高性能的 key-value 数据库


Linuxeden 开源社区 --Redis
Redis

Redis 4.0.4 发布,Redis 是一个高性能的 key-value 数据库。Redis 的出现,很大程度补偿了 memcached 这类 keyvalue 存储的不足,在部分场合可以对关系数据库起到很好的补充作用。它提供了 Python,Ruby,Erlang,PHP 客户端,使用很方便。

主要更新内容如下:

  • 8449227f PSYNC2: Fix off by one buffer size in luaCreateFunction().
  • eeac1d35 PSYNC2: just store script bodies into RDB.
  • fb0441a8 PSYNC2: luaCreateFunction() should handle NULL client parameter.
  • 0429db3c PSYNC2: Save Lua scripts state into RDB file.
  • d06fbbdd Regression test: Slave restart with EVALSHA in backlog issue #4483.
  • ab3d3aca Prevent corruption of server.executable after DEBUG RESTART.
  • b7c7edf9 Be more verbose when DEBUG RESTART fails.

发布说明

下载地址:

转自 http://ift.tt/2is5mY2

The post Redis 4.0.4 发布,高性能的 key-value 数据库 appeared first on Linuxeden开源社区.

http://ift.tt/2AtlfES

Linux Kernel 4.14.3, 3.18.85, 4.4.103, 4.9.66 发布


Linuxeden 开源社区 --Linux Kernel
Linux Kernel

Linux Kernel 4.14.3, 3.18.85, 4.4.103, 4.9.66 发布了。主要更新内容如下:

Version: 4.14.3 (stable)
Released: 2017-11-30
Source: linux-4.14.3.tar.xz
PGP Signature: linux-4.14.3.tar.sign
Patch: full (incremental)
ChangeLog: ChangeLog-4.14.3
Version: 3.18.85 (EOL) (longterm)
Released: 2017-11-30
Source: linux-3.18.85.tar.xz
PGP Signature: linux-3.18.85.tar.sign
Patch: full (incremental)
ChangeLog: ChangeLog-3.18.85
Version: 4.4.103 (longterm)
Released: 2017-11-30
Source: linux-4.4.103.tar.xz
PGP Signature: linux-4.4.103.tar.sign
Patch: full (incremental)
ChangeLog: ChangeLog-4.4.103
Version: 4.9.66 (longterm)
Released: 2017-11-30
Source: linux-4.9.66.tar.xz
PGP Signature: linux-4.9.66.tar.sign
Patch: full (incremental)
ChangeLog: ChangeLog-4.9.66

转自 http://ift.tt/2BpsH0k

The post Linux Kernel 4.14.3, 3.18.85, 4.4.103, 4.9.66 发布 appeared first on Linuxeden开源社区.

http://ift.tt/2iueOKD

XWiki 9.10.1 发布,Java 编写的开源 wiki 和应用平台


Linuxeden 开源社区 --XWiki
XWiki

XWiki 9.10.1 发布了。XWiki 是一个用 Java 编写的开源 wiki 和应用平台。

主要更新内容如下:

  •  XWIKI-14874 Broken deleted attachment break the whole deleted attachments index
  • XWIKI-14872 Nullpointerexception when migrating deleted filesystem attachments in 9.10 on Windows
  • XWIKI-14871 Deleted attachments lost when upgrading to 9.10
  • XWIKI-14862 Retro compatibility on xwiki.store.attachment.recyclebin.hint=file does not work
  • XWIKI-14643 Missing page in breadcrumbs treeview when treeview is expanded

下载地址:

转自 http://ift.tt/2zD3UW4

The post XWiki 9.10.1 发布,Java 编写的开源 wiki 和应用平台 appeared first on Linuxeden开源社区.

http://ift.tt/2njUwVF