搜索[官方产品]结果-低调大师优秀个人博客

Apache Struts 中两年前的严重漏洞重现，官方发布补丁

Apache Software Foundation 发布了一个安全公告 S2-062，以解决 Struts 2.0.0 到 2.5.29 版本中存在的一个远程代码执行漏洞；攻击者可以利用此漏洞来控制受影响的系统。对此，美国网络安全和基础设施安全局 (CISA) 也发布公告敦促组织查看Apache 的公告，并尽快升级到最新的 Struts 2 补丁版本。该漏洞被跟踪为 CVE-2021-31805，是由于 2020 年 CVE-2020-17530 (S2-061) 的不完整修复造成的。也就是说，这一漏洞早在 2020 年就已存在且当时被认为已修复，但事实证明问题并未完全得到解决。在 2020 年，GitHub 的研究人员 Alvaro Munoz 和 Aeye 安全实验室的 Masato Anzai 报告了 Struts 2 版本 2.0.0 - 2.5.25 在某些情况下存在一个OGNL 注入漏洞，编号为CVE-2020-17530，在 CVSS 严重性方面获得了 9.8 分（满分 10 分）。 “如果开发者使用 %{...} 语法进行强制 OGNL 评估，标签的一些属性仍然可以执行双重评估。对不信任的用户输入使用强制 OGNL 评估可能导致远程代码执行和安全性能下降。” 对象图导航语言 (Object-Graph Navigation Language,OGNL)是一种开源的 Java 表达式语言，简化了 Java 语言中的表达式范围。它被集成在 Struts2 等框架中，作用是对数据进行访问；拥有类型转换、访问对象方法、操作集合对象等功能。尽管 Apache 在 Struts 2.5.26 中解决了 2020 年所报告的漏洞，但研究人员 Chris McCown 发现，所应用的修复方案并不完整。他向 Apache 报告称，“双重评估”问题仍然可以在 Struts 版本 2.5.26 及更高版本中重现。作为解决措施，Apache 方面建议开发人员避免基于不受信任的用户输入在标签属性中使用强制 OGNL 评估，和/或升级到 Struts2.5.30或更高版本，以检查表达式评估是否不会导致双重评估。并建议遵循安全指南以获得最佳实践。

2022-04-15

Spring 官方修复零日漏洞，推出 Spring Boot 2.6.6、2.5.12 等新版本

1.1 Spring 零日漏洞真的存在就在开发者越来越焦灼时，Spring.io 官方于 3 月 31 日晚间出面证实了这一漏洞的存在，并带来了解决方案。

2022-04-02

扬开源之帆，借官方认证考试之势，在NGINX领域脱颖而出

NGINX官方认证考试给你答案！ 2021年3月1日，NGINX官方授权认证考试中心正式成立并落户中国，旨在为广大NGINX爱好者提供全面、科学、严谨、高效的考核体系。

2021-05-14

Mozilla 将停用两个官方扩展，并于 2 月 19 日自动卸载

Mozilla 近日宣布，他们将在 Firefox 上停用 Voice Fill 和 Voice Beta 这两个扩展，并将于 2 月 19 日自动从用户的 Firefox 中卸载这些扩展。 Mozilla 在公告中解释到，这一决定是在该公司决定停用 Mozilla 音频服务器代理（Mozilla Speech Proxy Server）之后做出的。由于 Mozilla 音频服务器代理为上述两个扩展提供支持，因此在停用音频服务器代理之后，Mozilla 只能选择也停用这两个扩展。 Mozilla 音频服务器代理将于 2021 年 2 月 28 日停止使用。该服务也为 Voice Fill 和 Firefox Voice Beta 这两个扩展提供支持，这些扩展带来了用户与浏览器之间基于语音的交互功能。音频服务器代理还引入了 WebSpeech API，允许开发人员添加基于语音与 Web 内容进行互动的功能。这些扩展将随着音频服务器代理的停用一同停用。 Firefox Voice Fill 于 2017 年 7 月推出，Mozilla 当时将它作为一个试点项目来测试相关功能能否以扩展的形式实现，而无需直接内置在 Firefox 浏览器中。该项目的推出也为后续多个重要的功能打下了坚实的基础，例如 Firefox Containers、Min Vid 和追踪保护。 Firefox Voice Beta 于 2020 年 1 月推出，它为 Firefox 桌面版浏览器引入了语音控制功能的。该扩展允许用户使用语音的方式控制浏览器功能，例如使用语音进行搜索、控制媒体播放、打开特定网站或控制浏览器功能。 Mozilla没有透露为什么要停用 Mozilla 音频服务器代理。但较低的用户数量可能是其中一个因素，Voice Fill 推出近4年只拥有 5800 名用户，而 Voice Beta 也仅有 11600 名用户。公开源代码，用户数据将从 Mozilla 服务器中删除为了将此信息告诉更多的用户，Mozilla 很快还会为这两个扩展推出一次更新，更新之后扩展将会为用户自动推送即将停用的通知。而且在 2 月 19 日，这两个扩展还会从 Firefox 中自动卸载。不过，好消息是 Mozilla 已经在 GitHub 中公布了 Voice Fill 和 Voice Beta 的源代码，开发者们基于源代码可以开发出类似功能的扩展，带来相似的体验。之前曾安装并使用过这些扩展的用户也无需担心，Mozilla 承诺将从他们的服务器上删除所有用户数据，也不会将数据与第三方共享。

