上次买书，加了一本《阅微草堂笔记》凑单，此书为纪昀晚年所作的笔记小说集，其实都是篇幅极其短小的随笔杂记。

每脱稿一卷，即被亲朋好友竞相传抄刻印，在上层社会广为流传，一时竟享有同曹雪芹的《红楼梦》、蒲松龄的《聊斋志异》并行海内的盛誉

对于此话，个人觉得有点夸张了，当然我水平不高就不多加评论。此文章主要为摘录阅读之时有所感触的的篇章，以飨读者。

请保持淡定，分析代码，记住：性能很重要。

人是一种视觉动物，如果你的应用长得不美，下场自不必多说，但这可是 UI 设计师的专属工作呀。作为工程师，对于视觉的体验上自然是从 UI 的性能优化入手了，从启动速度到应用 UI 优化，都是工程师讨好用户的手段。本文作为一份优化指南将帮助你优化你的应用的渲染性能，主要从两个方面入手：减少过度绘制，优化视图层级，内容包括了问题原因的阐述、问题的检测以及问题的解决方案。

减少过度绘制

过度绘制（Overdraw）是指应用在渲染一帧的时间内对屏幕某个像素进行多次绘制。应用应该尽可能避免过度绘制，因为让 GPU 去绘制用户不可见的内容完全是一种浪费。

大家都知道监听 Dialog 消失事件常常是要重写 onDismiss() 或者 onCancle() 方法，有时候为了让 Dialog 主动消失，我们会调用 Dialog 的 dismiss() 和 cancle() 方法。而一个 Dialog 的消失有三种方式可以设置：

1. 默认的 Cancel 按键：builder.setNegativeButton(android.R.string.cancel, null);
2. 设置点击外面退出：builder.create().setCanceledOnTouchOutside(true);
3. 点击 Back 键

但是这三种方法是怎样让 Dialog 消失的？这个问题的答案通过查看相关源码来一探究竟。

安装双系统时，给 /boot 文件目录分配 100M 空间，其实 /boot 可以单独分成一个区，也可以不单独分，不单独分会在 / 下自动创建一个 boot 文件夹。

/boot 目录中是系统引导文件和内核，100M 的空间是足够的，但是由于更新内核之后旧内核还存放在里面，安装软件的时候就会提示 /boot 空间不足，这时最佳解决办法就是将不用的旧内核删除。

Tasks(Tasks)与返回栈(Back Stack)

Tasks 的定义：执行特定作业时与用户交互的一系列 Activity。这些 Activity 按照各自的打开顺序排列在堆栈（即返回栈）中，堆栈顶部 Activity 即为可见的界面。堆栈中的 Activity 永远不会 重新排列，仅推入（push）和弹出（pop）堆栈：由当前 Activity 启动时推入堆栈；用户使用 Back 按钮退出时弹出堆栈。当所有 Activity 均从堆栈中移除后，Tasks 即不复存在。

举个例子，Contacts 应用的 PeopleActivity 可以启动 QuickContactActivity 来查看联系人信息，而 QuickContactActivity 可以通过 Intent 启动 Email 应用的编写邮件的 Activity。虽然 Activity 来自不同的应用，但是它们都被保留在相同的 Tasks 中以保持无缝的用户体验：用户按 Back 键时，会逐个回退到上一个 Activity，仿佛这些 Activity 是属于同一个应用的。

从数组中删除元素是经常需要用到的情况，可能根据经验你知道要从后往前删除，但是你知道具体的原因吗？本文通过简单的解析让你知其所以然。

假设一个需求，从数组
["a", "bb", "bb", "ccc", "ccc", "ccc", "ccc"] 中删除”bb”元素，即一个数组需要遍历其中的元素，当该元素符合某个条件的时候从数组中将该元素中删除。

错误写法

新手可能会直接写出使用迭代器的以下代码：

写法一:

1
2
3
4
5
6
7

public static void remove(ArrayList<String> list) {
    for (String s : list) {
        if (s.equals("bb")) {
            list.remove(s);
        }
    }
}

在项目中——一个基于 AOSP 的联系人修改的应用使用弹出框的时候，发现弹出框的宽度是根据其中内容的多少来决定宽度的，对于一个应用而言，UI 希望可以使用统一宽度的弹出框以达到和谐统一。

要在项目里实现统一弹出框宽度的要求，由于当时对源码中使用的各种 Style 不是很熟悉，不太敢改相关的样式，想到的一种方法是使用代码指定所需要的宽度。

方法

使用以下设置显示属性的方法去控制Dialog的显示宽度。

Theme.AppCompat, Theme.Base.AppCompat, Base.V7.Theme.AppCompat, Base.v11.Theme.AppCompat, Base.v21.Theme.AppCompat, ThemeOverlay, Platform.AppCompat, DeviceDefault, Material, Holo, Classic 等等……

当使用安卓主题和支持库时，你可能会遇见以上这些名字，并且好奇：

• Base.V{something}, Theme.Base.AppCompat, Platform.AppCompat 是什么？
• 这些主题是如何组织起来的？
• 我应当用哪一个？

在本文中，我将回答上述问题，并尝试阐明这一切是如何工作的。

请保持淡定，分析代码，记住：性能很重要。

毫无疑问，应用的启动速度越快越好。

本文可以帮助你优化应用的启动时间：首先描述应用启动过程的内部机制；然后讨论如何分析启动性能；最后，列举了一些常见的影响启动时间的问题，并就如何解决这些问题给出一些提示。

第 1 部分：启动过程内部机制

应用的启动可能为三种状态之一，不同状态的启动时长是不一样的。三种状态分别为：冷启动(cold start)，暖启动(warm start)，热启动(lukewarm start)。冷启动即应用从零开始加载运行，而其它状态则是应用从后台运行回到前台运行。建议始终基于冷启动的假设进行优化，因为这样做同样提升了另两种启动状态的表现。

要使得应用能快速启动，首先要理解应用以不同状态启动时，系统和应用内发生了什么，以及它们是如何交互的。

请保持淡定，分析代码，记住：性能很重要。

自动装箱引发的血案

有时性能瓶颈是由小问题累积到一起产生的。

一个典型的例子就是 Java 的自动装箱功能。自动拆装箱的目的就是自动地将基础类型与它们的对象版本相互转化，这样你就不用操心你代码中的这些转化了。例如 Integer value = 0 当中，将整型的 0 自动的转化为 Integer 的对象。