androidworkthread

Ⅰ 针对android的性能优化集中哪些方面

一、概要：

本文主要以Android的渲染机制、UI优化、多线程的处理、缓存处理、电量优化以及代码规范等几方面来简述Android的性能优化

二、渲染机制的优化：

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染， 如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

*关于JobScheler的更多知识可以参考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代码规范

1）for loop中不要声明临时变量，不到万不得已不要在里面写try catch。

2）明白垃圾回收机制，避免频繁GC，内存泄漏，OOM(有机会专门说)

3）合理使用数据类型，StringBuilder代替String，少用枚举enum，少用父类声明(List,Map)

4）如果你有频繁的new线程，那最好通过线程池去execute它们，减少线程创建开销。

5）你要知道单例的好处，并正确的使用它。

6）多用常量，少用显式的"action_key"，并维护一个常量类，别重复声明这些常量。

7）如果可以，至少要弄懂设计模式中的策略模式，组合模式，装饰模式，工厂模式，观察者模式，这些能帮助你合理的解耦，即使需求频繁变更，你也不用害怕牵一发而动全身。需求变更不可怕，可怕的是没有在写代码之前做合理的设计。

8）View中设置缓存属性.setDrawingCache为true.

9）cursor的使用。不过要注意管理好cursor,不要每次打开关闭cursor.因为打开关闭Cursor非常耗时。Cursor.require用于刷cursor.

10）采用SurfaceView在子线程刷新UI,避免手势的处理和绘制在同一UI线程（普通View都这样做）

11）采用JNI，将耗时间的处理放到c/c++层来处理

12）有些能用文件操作的，尽量采用文件操作，文件操作的速度比数据库的操作要快10倍左右

13）懒加载和缓存机制。访问网络的耗时操作启动一个新线程来做，而不要再UI线程来做

14）如果方法用不到成员变量，可以把方法申明为static，性能会提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明为public，直接访问

16）私有内部类要访问外部类的field或方法时,其成员变量不要用private，因为在编译时会生成setter/getter,影响性能。可以把外部类的field或方法声明为包访问权限

17）合理利用浮点数，浮点数比整型慢两倍

18）针对ListView的性能优化，ListView的背景色与cacheColorHint设置相同颜色，可以提高滑动时的渲染性能。ListView中getView是性能是关键，这里要尽可能的优化。

getView方法中要重用view；getView方法中不能做复杂的逻辑计算，特别是数据库操作，否则会严重影响滑动时的性能

19）不用new关键词创建类的实例，用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。

clone()方法不会调用任何类构造函数。在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单。例如，下面是Factory模式的一个典型实现：

20）public static Credit getNewCredit() {
return new Credit();
}
改进后的代码使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路对于数组处理同样很有用。

21）乘法和除法

考虑下面的代码：

22）ViewPager同时缓存page数最好为最小值3，如果过多，那么第一次显示时，ViewPager所初始化的pager就会很多，这样pager累积渲染耗时就会增多，看起来就卡。

23）每个pager应该只在显示时才加载网络或数据库(UserVisibleHint=true)，最好不要预加载数据，以免造成浪费

24）提高下载速度：要控制好同时下载的最大任务数，同时给InputStream再包一层缓冲流会更快(如BufferedInputStream)

25）提供加载速度：让服务端提供不同分辨率的图片才是最好的解决方案。还有合理使用内存缓存，使用开源的框架

引用：Android性能优化的浅谈

Ⅱ Framework事件机制——手撕Android事件处理的三种方法

Android的事件处理的三种方法：

setOnClickListener，setOnLongClickListener、setOnTouchListener

注意：如果onTouchEvent方法return true，则单击事件和长摁事件不再执行；若onLongClick方法返回true，则单击事件不再处理。

需要定义继承组件的类，重写回调方法Touch方法执行时，先被Activity捕获，DispatchTouchEvent方法处理。return false，交给上层的onTouchEvent方法处理；return super.dispatchTouchEvent（ev），则传递给最外层的View。

View用Dispatch方法处理，return false，由上层的onTouchEvent方法处理。如果返回super.dispatchTouchEvent（ev），则本层的onInterceptTouchEvent拦截，如果拦截true，则拦截，false不拦截，传递给子View的DispatchTouchEvent处理。

常用的回调方法：onKeyDown，onKeyLongPress，onKeyUp，onTouchEvent，onTrackballEvent（轨迹球事件）监听和回调同时存在时，先调用监听。

流程模型图：

Event source 事件源
Event 事件
Event Listener 事件监听器
下面我们来看一下点击事件和触摸事件的监听三要素具体是那部分：

由于点击事件比较简单，系统已经帮我们处理了，并没有找到具体事件是哪个。

View.OnClickListener 单击事件监听器必须实现的接⼝
View.OnCreateContextMenuListener 创建上下⽂菜单事件
View.OnFocusChangeListener 焦点改变事件
View.OnKeyListener 按键事件监听器
View.OnLongClickListener 长按事件监听器
View.OnTouchListener 触摸屏事件监听器

⾸先，事件监听机制中由事件源，事件，事件监听器三类对象组成。
事件监听器处理流程：

在此以OnClickListener单击事件为例使用intent来实现页面的跳转

监听事件处理是事件源与事件监听器分开的而基于回调的事件处理UI组件不但是事件源，而且还是事件监听器，通过组件的相关回调方法处理对应的事件。

Ⅰ. 自定义View类，继承自需要的View UI类。ex ：自定义 MyButton按钮类 extends 基础Button类

Ⅱ. 复写回调函数。ex：public boolean onTouchEvent(MotionEvent event)

每一个事件回调方法都会返回一个boolean值，①.如果返回true：表示该事件已被处理,不再继续向外扩散，②.如果返回false：表示事件继续向外扩散

而说到基于回调就离不开监听机制 。