2021-02-02

RaspBerry Pi OS 2021-01-11 发布，树莓派的官方操作系统

从2015年起，树莓派基金会正式将其作为树莓派的官方操作系统。

2021-01-14

速率可达5G一万倍，6G官方解读来了

这不，官方解读来了。近日，中国移动研究院首席专家、6G项目负责人刘光毅博士就6G网络下的参数指标做出了解答，接下来，我们将对这一系列数值进行逐一解释。

2020-07-09

华为否认提交给 Linux 内核的不安全补丁 HKSP 来自官方

华为同时也表示，该项目代码从未在任何正式的华为产品中实际使用过：“这只是个人用于与开源社区 Openwall 进行技术讨论的演示代码。”

2020-05-14

Flink 又双叒叕被 Apache 官方提名

3 月 26 日，Apache 官方博客宣布其成立 21 周年，博客中对 Apache 之道、Apache 大型项目的应用以及 Apache 基金会里程碑事件进行了盘点。

2020-03-29

官方病毒？伊朗新冠防控APP遭谷歌商店“零证据”下架

作为全球新冠肺炎疫情最严重的国家之一，伊朗政府上周发布了AC19——一款为应对新冠肺炎全国疫情而紧急开发的一款手机APP，并通过专用网站、谷歌官方Play商店和其他第三方应用商店分发。

2020-03-11

SAP官方到底提供了免费的S4HANA试用版没有？

