A. 安卓的service可以单例吗
service不需要单例，因为如果已经启动了服务再次启动的时候是不会执行onCreate的，只会执行onStart，只会有一个服务
B. android 开发中常用到的设计模式有哪些
设计模式总共是23种，常用的有下面几种 ：
1 单例模式，application 就是单例 可以存储一些数据例如记录activity的启动数量 ；
2 观察者模式： button的onClickListener ，监听button的响应；
3 适配器模式 ：例如recyclerView 的adapter ；
4 命令模式： 例如开源库eventBus ，把数据封装好 发送出去，然后接收； 等等等等，很多
C. android studio单例怎么使用
android studio使用单例的情况有很多，大多数是工具类，可以使用单例，里面有很多static方法，很方便的使用这些方法。
D. android 单例模式 什么时候被杀死 单例的那个对象 什么时候消失啊
我来补充下楼上:
进程关闭的时机是:
1.用Process.kill或者shell去杀死进程
2.系统通过memory策略来杀死后台进程。
说说第二种吧，当程序按Home键或者Back键退出后就变做后台进程。
另外，当程序启动了新的进程。而新的进程进入前台模式，此时程序也变成后台进程。
当前台进程退出，后台进程按照堆栈结构再次呈现时。很可能是个重启进程的过程，重启进程意味着单例对象也重新初始化了。这点要尤其谨慎
E. 如何使用android单例模式
java模式之单例模式：
单例模式确保一个类只有一个实例，自行提供这个实例并向整个系统提供这个实例。
特点：
1，一个类只能有一个实例
2，自己创建这个实例
3，整个系统都要使用这个实例
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。在很多操作中，比如建立目录
数据库连接都需要这样的单线程操作。一些资源管理器常常设计成单例模式。
外部资源：譬如每台计算机可以有若干个打印机，但只能有一个Printer
Spooler,以避免两个打印作业同时输出到打印机中。每台计算机可以有若干个通信端口，系统应当集中管理这些通信端口，以避免一个通信端口被两个请求同时调用。内部资源，譬如，大多数的软件都有一个（甚至多个）属性文件存放系统配置。这样的系统应当由一个对象来管理这些属性文件。
一个例子：Windows
回收站。
在整个视窗系统中，回收站只能有一个实例，整个系统都使用这个惟一的实例，而且回收站自行提供自己的实例。因此，回收站是单例模式的应用。
两种形式：
1，饿汉式单例类
public class Singleton {
private Singleton(){}
//在自己内部定义自己一个实例，是不是很奇怪？
//注意这是private 只供内部调用
private static Singleton instance =
new Singleton();
//这里提供了一个供外部访问本class的静态方法，可以直接访问
public static Singleton getInstance() {
return instance;
}
}
2，懒汉式单例类
public class Singleton {
private static Singleton instance = null;
public static synchronized Singleton
getInstance() {
//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次
//使用时生成实例，提高了效率！
if (instance==null)
instance＝new Singleton();
return instance; }
}
第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。
注意到lazy
initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。
一般来说第一种比较安全
我自己比较常用的方式：
public class Singleton {
private volatile static
Singleton singleton;
private Singleton(){}
public static Singleton getInstance(){
if(singleton==null){
synchronized(Singleton.class){
if(singleton==null){
singleton=new Singleton();
}
}
}
return singleton;
}
}
F. android之单例模式：懒汉式和饿汉式的区别
比较:
饿汉式是线程安全的,在类创建的同时就已经创建好一个静态的对象供系统使用,以后不在改变。
懒汉式如果在创建实例对象时不加上synchronized则会导致对对象的访问不是线程安全的。
G. android service是单例吗
android service不存在单列的问题，service是安卓一个组件。单例是一种设计模式。
1、在实际运行中同样的Service的确只能有一个。
2、Service类没有必要运用单例模式。
H. 安卓的service可以单例吗
这要看你的service是通过什么方式启动的 一：如果你通过startService()方式启动的话，那么当你关闭了activity之后 你的service依然还在运行当中。 二：如果你通过bindService()方式启动的话，那么他是跟随activity一起绑定的，那么也就是说当activity销毁的时候这个service也跟随一起销毁了！ 你可以看看 application 这个也挺好使用的 ，可以当做全局的回调对象使用！
I. 结合Android看看单例模式怎么写
单例模式常见的两种实现方式 饿汉模式和 双重锁模式
•饿汉模式
public class HungrySingleton {
private static HungrySingleton mInstance = new HungrySingleton();
private HungrySingleton() {
}
public static HungrySingleton getInstance() {
return mInstance;
}
}
不得不说，饿汉模式这个名字起得的确很巧，这种方式，不管你用不用得着这个实例，先给你创建（new）出来，生怕将来创建没机会似得，完全就是今朝有酒今朝醉的节奏。
与上面对应的还有一种就是懒汉模式，就是在用的时候才在getInstance 方法中完成实例的创建（new），真是“懒”，同时给这个方法添加synchronized 关键字，可以确保在多线程情况下单例依旧唯一，但是懒汉模式每次调用getInstance 方法时由于synchronized 的存在，需要进行同步，造成不必要的资源开销。因此便有了下面双重锁模式的实现方式。
•双重锁模式（DCL 实现）
public class LazySingleton {
private static LazySingleton mInstance = null;
private LazySingleton() {
}
public static LazySingleton getInstance() {
if (mInstance == null) {
synchronized (LazySingleton.class) {
if (mInstance == null) {
mInstance = new LazySingleton();
}
}
}
return mInstance;
}
}
这样既避免了饿汉模式的缺点，又解决了懒汉模式的不足；确保单例只在第一次真正需要的时候创建。
Android 中的使用
在日常的Android开发中，也可以见到单例模式的身影。
•Glide
使用Glide加载图片非常方便，大家应该不陌生，可以看一下它的源码中单例模式的实现方式。
Glide.with(this).load(url).into(imageView);
//Glide.with()
public static RequestManager with(FragmentActivity activity) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(activity);
}
//RequestManagerRetriever.get()
/** The singleton instance of RequestManagerRetriever. */
private static final RequestManagerRetriever INSTANCE = new RequestManagerRetriever();
/**
* Retrieves and returns the RequestManagerRetriever singleton.
*/
public static RequestManagerRetriever get() {
return INSTANCE;
}
可以看到，当我们写下Glide.with(..) 这行代码时，就完成了RequestManagerRetriever 这个类的实例化，这个类的单例模式是使用饿汉模式实现的。
•EventBus
public static EventBus getDefault() {
if (defaultInstance == null) {
synchronized (EventBus.class) {
if (defaultInstance == null) {
defaultInstance = new EventBus();
}
}
}
return defaultInstance;
};
很明显，EventBus的单例模式使用双重锁模式实现的。
•InputMethodManager static InputMethodManager sInstance
public static InputMethodManager getInstance() {
synchronized (InputMethodManager.class) {
if (sInstance == null) {
IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);
IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);
sInstance = new InputMethodManager(service, Looper.getMainLooper());
}
return sInstance;
}
}
InputMethodManager 的单例模式是使用懒汉模式实现。
可以看到，关于单例模式的实现方式，面对不同的场景，我们可以做出不同的选择
•Glide的单例模式虽然是使用饿汉模式实现，但理论上来说并不会造成内存资源的浪费，因为当我们通过gradle的配置引入Glide的库时，就是为了加载图片，必然会使用Glide.with进行相关的操作。同时RequestManagerRetriever 这个类应该是一个网络请求的管理类（Glide源码没有研究过，这里只是猜测），这样的一个类必然需要使用单列模式，试想如果存在多个管理类的实例，那么谈何管理，那么的多Request到底听哪个manger 的，这就是前面提到必须使用单列模式的情景。
•EventBus 作为事件总线的更要使用单例模式了，如果说EventBus的实例不是单例模式，那么他就无法实现它的功能了。对于EventBus不了解的同学，可以看看
EventBus 3.0 相见恨晚，EventBus真的很强大。
•InputMethodManager 使用懒汉模式实现单例也是无可厚非的，毕竟谁会去频繁的获取那么多他的实例呢；同时作为一个系统的输入法管理器，他也必须是唯一的，因此这个类也需要单例模式来实现它唯一的实例供外部使用。
由上可见，关于单例模式的实现，没有说哪一种方式最好，只有最合适的实现方式；实际开发中，单例模式应该怎么写，还需要根据业务场景做最合适的选择，无论是饿汉懒汉实用才是好汉。个人感觉，饿汉模式是一种简单又方便的实现方式， 一个类既然已经写成了单例模式，必然是要使用的呀，谁会去创建一个饿汉模式的单例，又不去使用这个单例呢？
之前在使用Volley的时候，就是使用饿汉模式创建整个应用的RequestQueue单例，所有需要网络请求的地方，把request添加到RequestQueue单例中即可。
public class MyApplication extends Application{
// 建立请求队列
public static RequestQueue queue;
@Override
public void onCreate() {
super.onCreate();
queue = Volley.newRequestQueue(getApplicationContext());
}
public static RequestQueue getHttpQueue() {
return queue;
}
}
在应用Application的onCreate方法中创建了属于整个应用的queue，之后每一次网络请求时，只需要queue.add(Request)即可，这里使用单例模式，可以有效的避免在多个地方创建RequestQueue 的实例，浪费系统资源。
J. Android图形系统（六）-app与SurfaceFlinger服务连接过程
经过上一篇的概览，我们对Android图形系统渲染流程有了一个大致的了解，这篇开始做细节分析。那么先来总结下app与SurfaceFlinger服务连接过程。
经过前面的activity 、window 、view 的分析我们大致了解了Activity的显示过程。其实Surface的创建过程与Activity的显示过程密不可分。
那么就从Activity.makeVisible 开始捋下流程：
1 Activity.makeVisible getWindowManager() 并执行addView。
2 经过WindowManagerImpl 和 WindowManagerGlobal addView , 最终创建了ViewRootImpl
3 ViewRootImpl 内部会new Surface() ，它是一个Parcelable对象，可在进程间传递，但目前仅是一个空壳，还未被赋值。
同时，通过WindowManagerGlobal.getWindowSession()获取了Session实例，准备好了与WMS通信，并且Session内有个成员变量SurfaceSession值得关注，它的初始化是在Session的windowAddedLocked方法，先埋个伏笔。
4 根据流程我们知道，最终ViewRootImpl会在走setView, 在这个方法中开始了两个流程：
requestLayout执行会走消息，因此它虽然在addToDisplay前面，但是执行是在之后的，因此我们先来看看mWindowSession.addToDisplay，这个过程最终是在WMS执行addWindow方法：
我们之前埋过伏笔的，windowAddedLocked创建了SurfaceSession 对象，并将当前 Session 添加到 WMS.mSessions 成员变量。SurfaceSession 的创建会调用 JNI，在 JNI 调用 nativeCreate()。
从这里开始要细说下了，这是应用程序与SurfaceFlinger建立连接的关键点：
跟踪到android_view_SurfaceSession.cpp 的nativeCreate()方法，创建了SurfaceComposerClient 对象,并且将这个对象赋值给类型为sp<SurfaceComposerClient>的智能指针mSession时，就会导致SurfaceComposerClient类的成员函数onFirstRef被调用：
SurfaceComposerClient类的成员函数getComposerService用来获得SurfaceFlinger服务的一个代理接口.
ComposerService类是单例模式，当我们第一次调用它的静态函数getInstance的时候，它就会在构造函数中获得SurfaceFlinger服务的一个代理接口，并且保存在它的成员变量mComposerService中，同时会通过这个代理接口的成员函数getCblk来获得一块匿名共享内存mServerCblkMemory。这块匿名共享内存是由SurfaceFlinger服务创建的，用来描述系统显示屏的信息，例如，显示屏的个数、大小、方向、密度等等信息。
这时候sm有值了，在接着onFirstRef()往下执行：
是不是感觉特别绕，下面来简单总结下：
首先ComPoserService作为client 与 SurfaceFlinger server进行binder IPC , 获取到SurfaceFlinger创建的Client对象，它相当于是SurfaceFlinger内部对应用程序客户端的封装对象，而Client与SurfaceComposerClient又互为binder ipc的两端，SurfaceComposerClient为client端，Client为server端。
这样，应用进程成功通过SurfaceComposerClient与SurfaceFlinger建立了连接。
下篇分析app请求SurfaceFlinger创建Surface过程。
参考：
https://blog.csdn.net/Luoshengyang/article/details/7857163
https://blog.csdn.net/armwind/article/details/73436532