几乎所有基于回调的事件处理方法都有一个boolean类型的返回值，该返回值用于表示该处理方法是否能完全处理该事件。
如果处理事件的回调方法返回true，表明该处理方法已经完全处理改事件，该事件不会传播出去。
如果处理事件的回调方法返回false，表明该处理方法并未完全处理该事件，该事件会传播出去。
对于基于回调的时间传播而言，某组件上所发生的事件不仅会激发该组件上的回调方法，也会触发该组件所在Activity的回调方法——只要事件能传播到该Activity。

这里是在模拟器里进行的测试，这里按下键盘(而不是点击)，会看到 logcat 中的输出，如下：

View类实现了KeyEvent.Callback接口中的一系列回调函数，因此，基于回调的事件处理机制通过自定义View来实现，自定义View时重写这些事件处理方法即可。

Handler是一个消息分发对象。

Handler是Android系统提供的一套用来更新UI的机制，也是一套消息处理机制，可以通过Handler发消息，也可以通过Handler处理消息。

在下面介绍Handler机制前，首先得了解以下几个概念：

在子线程执行完耗时操作，当Handler发送消息时，将会调用 MessageQueue.enqueueMessage ，向消息队列中添加消息。 当通过 Looper.loop 开启循环后，会不断地从消息池中读取消息，即调用 MessageQueue.next ， 然后调用目标Handler（即发送该消息的Handler）的 dispatchMessage 方法传递消息， 然后返回到Handler所在线程，目标Handler收到消息，调用 handleMessage 方法，接收消息，处理消息。

从上面可以看出，在子线程中创建Handler之前，要调用 Looper.prepare() 方法，Handler创建后，还要调用 Looper.loop() 方法。而前面我们在主线程创建Handler却不要这两个步骤，因为系统帮我们做了。

初始化Looper ：

从上可以看出，不能重复创建Looper，每个线程只能创建一个。创建Looper，并保存在 ThreadLocal 。其中ThreadLocal是线程本地存储区（Thread Local Storage，简称TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的TLS区域。

开启Looper

发送消息 ：

post方法：

send方法：

在子线程中，进行耗时操作，执行完操作后，发送消息，通知主线程更新UI。

本文讲解了三个方面；Android事件机制；基于监听、基于回调以及Handler消息处理。还有许多没有讲解到的知识点，我总结在了整理的一套Android进阶笔记里面；需要学习进阶的同学可以前往获取： Frame Work源码解析手册 、 Android核心技术进阶手册、实战笔记、面试题纲资料

Ⅲ android 7.0对开发者会有哪些影响

Android N 除了提供诸多新特性和功能外，还对系统和 API 行为做出了各种变更。 本文重点介绍您应该了解并在开发应用时加以考虑的一些重要变更。

如果您之前发布过 Android 应用，请注意您的应用可能受到这些平台变更的影响。

电池和内存

Android N 包括旨在延长设备电池寿命和减少 RAM 使用的系统行为变更。 这些变更可能会影响您的应用访问系统资源，以及您的系统通过特定隐式 Intent 与其他应用互动的方式。

低电耗模式

Android 6.0（API 级别
23）引入了低电耗模式，当用户设备未插接电源、处于静止状态且屏幕关闭时，该模式会推迟 CPU 和网络活动，从而延长电池寿命。而 Android N
则通过在设备未插接电源且屏幕关闭状态下、但不一定要处于静止状态（例如用户外出时把手持式设备装在口袋里）时应用部分 CPU
和网络限制，进一步增强了低电耗模式。

图 1. 低电耗模式如何辩蠢应用第一级系统活动限制以延携毕陪长电池寿命的图示。

当设备处于充电状态且屏幕已关闭一定时间后，设备会进入低电耗模式并应用第一部分限制： 关闭应用网络访问、推迟作业和同步。 如果进入低电耗模式后设备处于静止状态达到一定时间，系统则会对 PowerManager.WakeLock、AlarmManager 闹铃、GPS
和 Wi-Fi 扫描应用余下的低电耗模式限制。 无论是应用部分还是全部低电耗模式限制，系统都会唤醒设备以提供简短的维护时间窗口，在此窗口期间，应用程序可以访问网络并执行任何被推迟的作业/同步。

图 2. 低电耗模式如何在设备处于静止状态达到一定时间后应用第二级系统活动限制的图示。

请注意，激活屏幕或插接设备电源时，系统将退出低电耗模式并取消这些处理限制。 此项新增的行为不会影响有关使您的应用适应 Android 6.0（API 级别 23）中所推出的旧版本低电耗模式的建议和最佳实践，如低电耗模式和应用待机模式优化中所讨论。
您仍应遵循这些建议（例如使用 Google Cloud Messaging (GCM) 发送和接收消息）并开始安排更新计划以适应新增的低电耗模式行为。

Project Svelte：后台优化

Android N 删除了三项隐式广播，以帮助优化内存使用和电量消耗。 此项变更很有必要，因为隐式广播会在后台频繁启动已注册侦听这些广播的应用。 删除这些广播可以显着提升设备性能和用户体验。

移动设备会经历频繁的连接变更，例如在 Wi-Fi 和移动数据之间切换时。 目前，可以通过在应用清单中注册一个接收器来侦听隐式 CONNECTIVITY_ACTION广播，让应用能够监控这些变更。
由于很多应用会注册接收此广播，因此单次网络切换即会导致所有应用被唤醒并同时处理此广播。

同理，应用可以注册接收来自数碰其他应用（例如相机）的隐式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 广播。
当用户使用相机应用拍摄照片时，这些应用即会被唤醒以处理广播。

为缓解这些问题，Android N 应用了以下优化措施：

面向 Android N 开发的应用不会收到 CONNECTIVITY_ACTION 广播，即使它们已有清单条目来请求接受这些事件的通知。
在前台运行的应用如果使用BroadcastReceiver 请求接收通知，则仍可以在主线程中侦听 CONNECTIVITY_CHANGE。
应用无法发送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 广播。此项优化会影响所有应用，而不仅仅是面向
Android N 的应用。