经常有朋友在微信公众号上给我留言，询问是否有免费的S/4HANA系统可以用。作为SAP员工，我能给的答复就是这篇SAP社区的博客： SAP S/4HANA Fully-Activated Appliance: Create your SAP S/4HANA system in a fraction of the usual setup time https://blogs.sap.com/2018/12/12/sap-s4hana-fully-activated-appliance-create-your-sap-s4hana-1809-system-in-a-fraction-of-the-usual-setup-time/ 博客标题里提到的Appliance是什么意思？ The appliance is a compressed system image that contains an SAP S/4HANA system with pre-configured SAP Best Practices and demo scenarios. 一个压缩之后的系统镜像，包含预先配置好了SAP最佳实践和演示场景的S/4HANA系统。对于看过《异形》系列的朋友们来说，可以把S/4HANA appliance类比成异形的蛋(学名叫Ovomorph). 在《异形》系列影片里，有不止一位生物科学家赞叹过异形，惊叹于这种生命物种的纯粹和超高的攻击和防御力。科学家们认为异形是一种完美的生物。而通过S/4HANA appliance孵化出的S/4HANA系统，具有最纯正的蓝色软件巨人的血统，作为SAP R/3之后的下一代商务套件，在内存计算，物联网，人工智能，大数据实现的人、设备和业务网络的实时互联等方面都有突出进展，是客户在数字化时代加速实现企业卓越运营的完美助手。该Appliance可以通过SAP CAL(Cloud Appliance Library), 在一到两个小时之内部署到AWS, Azure或者Google Cloud Platform上，孵化出可用的S/4HANA系统。当然，On-Premises的孵化方式也仍旧支持，部署到客户本地的物理服务器上，需要花费两到三天。通过appliance孵化出的S/4HANA系统，只能用于测试，原型验证和开发等，不能用于正式的生产用途。使用这个链接开始试用： https://www.sap.com/registration/trial.b29aeae9-94b4-4e44-8d7e-fe3acbaab116.html 点击Start your 30-day trial之后，在弹出的窗口里维护注册必需的字段：该appliance可以免费试用30天。注册成功后会收到一封邮件，里面包含了能够操作申请的用于测试用途的S/4HANA appliance的CAL url. 登录之后，从Cloud Provider下拉列表里选择AWS，GCP或者Azure，然后就可以在这些云平台上把S/4HANA appliance孵化成可用的S/4HANA系统。这也就是SAP如今在很多云服务使用场景里都提到的BYOL概念 - Bring Your Own License. 回到本文的上下文，S/4HANA trial appliance本身是30天免费使用的，但因为孵化后的S/4HANA系统是运行在AWS, Azure或者GCP上，因此使用者需要事先在这三个云服务平台之一上面拥有帐号，且需要按照实际使用情况，向AWS，Azure或GCP支付使用费用。包括之前Jerry文章介绍的SAP Cloud Platform Extension Factory的计费方式，也是按照BYOL进行的。将这三大云平台上帐号的明细维护到CAL里，点击Create即可创建实例。可以使用Calculate Cost按钮，选择不同的硬件资源，然后查看预估的使用费用：以AWS为例，最低配的价格每小时2.69美元。各位，想试试吗？ (题图：从蛋里孵化出来，集合了众多龙珠战士细胞的超强BOSS：沙鲁）本文来自云栖社区合作伙伴“汪子熙”，了解相关信息可以关注微信公众号"汪子熙"。

2020-01-17

iPhone 11官方维修费正式出炉，你那颤抖的小手还好吧？

就在发布新机不久后，苹果官方如愿地公布了维修iPhone11系列的价格，看完这些价格之后，你那本来就颤抖的小手，如今还好吗?

2019-10-18

阿里云服务器购买配置选择，官方推荐配置及价格表

阿里云服务器购买的时候，如何选择配置是很多用户犯难的地方，特别是新用户，由于以前没买过，不知道买什么样的配置合适，配置买高了，浪费了资源和金钱，买低了又无法满足自己的应用运行需求，其实阿里云官方已经根据大部分用的的上云需求场景推荐了对应的配置

2019-08-13

云原生周报：Google 官方云原生架构的五大原则

这是仓库里包含的所有扩展： Kubernetes Standardized Glossary : 这是 Kubernetes 官方文档新出的标准术语表，对每种资源类型和组件都有标准化的解释。

2019-07-13

为什么Android官方废弃SoftRefrerence软引用和WeakReference弱引用，而拥抱LruCache？

2018-06-08

《JDK10新特性官方文档》从JDK10中移除javah工具

而且正如javah命令的用户被推荐使用javac -h一样，javah的一些衍生产品，比如Ant javah，使用这些任务依赖关系的用户，也被推荐使用javac提供相应的支持。

2018-05-21

Tensorflow官方语音识别入门教程 | 附Google新语音指令数据集

本文来自AI新媒体量子位（QbitAI） Google今天推出了一个语音指令数据集，其中包含30个词的65000条语音，wav格式，每条长度为一秒钟。这30个词都是英文的，基本是yes、no、up、down、stop、go这类。这个数据集由Google TensorFlow团队和AIY团队共同推出的，AIY就是之前推出树莓派DIY智能音箱的那个团队：所以说，也别指望用这个数据集训练模型然后做个App什么的，它其实和那个DIY的音箱差不多，主要供初学者/爱好者练手用。语音识别教程 Google还配合这个数据集，推出了一份TensorFlow教程，教你训练一个简单的语音识别网络，能识别10个词，就像是语音识别领域的MNIST（手写数字识别数据集）。虽然这份教程和数据集都比真实场景简化了太多，但能帮用户建立起对语音识别技术的基本理解，很适合

2018-01-15

Android官方ORM数据库Room技术解决方案：@Embedded内嵌对象（二）

