在 Android 开发中，设备和代码的调试都离不开 ADB（Android Debug Bridge），默认情况下 ADB 没有被加入到系统环境变量中，这也就意味着不能在任何地方调起 ADB。如果调用，则会出现 [ adb 不是内部或外部命令，也不是可运行的程序或批处理文件。] 的提示，如下图所示：

现在许多公司已经在使用 Git 作为代码托管工具，但仍然有非常多的公司由于各种原因仍然在使用 SVN 进行代码管理。所以，本篇会详细的介绍如何将一个新建的项目托管到 SVN 上。要使用 SVN，首先需要在 SVN 服务端创建一个仓库用来存储项目。

1、创建仓库

打开 SVN 所在服务器的 VisualSVN Server，右键「Repositories」›「Create New Repository」。

随着 Glide 从 V3 向 V4 的升级，API 的调用方式也发生了一些变化。这些变化主要集中在：选项、类型与目标、配置等方面。本文也会根据这几个方面结合官方文档对 API 变更做一个详细的阐述。在进行正式介绍 API 变更之前，我想非常有必要简述一下 Glide 的接入。这样，每位读者在阅读这篇文章的时候就不会感到陌生和生硬。

1 Android SDK 要求

我们知道使用 WebViewClient 和 WebChromeClient 类可以响应发生在 WebView 里的特定事件。然而，通过注入任意 Java 对象到 WebView 的 JavaScript 中，我们还可以做到更多。查阅 WebView 文档，找到 addJavascriptInterface (Object object, String name) 方法。使用该方法，可以将任意 Java 对象注入到指定文档中。

1. API 简介

开始正式介绍实现过程之前，先来看下效果图，原点纵向跳动，跳动幅度在上次原点数的基础上随机做增减。

在一些选项卡滑动切换的应用场景下，我们大多会采用 ViewPager 与 Fragment 组合的方式来实现这样的需求，但 ViewPager 会预加载下一个 Framgment 的内容，这种机制的初衷是为了让用户更流畅的看到后面的内容。但是，当 ViewPager 中持久保留的 Framgment 数量增加，同时 Framgment 中又包含有大量的网络请求和数据库操作的时候，这种机制的弊端就出现了，预加载机制使的 ViewPager 内所有 Fragment 的网络请求和数据库操作同时被触发，CPU 和 内存占用会发生跳跃式的增长，最终造成 APP 卡顿，影响用户体验。

如果想提升用户体验，理想的状态大概是这样的：让 Fragment 内的网络请求和数据库操作根据需要进行触发。当 Fragment 对用户首次可见时，执行网络请求或数据库操作；当 Fragment 滑出屏幕时，不追加任何后续操作；当 Fragment 对用户再次可见时，根据首次执行状态决定是否执行网络请求或数据库操作。这样一个过程实际上就是 Fragment 的懒加载过程。

实现思路：新建一个拥有 M 个元素的数组 Find，将 N 个数中的前 M 个元素存入该数组，假设这前 M 个元素就是最大值，在存入的过程中找出最小数值的索引 minIndex。然后从 N 个数中的第 ( M + 1 ) 个元素开始，逐个与 Find 数组中的最小值进行比较，若大于 Find 数组中的最小值，则将其替换。替换完毕后，继续循环找出 Find 数组中最小值的索引，外层的 while 在进行下一次循环时，会直接拿 N 的下一个元素与 Find 数组中的最小值进行比较。这样循环一遍之后，Find 数组中的最小值都被较大的数值替换，这时 Find 中存放的元素就是 N 中最大的 M 个数，这种思路的时间复杂度为O(n*logm)。这种实现方式可以将亿级数据量的运算时间控制在 100 毫秒内。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

package com.sunzn.max;

import java.util.Random;

public class FindMax {

    public static void main(String[] args) {

        Random random = new Random();

        int n = 100000000;

        int[] Pool = new int[n];

        for (int i = 0; i < n; i++) {
            Pool[i] = random.nextInt(n);
        }

        findMax(Pool, 10);

    }