如果您的应用使用任何 Intent，您仍需要尽快移除它们的依赖关系，以正确适配 Android N 设备。 Android 框架提供多个解决方案来缓解对这些隐式广播的需求。 例如，JobScheler API
提供了一个稳健可靠的机制来安排满足指定条件（例如连入无限流量网络）时所执行的网络操作。 您甚至可以使用JobScheler 来适应内容提供程序变化。

如需了解有关 Android N 中后台优化以及如何改写应用的详细信息，请参阅后台优化。

权限更改

Android N 做了一些权限更改，这些更改可能会影响您的应用。

系统权限更改

为了提高私有文件的安全性，面向 Android N 或更高版本的应用私有目录被限制访问(0700)。 此设置可防止私有文件的元数据泄漏，如它们的大小或存在。 此权限更改有多重副作用：

私有文件的文件权限不应再由所有者放宽，为使用 MODE_WORLD_READABLE 和/或 MODE_WORLD_WRITEABLE 而进行的此类尝试将触发SecurityException。
注：迄今为止，这种限制尚不能完全执行。 应用仍可能使用原生 API 或 File API 来修改它们的私有目录权限。 但是，我们强烈反对放宽私有目录的权限。

传递软件包网域外的 file:// URI 可能给接收器留下无法访问的路径。 因此，尝试传递 file:// URI 会触发 FileUriExposedException。 分享私有文件内容的推荐方法是使用 FileProvider。
DownloadManager 不再按文件名分享私人存储的文件。
旧版应用在访问 COLUMN_LOCAL_FILENAME 时可能出现无法访问的路径。
面向 Android N 或更高版本的应用在尝试访问 COLUMN_LOCAL_FILENAME 时会触发 SecurityException。
通过使用DownloadManager.Request.() 或 DownloadManager.Request.() 将下载位置设置为公共位置的旧版应用仍可以访问 COLUMN_LOCAL_FILENAME 中的路径，但是我们强烈反对使用这种方法。
访问由 DownloadManager 公开的文件的首选方式是使用 ContentResolver.openFileDescriptor()。

应用间共享文件

对于面向 Android N 的应用，Android 框架执行的 StrictMode API
政策禁止向您的应用外公开 file:// URI。 如果一项包含文件 URI 的 Intent 离开您的应用，应用失败，并出现 FileUriExposedException 异常。

若要在应用间共享文件，您应发送一项 content:// URI，并授予 URI 临时访问权限。 进行此授权的最简单方式是使用 FileProvider 类。
如需有关权限和共享文件的更多信息，请参阅共享文件。

无障碍改进

为提高平台对于视力不佳或视力受损用户的可用性，Android N 做出了一些更改。这些更改一般并不要求更改您的应用代码，不过您应仔细检查并使用您的应用测试这些功能，以评估它们对用户体验的潜在影响。

屏幕缩放

Android N 支持用户设置显示尺寸，以放大或缩小屏幕上的所有元素，从而提升设备对视力不佳用户的可访问性。用户无法将屏幕缩放至低于最小屏幕宽度 sw320dp，该宽度是
Nexus 4 的宽度，也是常规中等大小手机的宽度。

图 3. 右侧屏幕显示的是一台运行 Android N 系统映像的设备增大显示尺寸后的效果。

当设备密度发生更改时，系统会以如下方式通知正在运行的应用：

如果是面向 API 级别 23 或更低版本系统的应用，系统会自动终止其所有后台进程。 这意味着如果用户切换离开此类应用，转而打开“Settings”屏幕并更改 Display size 设置，则系统会像处理内存不足的情况一样终止该应用。 如果应用具有任何前台进程，则系统会如处理运行时变更中所述将配置变更通知给这些进程，就像对待设备屏幕方向变更一样。
如果是面向 Android N 的应用，则其所有进程（前台和后台）都会收到有关配置变更的通知，如处理运行时变更中所述。

大多数应用并不需要进行任何更改即可支持此功能，不过前提是这些应用遵循 Android 最佳实践。具体要检查的事项：

在屏幕宽度为 sw320dp 的设备上测试您的应用，并确保其充分运行。
当设备配置发生变更时，更新任何与密度相关的缓存信息，例如缓存位图或从网络加载的资源。当应用从暂停状态恢复运行时，检查配置变更。
注：如果您要缓存与配置相关的数据，则最好也包括相关元数据，例如该数据对应的屏幕尺寸或像素密度。 保存这些元数据便于您在配置变更后决定是否需要刷新缓存数据。

避免用像素单位指定尺寸，因为像素不会随屏幕密度缩放。应改为使用与密度无关像素 (dp)
单位指定尺寸。

设置向导中的视觉设置

Android N 在“Welcome”屏幕中加入了“Vision Settings”，用户可以在新设备上设置以下无障碍功能设置： Magnification gesture、Font size、Display size 和 TalkBack。 此项变更增强了与不同屏幕设置相关的错误的可见性。
要评估此功能的影响，您应在启用这些设置的状态下测试应用。 您可以在Settings > Accessibility 中找到这些设置。

NDK 应用链接至平台库

Android N 做了一些命名空间更改，以阻止加载非公开 API。 如果您使用 NDK，则只能使用 Android 平台提供的公开 API。 在下一个官方发布的 Android 版本上使用非公开 API 会导致应用崩溃。

为提醒您使用了非公开 API，在 Android N
设备上运行的应用会在有应用调用非公开 API 时在日志消息输出中生成一个错误。
此错误还会作为消息显示在设备屏幕上，以帮助增强您对此情况的认识。 您应检查应用代码以删除使用非公开平台
API，并使用预览版设备或模拟器全面测试应用。

如果您的应用依赖平台库，则请参见 NDK 文档，了解使用公开 API 等效项替换普通私有 API 的典型修复。 您还可以链接至平台库，而无需实现此应用，如果应用使用的库是平台的一部分（例如 libpng），但不属于 NDK，则更可如此。 此情况下，请确保您的 APK 包含您打算链接到的所有 .so 文件。

注意：有些第三方库可能会链接至非公开 API。 如果您的应用使用这些库，那么当您的应用在下一个官方发布的 Android 版本上运行时可能会出现崩溃现象。