Android官方ORM数据库Room技术解决方案：@Embedded内嵌对象（二）（一）附录1简介了Android Room的基本使用。

2017-11-23

android app性能优化大汇总（google官方Android性能优化典范 - 第1季）

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。从设计师的角度，他们希望App能够有更多的动画，图片等时尚元素来实现流畅的用户体验。但是Android系统很有可能无法及时完成那些复杂的界面渲染操作。Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。如果你的某个操作花费时间是24ms，系统在得到VSYNC信号的时候就无法进行正常渲染，这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面。用户容易在UI执行动画或者滑动ListView的时候感知到卡顿不流畅，是因为这里的操作相对复杂，容易发生丢帧的现象，从而感觉卡顿。有很多原因可以导致丢帧，也许是因为你的layout太过复杂，无法在16ms内完成渲染，有可能是因为你的UI上有层叠太多的绘制单元，还有可能是因为动画执行的次数过多。这些都会导致CPU或者GPU负载过重。我们可以通过一些工具来定位问题，比如可以使用HierarchyViewer来查找Activity中的布局是否过于复杂，也可以使用手机设置里面的开发者选项，打开Show GPU Overdraw等选项进行观察。你还可以使用TraceView来观察CPU的执行情况，更加快捷的找到性能瓶颈。（a）Understanding Overdraw Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源。当设计上追求更华丽的视觉效果的时候，我们就容易陷入采用越来越多的层叠组件来实现这种视觉效果的怪圈。这很容易导致大量的性能问题，为了获得最佳的性能，我们必须尽量减少Overdraw的情况发生。幸运的是，我们可以通过手机设置里面的开发者选项，打开Show GPU Overdraw的选项，可以观察UI上的Overdraw情况。蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。 Overdraw有时候是因为你的UI布局存在大量重叠的部分，还有的时候是因为非必须的重叠背景。例如某个Activity有一个背景，然后里面的Layout又有自己的背景，同时子View又分别有自己的背景。仅仅是通过移除非必须的背景图片，这就能够减少大量的红色Overdraw区域，增加蓝色区域的占比。这一措施能够显著提升程序性能。（b）Understanding VSYNC 为了理解App是如何进行渲染的，我们必须了解手机硬件是如何工作，那么就必须理解什么是VSYNC。在讲解VSYNC之前，我们需要了解两个相关的概念： Refresh Rate：代表了屏幕在一秒内刷新屏幕的次数，这取决于硬件的固定参数，例如60Hz。 Frame Rate：代表了GPU在一秒内绘制操作的帧数，例如30fps，60fps。 GPU会获取图形数据进行渲染，然后硬件负责把渲染后的内容呈现到屏幕上，他们两者不停的进行协作。不幸的是，刷新频率和帧率并不是总能够保持相同的节奏。如果发生帧率与刷新频率不一致的情况，就会容易出现Tearing的现象(画面上下两部分显示内容发生断裂，来自不同的两帧数据发生重叠)。理解图像渲染里面的双重与三重缓存机制，这个概念比较复杂，请移步查看这里：http://source.android.com/devices/graphics/index.html，还有这里http://article.yeeyan.org/view/37503/304664。通常来说，帧率超过刷新频率只是一种理想的状况，在超过60fps的情况下，GPU所产生的帧数据会因为等待VSYNC的刷新信息而被Hold住，这样能够保持每次刷新都有实际的新的数据可以显示。但是我们遇到更多的情况是帧率小于刷新频率。在这种情况下，某些帧显示的画面内容就会与上一帧的画面相同。糟糕的事情是，帧率从超过60fps突然掉到60fps以下，这样就会发生LAG，JANK，HITCHING等卡顿掉帧的不顺滑的情况。这也是用户感受不好的原因所在。（c）Tool:Profile GPU Rendering 性能问题如此的麻烦，幸好我们可以有工具来进行调试。打开手机里面的开发者选项，选择Profile GPU Rendering，选中On screen as bars的选项。选择了这样以后，我们可以在手机画面上看到丰富的GPU绘制图形信息，分别关于StatusBar，NavBar，激活的程序Activity区域的GPU Rending信息。随着界面的刷新，界面上会滚动显示垂直的柱状图来表示每帧画面所需要渲染的时间，柱状图越高表示花费的渲染时间越长。中间有一根绿色的横线，代表16ms，我们需要确保每一帧花费的总时间都低于这条横线，这样才能够避免出现卡顿的问题。每一条柱状线都包含三部分，蓝色代表测量绘制Display List的时间，红色代表OpenGL渲染Display List所需要的时间，×××代表CPU等待GPU处理的时间。（d）Why 60fps? 我们通常都会提到60fps与16ms，可是知道为何会是以程序是否达到60fps来作为App性能的衡量标准吗？这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。 12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。但是低于30fps是无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，当然超过60fps是没有必要的。开发app的性能目标就是保持60fps，这意味着每一帧你只有16ms=1000/60的时间来处理所有的任务。（e）Android, UI and the GPU 了解Android是如何利用GPU进行画面渲染有助于我们更好的理解性能问题。那么一个最实际的问题是：activity的画面是如何绘制到屏幕上的？那些复杂的XML布局文件又是如何能够被识别并绘制出来的？ Resterization栅格化是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操作。它把那些组件拆分到不同的像素上进行显示。这是一个很费时的操作，GPU的引入就是为了加快栅格化的操作。 CPU负责把UI组件计算成Polygons，Texture纹理，然后交给GPU进行栅格化渲染。然而每次从CPU转移到GPU是一件很麻烦的事情，所幸的是OpenGL ES可以把那些需要渲染的纹理Hold在GPU Memory里面，在下次需要渲染的时候直接进行操作。所以如果你更新了GPU所hold住的纹理内容，那么之前保存的状态就丢失了。在Android里面那些由主题所提供的资源，例如Bitmaps，Drawables都是一起打包到统一的Texture纹理当中，然后再传递到GPU里面，这意味着每次你需要使用这些资源的时候，都是直接从纹理里面进行获取渲染的。当然随着UI组件的越来越丰富，有了更多演变的形态。例如显示图片的时候，需要先经过CPU的计算加载到内存中，然后传递给GPU进行渲染。文字的显示更加复杂，需要先经过CPU换算成纹理，然后再交给GPU进行渲染，回到CPU绘制单个字符的时候，再重新引用经过GPU渲染的内容。动画则是一个更加复杂的操作流程。为了能够使得App流畅，我们需要在每一帧16ms以内处理完所有的CPU与GPU计算，绘制，渲染等等操作。（f）Invalidations, Layouts, and Performance 顺滑精妙的动画是app设计里面最重要的元素之一，这些动画能够显著提升用户体验。下面会讲解Android系统是如何处理UI组件的更新操作的。通常来说，Android需要把XML布局文件转换成GPU能够识别并绘制的对象。这个操作是在DisplayList的帮助下完成的。DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。在某个View第一次需要被渲染时，DisplayList会因此而被创建，当这个View要显示到屏幕上时，我们会执行GPU的绘制指令来进行渲染。如果你在后续有执行类似移动这个View的位置等操作而需要再次渲染这个View时，我们就仅仅需要额外操作一次渲染指令就够了。然而如果你修改了View中的某些可见组件，那么之前的DisplayList就无法继续使用了，我们需要回头重新创建一个DisplayList并且重新执行渲染指令并更新到屏幕上。需要注意的是：任何时候View中的绘制内容发生变化时，都会重新执行创建DisplayList，渲染DisplayList，更新到屏幕上等一系列操作。这个流程的表现性能取决于你的View的复杂程度，View的状态变化以及渲染管道的执行性能。举个例子，假设某个Button的大小需要增大到目前的两倍，在增大Button大小之前，需要通过父View重新计算并摆放其他子View的位置。修改View的大小会触发整个HierarcyView的重新计算大小的操作。如果是修改View的位置则会触发HierarchView重新计算其他View的位置。如果布局很复杂，这就会很容易导致严重的性能问题。我们需要尽量减少Overdraw。我们可以通过前面介绍的Monitor GPU Rendering来查看渲染的表现性能如何，另外也可以通过开发者选项里面的Show GPU view updates来查看视图更新的操作，最后我们还可以通过HierarchyViewer这个工具来查看布局，使得布局尽量扁平化，移除非必需的UI组件，这些操作能够减少Measure，Layout的计算时间。（g）Overdraw, Cliprect, QuickReject 引起性能问题的一个很重要的方面是因为过多复杂的绘制操作。我们可以通过工具来检测并修复标准UI组件的Overdraw问题，但是针对高度自定义的UI组件则显得有些力不从心。有一个窍门是我们可以通过执行几个APIs方法来显著提升绘制操作的性能。前面有提到过，非可见的UI组件进行绘制更新会导致Overdraw。例如Nav Drawer从前置可见的Activity滑出之后，如果还继续绘制那些在Nav Drawer里面不可见的UI组件，这就导致了Overdraw。为了解决这个问题，Android系统会通过避免绘制那些完全不可见的组件来尽量减少Overdraw。那些Nav Drawer里面不可见的View就不会被执行浪费资源。但是不幸的是，对于那些过于复杂的自定义的View(重写了onDraw方法)，Android系统无法检测具体在onDraw里面会执行什么操作，系统无法监控并自动优化，也就无法避免Overdraw了。但是我们可以通过canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。同时clipRect方法还可以帮助节约CPU与GPU资源，在clipRect区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。除了clipRect方法之外，我们还可以使用canvas.quickreject()来判断是否没和某个矩形相交，从而跳过那些非矩形区域内的绘制操作。做了那些优化之后，我们可以通过上面介绍的Show GPU Overdraw来查看效果。（h）Memory Churn and performance 虽然Android有自动管理内存的机制，但是对内存的不恰当使用仍然容易引起严重的性能问题。在同一帧里面创建过多的对象是件需要特别引起注意的事情。 Android系统里面有一个Generational Heap Memory的模型，系统会根据内存中不同的内存数据类型分别执行不同的GC操作。例如，最近刚分配的对象会放在Young Generation区域，这个区域的对象通常都是会快速被创建并且很快被销毁回收的，同时这个区域的GC操作速度也是比Old Generation区域的GC操作速度更快的。除了速度差异之外，执行GC操作的时候，所有线程的任何操作都会需要暂停，等待GC操作完成之后，其他操作才能够继续运行。通常来说，单个的GC并不会占用太多时间，但是大量不停的GC操作则会显著占用帧间隔时间(16ms)。如果在帧间隔时间里面做了过多的GC操作，那么自然其他类似计算，渲染等操作的可用时间就变得少了。导致GC频繁执行有两个原因： Memory Churn内存抖动，内存抖动是因为大量的对象被创建又在短时间内马上被释放。瞬间产生大量的对象会严重占用Young Generation的内存区域，当达到阀值，剩余空间不够的时候，也会触发GC。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力，从而触发更多其他类型的GC。这个操作有可能会影响到帧率，并使得用户感知到性能问题。解决上面的问题有简洁直观方法，如果你在Memory Monitor里面查看到短时间发生了多次内存的涨跌，这意味着很有可能发生了内存抖动。同时我们还可以通过Allocation Tracker来查看在短时间内，同一个栈中不断进出的相同对象。这是内存抖动的典型信号之一。当你大致定位问题之后，接下去的问题修复也就显得相对直接简单了。例如，你需要避免在for循环里面分配对象占用内存，需要尝试把对象的创建移到循环体之外，自定义View中的onDraw方法也需要引起注意，每次屏幕发生绘制以及动画执行过程中，onDraw方法都会被调用到，避免在onDraw方法里面执行复杂的操作，避免创建对象。对于那些无法避免需要创建对象的情况，我们可以考虑对象池模型，通过对象池来解决频繁创建与销毁的问题，但是这里需要注意结束使用之后，需要手动释放对象池中的对象。（i）Garbage Collection in Android JVM的回收机制给开发人员带来很大的好处，不用时刻处理对象的分配与回收，可以更加专注于更加高级的代码实现。相比起Java，C与C++等语言具备更高的执行效率，他们需要开发人员自己关注对象的分配与回收，但是在一个庞大的系统当中，还是免不了经常发生部分对象忘记回收的情况，这就是内存泄漏。原始JVM中的GC机制在Android中得到了很大程度上的优化。Android里面是一个三级Generation的内存模型，最近分配的对象会存放在Young Generation区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到Old Generation，最后到Permanent Generation区域。每一个级别的内存区域都有固定的大小，此后不断有新的对象被分配到此区域，当这些对象总的大小快达到这一级别内存区域的阀值时，会触发GC的操作，以便腾出空间来存放其他新的对象。前面提到过每次GC发生的时候，所有的线程都是暂停状态的。GC所占用的时间和它是哪一个Generation也有关系，Young Generation的每次GC操作时间是最短的，Old Generation其次，Permanent Generation最长。执行时间的长短也和当前Generation中的对象数量有关，遍历查找20000个对象比起遍历50个对象自然是要慢很多的。虽然Google的工程师在尽量缩短每次GC所花费的时间，但是特别注意GC引起的性能问题还是很有必要。如果不小心在最小的for循环单元里面执行了创建对象的操作，这将很容易引起GC并导致性能问题。通过Memory Monitor我们可以查看到内存的占用情况，每一次瞬间的内存降低都是因为此时发生了GC操作，如果在短时间内发生大量的内存上涨与降低的事件，这说明很有可能这里有性能问题。我们还可以通过Heap and Allocation Tracker工具来查看此时内存中分配的到底有哪些对象。（j）Performance Cost of Memory Leaks 虽然Java有自动回收的机制，可是这不意味着Java中不存在内存泄漏的问题，而内存泄漏会很容易导致严重的性能问题。内存泄漏指的是那些程序不再使用的对象无法被GC识别，这样就导致这个对象一直留在内存当中，占用了宝贵的内存空间。显然，这还使得每级Generation的内存区域可用空间变小，GC就会更容易被触发，从而引起性能问题。寻找内存泄漏并修复这个漏洞是件很棘手的事情，你需要对执行的代码很熟悉，清楚的知道在特定环境下是如何运行的，然后仔细排查。例如，你想知道程序中的某个activity退出的时候，它之前所占用的内存是否有完整的释放干净了？首先你需要在activity处于前台的时候使用Heap Tool获取一份当前状态的内存快照，然后你需要创建一个几乎不这么占用内存的空白activity用来给前一个Activity进行跳转，其次在跳转到这个空白的activity的时候主动调用System.gc()方法来确保触发一个GC操作。最后，如果前面这个activity的内存都有全部正确释放，那么在空白activity被启动之后的内存快照中应该不会有前面那个activity中的任何对象了。如果你发现在空白activity的内存快照中有一些可疑的没有被释放的对象存在，那么接下去就应该使用Alocation Track Tool来仔细查找具体的可疑对象。我们可以从空白activity开始监听，启动到观察activity，然后再回到空白activity结束监听。这样操作以后，我们可以仔细观察那些对象，找出内存泄漏的真凶。（k）Memory Performance 通常来说，Android对GC做了大量的优化操作，虽然执行GC操作的时候会暂停其他任务，可是大多数情况下，GC操作还是相对很安静并且高效的。但是如果我们对内存的使用不恰当，导致GC频繁执行，这样就会引起不小的性能问题。为了寻找内存的性能问题，Android Studio提供了工具来帮助开发者。 Memory Monitor：查看整个app所占用的内存，以及发生GC的时刻，短时间内发生大量的GC操作是一个危险的信号。 Allocation Tracker：使用此工具来追踪内存的分配，前面有提到过。 Heap Tool：查看当前内存快照，便于对比分析哪些对象有可能是泄漏了的，请参考前面的Case。（l）Tool - Memory Monitor Android Studio中的Memory Monitor可以很好的帮助我们查看程序的内存使用情况。（m）Battery Performance 电量其实是目前手持设备最宝贵的资源之一，大多数设备都需要不断的充电来维持继续使用。不幸的是，对于开发者来说，电量优化是他们最后才会考虑的的事情。但是可以确定的是，千万不能让你的应用成为消耗电量的大户。 Purdue University研究了最受欢迎的一些应用的电量消耗，平均只有30%左右的电量是被程序最核心的方法例如绘制图片，摆放布局等等所使用掉的，剩下的70%左右的电量是被上报数据，检查位置信息，定时检索后台广告信息所使用掉的。如何平衡这两者的电量消耗，就显得非常重要了。有下面一些措施能够显著减少电量的消耗：我们应该尽量减少唤醒屏幕的次数与持续的时间，使用WakeLock来处理唤醒的问题，能够正确执行唤醒操作并根据设定及时关闭操作进入睡眠状态。某些非必须马上执行的操作，例如上传歌曲，图片处理等，可以等到设备处于充电状态或者电量充足的时候才进行。触发网络请求的操作，每次都会保持无线信号持续一段时间，我们可以把零散的网络请求打包进行一次操作，避免过多的无线信号引起的电量消耗。关于网络请求引起无线信号的电量消耗，还可以参考这里http://hukai.me/android-training-course-in-chinese/connectivity/efficient-downloads/efficient-network-access.html 我们可以通过手机设置选项找到对应App的电量消耗统计数据。我们还可以通过Battery Historian Tool来查看详细的电量消耗。如果发现我们的App有电量消耗过多的问题，我们可以使用JobScheduler API来对一些任务进行定时处理，例如我们可以把那些任务重的操作等到手机处于充电状态，或者是连接到WiFi的时候来处理。关于JobScheduler的更多知识可以参考http://hukai.me/android-training-course-in-chinese/background-jobs/scheduling/index.html （n）Understanding Battery Drain on Android 高效的保留更多的电量与不断促使用户使用你的App会消耗电量，这是矛盾的选择题。不过我们可以使用一些更好的办法来平衡两者。假设你的手机里面装了大量的社交类应用，即使手机处于待机状态，也会经常被这些应用唤醒用来检查同步新的数据信息。Android会不断关闭各种硬件来延长手机的待机时间，首先屏幕会逐渐变暗直至关闭，然后CPU进入睡眠，这一切操作都是为了节约宝贵的电量资源。但是即使在这种睡眠状态下，大多数应用还是会尝试进行工作，他们将不断的唤醒手机。一个最简单的唤醒手机的方法是使用PowerManager.WakeLock的API来保持CPU工作并防止屏幕变暗关闭。这使得手机可以被唤醒，执行工作，然后回到睡眠状态。知道如何获取WakeLock是简单的，可是及时释放WakeLock也是非常重要的，不恰当的使用WakeLock会导致严重错误。例如网络请求的数据返回时间不确定，导致本来只需要10s的事情一直等待了1个小时，这样会使得电量白白浪费了。这也是为何使用带超时参数的wakelock.acquice()方法是很关键的。但是仅仅设置超时并不足够解决问题，例如设置多长的超时比较合适？什么时候进行重试等等？解决上面的问题，正确的方式可能是使用非精准定时器。通常情况下，我们会设定一个时间进行某个操作，但是动态修改这个时间也许会更好。例如，如果有另外一个程序需要比你设定的时间晚5分钟唤醒，最好能够等到那个时候，两个任务捆绑一起同时进行，这就是非精确定时器的核心工作原理。我们可以定制计划的任务，可是系统如果检测到一个更好的时间，它可以推迟你的任务，以节省电量消耗。这正是JobScheduler API所做的事情。它会根据当前的情况与任务，组合出理想的唤醒时间，例如等到正在充电或者连接到WiFi的时候，或者集中任务一起执行。我们可以通过这个API实现很多免费的调度算法。从Android 5.0开始发布了Battery History Tool，它可以查看程序被唤醒的频率，又谁唤醒的，持续了多长的时间，这些信息都可以获取到。请关注程序的电量消耗，用户可以通过手机的设置选项观察到那些耗电量大户，并可能决定卸载他们。所以尽量减少程序的电量消耗是非常有必要的。 http://www.cnblogs.com/yezhennan/p/5431738.html 本文转自知止内明 51CTO博客，原文链接：http://blog.51cto.com/357712148/2046041，如需转载请自行联系原作者

2017-11-16

下载Google官方/CM Android源代码自动重新开始的Shell脚本

国内由于某种原因，下载CM或Google官方的Android源代码总容易中断。总看着机器，一中断就重新执行repo sync还太麻烦，所以我特意编写了一段shell脚本（download.sh）。

2017-11-14

APP设计尺寸规范大全，APP界面设计新手教程【官方版】(转)

详细阅读扩展：苹果iphone APP界面设计尺寸官方版http://www.25xt.com/647.html Ipad 和Iphone APPUI设计尺寸和参考手册http://www.25xt.com

2017-11-13

精选列表