    private static void findMax(int[] data, int m) {

        long sTime = System.currentTimeMillis();

        int[] Find = new int[m];

        int minIndex = 0;

        for (int i = 0; i < Find.length; i++) {
            Find[i] = data[i];
            if (Find[minIndex] > Find[i]) {
                minIndex = i;
            }
        }

        while (m < data.length) {
            if (data[m] > Find[minIndex]) {
                Find[minIndex] = data[m];
                for (int i = 0; i < Find.length; i++) {
                    if (Find[minIndex] > Find[i]) {
                        minIndex = i;
                    }
                }
            }
            m++;
        }

        for (int i = 0; i < Find.length; i++) {
            System.out.printf("结果数据:");
            System.out.printf("%d", Find[i]);
            System.out.printf("\n");
        }

        long eTime = System.currentTimeMillis();

        System.out.printf("消耗时间:" + (eTime - sTime) + "毫秒");

    }

}

图片有不同的形状与大小。在大多数情况下它们的实际大小都比需要呈现的尺寸大很多。例如，系统的图库应用会显示我们使用相机拍摄的照片，但这些图片的分辨率通常都比设备屏幕的分辨率要高很多。

考虑到应用是在有限的内存下工作的，理想情况下，我们只需要在内存中加载一个低分辨率的照片即可。为了有更好的显示效果，这个低分辨率的照片应该与展示它的UI组件大小相匹配。加载高分辨率的图片不仅没有任何显而易见的好处，还会占用宝贵的内存资源，并且由于图片的即时缩放，还会增加额外的性能开销。

下面将会介绍如何解码大型位图，加载缩小版图片，从而避免超出应用程序的内存限制。

1.读取位图的尺寸与类型

BitmapFactory 提供了多种解码方法（decodeByteArray()， decodeFile()，decodeResource() 等），用于从各种来源创建 Bitmap。我们应该根据图片的数据源选择最合适的解码方法。这些方法在构造位图的时候会尝试分配内存，因此很容易导致 OutOfMemory 异常。每一种解码方法都可以通过 BitmapFactory.Options 设置一些附加的标记，以此来指定解码选项。设置 inJustDecodeBounds 属性为 true 可以在解码时避免内存的分配，返回的 Bitmap 为 null，但是可以获取到 outWidth，outHeight 与 outMimeType。该技术可以允许你在构造 Bitmap 之前优先读图片的尺寸与类型（以及内存分配）。

当一个 Android 设备闲置时，它的屏幕会先变暗，然后关闭屏幕，最后关闭 CPU。 这样可以防止设备的电量被快速耗尽。 但是，有时候也会存在一些例外：

• 例如游戏或电影之类的应用可能需要保持屏幕常亮。
• 其他应用可能不需要屏幕保持常亮，但是可能需要 CPU 保持运行，直到关键操作完成。

本文将描述如何在必要的时候保持设备唤醒，同时又不会过多消耗它的电量。

1. 保持设备唤醒

了解如何根据需要保持屏幕或 CPU 的唤醒，同时最大限度地减少对电池寿命的影响。

为了避免电量耗尽，闲置的 Android 设备会迅速进入睡眠状态。但是，有时应用程序需要唤醒屏幕或 CPU 并保持唤醒状态才能完成某些工作。

采取什么样的方法取决于你应用程序的需求。然而，一般的经验是，你应该为应用使用最轻量级的方法，以尽量减少其对系统资源的影响。接下来的内容会介绍如何处理设备的默认睡眠行为与应用程序的需求不兼容的情况。

Android 5.0 行为变更已经好长时间了，之前进行 WebView 的开发一直没有出现问题，所有也就没有关注这次行为变更对 WebVie 带来的影响。直到要为一个视频网站开发的 APP 里嵌入 WebView 进行音视频播放，才发现问题所在。大概描述一下情况：视频网站使用了 HTTPS 加密，但视频资源采用的是 HTTP，几经测试，发现网站取消 HTTPS 加密后，WebView 就可以正常加载视频了。于是就顺藤摸瓜，有了这篇文章。开始文章之前，先来看看 Google 官方的描述 Android 5.0 行为变更之 WebView。

1. WebView 行为变更

Android 5.0 更改了应用的默认行为。

• 如果您的应用是面向 API 级别 21 或更高级别：
  • 默认情况下，系统会阻止混合内容和第三方 Cookie。要允许混合内容和第三方 Cookie，请分别使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法。
  • 系统现在可以智能地选择要绘制的 HTML 文档部分。这个新的默认行为有助于减少内存占用和提升性能。如果您要一次渲染整个文档，可通过调用 enableSlowWholeDocumentDraw() 停用此优化。
• 如果您的应用是面向低于 21 的 API 级别：
  • 系统允许混合内容和第三方 Cookie，并始终一次渲染整个文档。