应用不应依赖或使用不属于 NDK
的原生库，因为这些库可能会发生更改或从一个 Android 版本迁移至另一版本。 例如，从 OpenSSL 切换至 BoringSSL
即属于此类更改。 此外，不同的设备可能提供不同级别的兼容性，因为不属于 NDK 中的平台库没有兼容性要求。 如果您必须在较旧设备上访问非 NDK
库，则请依据 Android API 级别进行加载。

为帮助您诊断此类问题，下面列举了一些在您试图使用 Android N 开发应用时可能遇到的 java 和 NDK 错误：

Java 错误示例：
java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libcutils.so"
is not accessible for the namespace "classloader-namespace"

NDK 错误示例：
dlopen failed: cannot locate symbol "__system_property_get" referenced by ...

以下是遇到这类错误的应用的一些典型修复：

可以使用标准 JNI 函数来替代使用 libandroid_runtime.so 中的 getJavaVM 和 getJNIEnv：
AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.

可以使用公开 alternative __system_property_get 来替代使用 libcutils.so 中的 property_get 符号。如需这样做，请使用__system_property_get 及以下 include 函数：
#include <sys/system_properties.h>

应使用应用本地版本来替代使用 libcrypto.so 中的 SSL_ctrl 符号。例如，您应在 .so 文件中静态链接 libcyrpto.a，或者在应用中包含您自己的来自 BoringSSL 或 OpenSSL 的动态 libcrypto.so。

Android for Work

Android N 包含一些针对面向 Android
for Work 的应用的变更，包括对证书安装、密码重置、二级用户管理、设备标识符访问权限的变更。如果您是要针对 Android for
Work 环境开发应用，则应仔细检查这些变更并相应地修改您的应用。

您必须先安装授权证书安装程序，然后 DPC 才能对其进行设置。 对于面向 N SDK 的个人资料和设备所有者应用，您应在设备策略控制器 (DPC) 调用DevicePolicyManager.setCertInstallerPackage() 之前安装授权证书安装程序。 如果尚未安装此安装程序，则系统会引发IllegalArgumentException。
针对设备管理员的重置密码限制现在也适用于个人资料所有者。 设备管理员无法再使用 DevicePolicyManager.resetPassword() 来清除或更改已经设置的密码。 设备管理员仍可以设置密码，但只能在设备没有密码、PIN 或图案时这样做。
即使设置了限制，设备所有者和个人资料所有者仍可以管理帐户。而且，即使具有 DISALLOW_MODIFY_ACCOUNTS 用户限制，设备所有者和个人资料所有者仍可调用 Account Management API。
设备所有者可以更轻松地管理二级用户。当设备在设备所有者模式下运行时，系统将自动设置 DISALLOW_ADD_USER 限制。 这样可以防止用户创建非托管二级用户。 此外，CreateUser() 和 createAndInitializeUser() 方法已弃用，取而代之的是 DevicePolicyManager.createAndManageUser() 方法。
设备所有者可以访问设备标识符。设备所有者可以使用 DevicePolicyManagewr.getWifiMacAddress() 访问设备的 Wi-Fi MAC 地址。 如果设备上从未启用 Wi-Fi，则此方法将返回一个 null 值。
工作模式设置控制工作应用访问。当工作模式关闭时，系统启动器通过使工作应用显示为灰色来指示它们不可用。 启用工作模式会再次恢复正常行为。

如需了解有关 Android N 中针对 Android for Work 所做变更的详细信息，请参阅 Android for
Work 更新。

注解保留

Android N 在注解可见性被忽略时修复错误。这种问题将启用本不应被允许的运行时访问注解。 这些注解包括：

VISIBILITY_BUILD:仅应编译时可见。
VISIBILITY_SYSTEM:运行时应可见，但仅限基本系统。

如果您的应用依赖这种行为，请在注解中添加一项运行时必须可用的保留政策。 您可通过使用 @Retention(RetentionPolicy.RUNTIME) 来如此做。

其他重要说明

如果一个应用在 Android N 上运行，但却是针对更低 API 级别开发的，那么在用户更改显示尺寸时，系统将终止此应用进程。 应用必须能够正常处理此情景。 否则，当用户从最近使用记录中恢复运行应用时，应用将会出现崩溃现象。
您应测试应用以确保不会发生此行为。要进行此测试，您可以通过 DDMS 手动终止应用，以造成相同的崩溃现象。

在密度发生更改时，系统不会自动终止面向 N 及更高版本的应用；不过，这些应用仍可能对配置变更做出不良响应。

Android N 上的应用应能够正常处理配置变更，并且在后续启动时不会出现崩溃现象。您可以通过更改字体大小 (Setting > Display > Font size) 并随后从最近使用记录中恢复运行应用，来验证应用行为。
由于之前的 Android 版本中的一项错误，系统未能将对主线程上的一个 TCP 套接字的写入操作举报为严格模式违反。 Android N 修复了此错误。呈现出这种行为的应用引发 android.os.NetworkOnMainThreadException。一般情况下，我们不建议在主线程上执行网络操作，因为这些操作通常都有可能导致 ANR 和卡顿的高尾延迟。
Debug.startMethodTracing() 方法族现在默认在您的共享的存储空间上的软件包特定目录中存储输出，而非 SD 卡顶级。 这意味着应用不再需要请求WRITE_EXTERNAL_STORAGE 使用这些 API 的权限。
许多平台 API 现在开始检查在 Binder 事务间发送的大负载，系统现在会将 TransactionTooLargeExceptions 再次作为 RuntimeExceptions 引发，而不再只是默默记录或抑制它们。
一个常见例子是在 Activity.onSaveInstanceState() 上存储过多数据，导致 ActivityThread.StopInfo 在您的应用面向
Android N 时引发 RuntimeException。
如果应用向 View 发布 Runnable 任务，并且 View 未附加到窗口，系统会用 View 为 Runnable 任务排队；在 View 附加到窗口之前，Runnable 任务不会执行。
此行为会修复以下错误：
如果一项应用是从并非预期窗口 UI 线程的其他线程发布到 View，则Runnable 可能会因此运行错误的线程。
如果 Runnable 任务是从并非环路线程的其他线程发布，则应用可能会曝光 Runnable 任务。
如果 Android N 上一项有 DELETE_PACKAGES 权限的应用尝试删除一个软件包，但另一项应用已经安装了这个软件包，则系统可能要求用户确认。
在这种情况下，应用在调用 PackageInstaller.uninstall() 时的返回状态应为 STATUS_PENDING_USER_ACTION。

Ⅳ 如何实现一个android的log自动化分析工具

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

[ 12-09 21:39:35.510 396: 416 I/ActivityManager ]

Start procnet.coollet.infzmreader:umengService_v1 for service
net.coollet.infzmreader/com.umeng.message.

UmengService:pid=21745 uid=10039 gids={50039, 3003, 1015,1028}

[ 12-09 21:39:35.518 21745:21745I/dalvikvm ]

Turning on JNI app bug workarounds fortarget SDK version 8...

[ 12-09 21:39:35.611 21745:21745D/AgooService ]

onCreate()

我们以第一行为例：12-09 是日期，21:39:35.510是时间396是进程号，416是线程号；I代表log优先级，ActivityManager是log标签。

在应用开发中，这些信息的作用可能不是很大。但是在系统开发中，这些都是很重要的辅助信息。开发工程师分析的log很多都是由测试工程师抓取的，所以可能有些log根本就不是当时出错的log。如果出现这种情况，无论你怎么分析都不太可能得出正确的结论。如何能最大限度的避免这种情况呢？笔者就要求测试工程师报bug时必须填上bug发生的时间。这样结合log里的时间戳信息就能大致判断是否是发生错误时的log。而且根据测试工程师提供的bug发生时间点，开发工程师可以在长长的log信息中快速的定位错误的位置，缩小分析的范围。

同时我们也要注意，时间信息在log分析中可能被错误的使用。例如：在分析多线程相关的问题时，我们有时需要根据两段不同线程中log语句执行的先后顺序来判断错误发生的原因，但是我们不能以两段log在log文件中出现的先后做为判断的条件，这是因为在小段时间内两个线程输出log的先后是随机的，log打印的先后顺序并不完全等同于执行的顺序。那么我们是否能以log的时间戳来判断呢？同样是不可以，因为这个时间戳实际上是系统打印输出log时的时间，并不是调用log函数时的时间。遇到这种情况唯一的办法是在输出log前，调用系统时间函数获取当时时间，然后再通过log信息打印输出。这样虽然麻烦一点，但是只有这样取得的时间才是可靠的，才能做为我们判断的依据。

另外一种误用log中时间戳的情况是用它来分析程序的性能。一个有多年工作经验的工程师拿着他的性能分析结果给笔者看，但是笔者对这份和实际情况相差很远的报告表示怀疑，于是询问这位工程师是如何得出结论的。他的回答让笔者很惊讶，他计算所采用的数据就是log信息前面的时间戳。前面我们已经讲过，log前面时间戳和调用log函数的时间并不相同，这是由于系统缓冲log信息引起的，而且这两个时间的时间差并不固定。所以用log信息前附带的时间戳来计算两段log间代码的性能会有比较大的误差。正确的方法还是上面提到的：在程序中获取系统时间然后打印输出，利用我们打印的时间来计算所花费的时间。

了解了时间，我们再谈谈进程Id和线程Id，它们也是分析log时很重要的依据。我们看到的log文件，不同进程的log信息实际上是混杂在一起输出的，这给我们分析log带来了很大的麻烦。有时即使是一个函数内的两条相邻的log，也会出现不同进程的log交替输出的情况，也就是A进程的第一条log后面跟着的是B进程的第二条log，对于这样的组合如果不细心分析，就很容易得出错误的结论。这时一定要仔细看log前面的进程Id，把相同Id的log放到一起看。

不同进程的log有这样的问题，不同的线程输出的log当然也存在着相同的问题。Logcat加上-vthread就能打印出线程Id。但是有一点也要引起注意，就是Android的线程Id和我们平时所讲的linux线程Id并不完全等同。首先，在Android系统中，C++层使用的Linux获取线程Id的函数gettid()是不能得到线程Id的，调用gettid()实际上返回的是进程Id。作为替代，我们可以调用pthread_self()得到一个唯一的值来标示当前的native线程。Android也提供了一个函数androidGetThreaId()来获取线程Id，这个函数实际上就是在调用pthread_self函数。但是在Java层线程Id又是另外一个值，Java层的线程Id是通过调用Thread的getId方法得到的，这个方法的返回值实际上来自Android在每个进程的java层中维护的一个全局变量，所以这个值和C++层所获得的值并不相同。这也是我们分析log时要注意的问题，如果是Java层线程Id，一般值会比较小，几百左右；如果是C++层的线程，值会比较大。在前里面的log样本中，就能很容易的看出，第一条log是Jave层输出的log，第二条是native层输出的。明白了这些，我们在分析log时就不要看见两段log前面的线程Id不相同就得出是两个不同线程log的简单结论，还要注意Jave层和native层的区别，这样才能防止被误导。

AndroidLog的优先级在打印输出时会被转换成V，I，D，W，E等简单的字符标记。在做系统log分析时，我们很难把一个log文件从头看到尾，都是利用搜索工具来查找出错的标记。比如搜索“E/”来看看有没有指示错误的log。所以如果参与系统开发的每个工程师都能遵守Android定义的优先级含义来输出log，这会让我们繁重的log分析工作变得相对轻松些。

Android比较常见的严重问题有两大类，一是程序发生崩溃；二是产生了ANR。程序崩溃和ANR既可能发生在java层，也可能发生在native层。如果问题发生在java层，出错的原因一般比较容易定位。如果是native层的问题，在很多情况下，解决问题就不是那么的容易了。我们先看一个java层的崩溃例子：

I/ActivityManager( 396): Start proccom.test.crash for activity com.test.crash/.MainActivity:
pid=1760 uid=10065 gids={50065, 1028}

D/AndroidRuntime( 1760): Shutting downVM

W/dalvikvm( 1760): threadid=1: threadexiting with uncaught exception(group=0x40c38930)

E/AndroidRuntime( 1760): FATALEXCEPTION: main

E/AndroidRuntime( 1760):java.lang.RuntimeException: Unable to start activityComponentInfo
{com.test.crash/com.test.crash.MainActivity}:java.lang.NullPointerException

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2180)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2230)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.access$600(ActivityThread.java:141)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:1234)

E/AndroidRuntime( 1760): atandroid.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime( 1760): atandroid.os.Looper.loop(Looper.java:137)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.main(ActivityThread.java:5050)

E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invokeNative(NativeMethod)

E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:793)

E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)

E/AndroidRuntime( 1760): atdalvik.system.NativeStart.main(NativeMethod)

E/AndroidRuntime( 1760): Caused by:java.lang.NullPointerException

E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.setViewText(MainActivity.java:29)

E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.onCreate(MainActivity.java:17)

E/AndroidRuntime( 1760): atandroid.app.Activity.performCreate(Activity.java:5104)

E/AndroidRuntime( 1760): atandroid.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1080)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2144)

E/AndroidRuntime( 1760): ... 11more

I/Process ( 1760): Sending signal.PID: 1760 SIG: 9

W/ActivityManager( 396): Force finishing activitycom.test.crash/.MainActivity

Jave层的代码发生crash问题时，系统往往会打印出很详细的出错信息。比如上面这个例子，不但给出了出错的原因，还有出错的文件和行数。根据这些信息，我们会很容易的定位问题所在。native层的crash虽然也有栈log信息输出，但是就不那么容易看懂了。下面我们再看一个native层crash的例子：

F/libc ( 2102): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread2102 (testapp)

D/dalvikvm(26630):GC_FOR_ALLOC freed 604K, 11% free 11980K/13368K, paused 36ms, total36ms

I/dalvikvm-heap(26630):Grow heap (frag case) to 11.831MB for 102416-byteallocation

D/dalvikvm(26630):GC_FOR_ALLOC freed 1K, 11% free 12078K/13472K, paused 34ms, total34ms

I/DEBUG ( 127):*** *** *** *** *** *** *** *** *** *** *** *** *** *** ******

I/DEBUG ( 127):Build fingerprint:
'Android/full_maguro/maguro:4.2.2/JDQ39/eng.liuchao.20130619.201255:userdebug/test-keys'

I/DEBUG ( 127):Revision: '9'

I/DEBUG ( 127):pid: 2102, tid: 2102, name: testapp >>>./testapp <<<
I/DEBUG ( 127):signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr00000000

I/DEBUG ( 127): r0 00000020 r173696874 r2 400ff520 r300000000

I/DEBUG ( 127): r4 400ff469 r5beb4ab24 r6 00000001 r7beb4ab2c

I/DEBUG ( 127): r8 00000000 r900000000 sl 00000000 fpbeb4ab1c

I/DEBUG ( 127): ip 4009b5dc spbeb4aae8 lr 400ff46f pc400ff45e cpsr 60000030

I/DEBUG ( 127): d0 000000004108dae8 d1 4108ced84108cec8

I/DEBUG ( 127): d2 4108cef84108cee8 d3 4108cf184108cf08

I/DEBUG ( 127): d4 4108c5a84108c598 d5 4108ca084108c5b8

I/DEBUG ( 127): d6 4108ce684108ce58 d7 4108ce884108ce78

I/DEBUG ( 127): d8 0000000000000000 d9 0000000000000000

I/DEBUG ( 127): d10 0000000000000000 d110000000000000000

I/DEBUG ( 127): d120000000000000000 d130000000000000000

I/DEBUG ( 127): d14 0000000000000000 d150000000000000000

I/DEBUG ( 127): d16 c1dcf7c087fec8b4 d173f50624dd2f1a9fc

I/DEBUG ( 127): d18 41c7b1ac89800000 d190000000000000000

I/DEBUG ( 127): d20 0000000000000000 d210000000000000000

I/DEBUG ( 127): d22 0000000000000000 d230000000000000000

I/DEBUG ( 127): d24 0000000000000000 d250000000000000000

I/DEBUG ( 127): d26 0000000000000000 d270000000000000000

I/DEBUG ( 127): d28 0000000000000000 d290000000000000000

I/DEBUG ( 127): d30 0000000000000000 d310000000000000000

I/DEBUG ( 127): scr 00000010

I/DEBUG ( 127):

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

I/DEBUG ( 127):

I/DEBUG ( 127):stack:

I/DEBUG ( 127): beb4aaa8 000000c8
I/DEBUG ( 127): beb4aaac 00000000
I/DEBUG ( 127): beb4aab0 00000000
I/DEBUG ( 127): beb4aab4 401cbee0 /system/bin/linker

I/DEBUG ( 127): beb4aab8 00001000
I/DEBUG ( 127): beb4aabc 4020191d /system/lib/libc.so (__libc_fini)

I/DEBUG ( 127): beb4aac0 4020191d /system/lib/libc.so (__libc_fini)

I/DEBUG ( 127): beb4aac4 40100eac /system/bin/testapp

I/DEBUG ( 127): beb4aac8 00000000
I/DEBUG ( 127): beb4aacc 400ff469 /system/bin/testapp

I/DEBUG ( 127): beb4aad0 beb4ab24 [stack]

I/DEBUG ( 127): beb4aad4 00000001
I/DEBUG ( 127): beb4aad8 beb4ab2c [stack]

I/DEBUG ( 127): beb4aadc 00000000
I/DEBUG ( 127): beb4aae0 df0027ad
I/DEBUG ( 127): beb4aae4 00000000
I/DEBUG ( 127): #00 beb4aae8 00000000
I/DEBUG ( 127): ........ ........

I/DEBUG ( 127): #01 beb4aae8 00000000
I/DEBUG ( 127): beb4aaec 401e9721 /system/lib/libc.so (__libc_init+40)

I/DEBUG ( 127): #02 beb4aaf0 beb4ab08 [stack]

I/DEBUG ( 127): beb4aaf4 00000000
I/DEBUG ( 127): beb4aaf8 00000000
I/DEBUG ( 127): beb4aafc 00000000
I/DEBUG ( 127): beb4ab00 00000000
I/DEBUG ( 127): beb4ab04 400ff404 /system/bin/testapp

I/DEBUG ( 127):

这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：

pid: 2102, tid: 2102,name: testapp >>>./testapp <<<
从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。

接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：

signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

signal11是Linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr 00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。

再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：

#./arm-eabi-addr2line -f -eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e

参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：

memcpy /home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

剩余三个地址翻译如下：

main /home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

out_vformat /home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

_start libgcc2.c:0

利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。

了解了如何分析普通的Log文件，下面让我们再看看如何分析ANR的Log文件。

Ⅳ android Software caused connection abort异常 手机通过wifi（ESP8266）采集数据 几个小时后报错

出现这个情况一般是客户端那边写完流后，就立即关闭了socket。服务器端这边还没读完，所以就报错了，你可以让客户端那边写完对象后，等服务器端回一个状态给客户端。客户端再关闭流。

Ⅵ 如何使用Android蓝牙开发

Android平台支持蓝牙网络协议栈，实现蓝牙设备之间数据的无线传输。本文档描述了怎样利用android平台提供的蓝牙API去实现蓝压设备之间的通信。蓝牙具有point-to-point 和 multipoint两种连接功能。
使用蓝牙API，可以做到：
* 搜索蓝牙设备
* 从本地的Bluetooth adapter中查询已经配对的设备
* 建立RFCOMM通道
* 通过service discovery连接到其它设备
* 在设备之间传输数据
* 管理多个连接

基础知识
本文档介绍了如何使用Android的蓝牙API来完成的四个必要的主要任务，使用蓝牙进行设备通信，主要包含四个部分：蓝牙设置、搜索设备（配对的或可见的）、连接、传输数据。
所有的蓝牙API在android.bluetooth包中。实现这些功能主要需要下面这几个类和接口：

BluetoothAdapter
代表本地蓝牙适配器（蓝牙发射器），是所有蓝牙交互的入口。通过它可以搜索其它蓝牙设备，查询已经配对的设备列表，通过已知的MAC地址创建BluetoothDevice，创建BluetoothServerSocket监听来自其它设备的通信。

BluetoothDevice
代表了一个远端的蓝牙设备， 使用它请求远端蓝牙设备连接或者获取 远端蓝牙设备的名称、地址、种类和绑定状态。 （其信息是封装在 bluetoothsocket 中） 。

BluetoothSocket
代表了一个蓝牙套接字的接口（类似于 tcp 中的套接字） ，他是应用程 序通过输入、输出流与其他蓝牙设备通信的连接点。

BluetoothServerSocket
代表打开服务连接来监听可能到来的连接请求 （属于 server 端） ， 为了连接两个蓝牙设备必须有一个设备作为服务器打开一个服务套接字。 当远端设备发起连 接连接请求的时候，并且已经连接到了的时候，Blueboothserversocket 类将会返回一个 bluetoothsocket。

BluetoothClass
描述了一个设备的特性（profile）或该设备上的蓝牙大致可以提供哪些服务(service)，但不可信。比如，设备是一个电话、计算机或手持设备；设备可以提供audio/telephony服务等。可以用它来进行一些UI上的提示。
BluetoothProfile

BluetoothHeadset
提供手机使用蓝牙耳机的支持。这既包括蓝牙耳机和免提（V1.5）模式。

BluetoothA2dp
定义高品质的音频，可以从一个设备传输到另一个蓝牙连接。 “A2DP的”代表高级音频分配模式。

BluetoothHealth
代表了医疗设备配置代理控制的蓝牙服务

BluetoothHealthCallback
一个抽象类，使用实现BluetoothHealth回调。你必须扩展这个类并实现回调方法接收更新应用程序的注册状态和蓝牙通道状态的变化。

Ⅶ 如何定时刷新Android界面

Handler.sendEmptyMessageDelayed(0, 1000);来实现

sendEmptyMessageDelayed：延时多少毫秒，向Handler发送信息

具体代码和效果

每隔1秒刷新一次时间

Ⅷ Android程序员的较好的职业规划应该是怎样

Android程序员的职业规划,怎么说呢？一句话叫做：早知如此，又何必当初。命运有些是自己可以掌握的，有些可能需要运气和机会。
一、路径可达
先说说路径可达这个词吧？有些人会觉得他的路看不到未来，有些人就可以清晰的看到他的方向。如果你现在所做的工作过两年会不会有所成长，达到你的目标。如果答案是否定的，那么说明现在的工作是没有上升通道的，就需要改变。当然安于现状不思进取是另外一回事。时刻反思自己所走的路，然后迅速调整，可能会少走很多弯路，毕竟时间不可逆。

二、时间规划
我有时候会想我五年后在哪里？做什么？大部分人对于这个都会比较模糊。因为时间跨度太大。五年时间相当于整个生命长河其实比较短，但在职业规划中确是很长的段，特别是刚毕业的那五年。从时间规划来讲肯定会用到时间的切分。宏观的东西只有落地到一件件事上才是有效的，才算得上完整的规划。但是话又说回来人是有惰性的，人对于这种有限制的东西有天然的排斥感，执行起来非常痛苦，即使开始执行起来很有激情，过不了几个月，所有的计划都缩水了，这同时也导致了很多时间的浪费和做事情的盲目性。所以计划的时效性和执行很重要，这里又会涉及一个词：“执行力”。
没有计划也导致学习变成一个一个孤立的点，完全没有串连性。因为你是想到学什么学什么，而不是计划着学，一段时间后可能会有一些积累，但是永远深度不够。这可以做一个简单的实验，把自己脑子里的东西理一理，如果时间需要很长说明整体知识体系已经有些混乱，可以对比一下操作系统的磁盘整理。如果一个人能很好的管理时间那么必成大牛。好学生好在哪里，排除智商的因素外，就是时间管理和善于思考。我觉得我自己最大的问题：时间管理，自律性，沟通能力。这三块是我觉得自己最缺乏一定程度上是致命的，很大程度上会决定我未来的所发展的高度。
三、项目经理还是架构师
在程序员中一直有个讨论就是将来要做项目经理还是做架构师。这两条路的侧重点不一样，所以积累的东西也可能不同。项目经理更强调综合能力，比如说协调能力，沟通能力等一系列偏管理的能力。而架构师可能更专注于技术本身，技术上的宏观方向。两条路有重叠，但是更多的是区别。有些项目经理可能就不会写代码。但是同样可以带好一个项目，一个团队。
我曾经也问自己要是以后这两条路走哪条，其实都可以尝试一下。比如说给一个项目让我带带，我能否把它带好，其实需要机会，同时也需要自己去争取这样的机会。所以我的答案就是如果有机会的话两条路都可以尝试走走，就是两个方向的一些能力都可以进行积累。很多人认为项目经理是一个职位，我倒觉得是动态的，这个项目中你做项目经理，另外一个项目中可能又是开发工程师。所以不永远是项目经理，也不永远是开发工程师。
就程序员而言，专注技术是没有任何问题的，先技术后管理。管理这个东西总的说有点虚无飘渺，各都有各的一套理论，比较难以评估。但是技术是可测量的，通过一定的努力技术水平都会有定的跃升。记得在《肖申克的救赎》里面说到地质的形成只需要两个条件：压力和时间。其实对于学技术也是一样的。只要肯学一定会达到某个水平。到大牛级别的确实需要一些悟性和天分。
四、我的选择
我为什么觉得自己应该走架构师这条路，这和我职业终极目标是契合的。这里先说一下架构师做什么？架构师负责整个项目甚至整个系统的构架（这一句话等于废话）。一般型的项目可能这个设计项目就做掉甚至可能就不需要架构。但是系统复杂度上升的时候，会涉及到系统之间的交互，还有技术的可行性和整个设计的方案。这个时候架构师就出场了。另外的工作就是承担一定的培养新人的工作。所以架构师都需要具备比较好的口才，很多人都说程序员不会说话，错了，那是低端的，到了高端的程序员口才都很好，看一下那些程序员大会中侃侃而谈的架构师们，是不是有种“高端大气上档次”的感觉。这后面会发现有一个发展方向就是“培训师”，还可以写书，其实这些都可能是一些“副产品”。技术到一定的境界很多事情到都是水到渠成。
架构师写代码吗？当然写。他们肯定不会写那些简单的代码，他们一般写什么代码？框架，一般来讲优秀的框架都是一个人或者极少人写出来的。比如说Linux的核心就是一个人写出来的。好的代码绝不是人堆出来的。你给100个初级程序员也整不出一个Struts来。这里会衍生出另外一条路，就是开源框架，很多牛人都是开源社区的爱好者。都或多或少的参与了一些开源项目。甚至把自己写的一些东西开源出来。一般来讲能做到这个级别那是相当厉害的了。

五、领域方向
我记得以前总有人问我你最擅长的领域是什么？这个问题一问我就懵了，因为我从来就没想过这个问题。可能本身还没到分领域的级别，还处于一种“原始积累”阶段。技术学到一定阶段的时候是分领域的。领域之间会有一些交叉。
我所知道的大方向是“高性能，大数据量，移到平台“。这是我给Java这所分的三个方向。其实我上面所说的三个方向不一定是同一个维度。但是我认为写Java的如果没有沾上这三个方向中的一个，一定没有前途。高性能和大数据量的处理需要比较多的技术储备。很多人说写个Java就是CRUD（严格来讲，对于计算机本身所有的操作都是CRUD）。可是在高性能情况下所涉及的问题一下成指数级增长。各种“水平扩展”，“服务化”，“容灾”，”缓存”等各种牛B的词汇就来了，你写一般的CRUD最多也就知道个SSH，这是不一样的。比如说做大数据量的处理一定会知道Hadoop，然后就是云计算，云存储。反正什么牛B什么来。移动平台和上面我所说的维度不一样，因为移动平台相对应的是PC平台。但是由于移动平台的发展时间很短。所以能搭上这趟快车也有不错的发展。要是早些年（2012年以前）进入移动平台的开发，现在同水平的程序员工资肯定更高。这是平台发展所带来的红利。虽然三年前我预见到了移动平台的无可限量，但是那时候就像一个一无所有的人，还管它什么移动平台还是PC平台，能写代码做项目就OK。以至于我学了一个月的Android就偃旗息鼓。
不管怎么样技术的底层都是一样的，所以扎实的基础是必要的，这就是为什么算法和数据结构是永恒不衰的。很多人说算法和数据结构无用那就是无知的表现。这个无知就像在讨论读大学有没有用一样。

六、总结
上面所说的一些东西可能都会比较虚，很多人都可能明白其中的道道，比如说到时间管理，这个估计从学生时代就在讲。但是真正的执行还是千差万别。所以又回归到哪里？回归到人本身。后来我想明白一件事情，即使道理再明白，没有好的执行仍然等于空谈。这里我回想起刘未鹏的《暗时间》。里面非常细致的讲了对于时间的管理。这个我读大学的时候同样在一本书《读大学，究竟读什么》里面也有所论述。当然两个方向是不一样的，一个是程序员的思维，另外一个是文科生的思维。但是道理只有一个，时间利用率的本质是什么。
另外就是实践，强烈的实践。我记得大学的时候读《人性的弱点》真是心潮澎湃，可是过不了多久我就忘了书中的内容。所以没有把书中的一些东西深刻的印记在脑海里并转化成你自己的东西，它永远只是知识。