android中的service本质是一个类还是一个方法还是一个对象
当然我明白java中一切都是对象的这种说法
service在哪里看到的，作为类的定义它是类，对它实例化创建了对象并且执行就是对象了。
java中一切都是对象
这个说法其实不准确。你能说java中的关键字是对象么？
/*
package android.app;
import android.annotation.Nullable;
import android.content.ComponentCallbacks2;
import android.content.ComponentName;
import android.content.Intent;
import android.content.ContextWrapper;
import android.content.Context;
import android.content.res.Configuration;
import android.os.Build;
import android.os.RemoteException;
import android.os.IBinder;
import android.util.Log;
import java.io.FileDescriptor;
import java.io.PrintWriter;
/**
AndroidManifest.xml. ServicesNote that services, like other application objects, run in the main
Topics covered here:
For a detailed discussion about how to create services, read the
Most confusion about the Service class actually revolves around what
Thus a Service itself is actually very simple, providing two main features:
When a Service component is actually created, for either of these reasons,
all that the system actually does is instantiate the component and call its {@link #onCreate} and any other appropriate callbacks on the main thread. It is up to the Service to implement these with the appropriate behavior, such as creating a secondary thread in which it does its work.Note that because Service itself is so simple, you can make your
interaction with it as simple or complicated as you want: from treating it as a local Java object that you make direct method calls on (as illustrated by Local Service Sample), to providing a full remoteable interface using AIDL.There are two reasons that a service can be run by the system. If someone
calls {@link android.content.Context#startService Context.startService()} then the system will retrieve the service (creating it and calling its {@link #onCreate} method if needed) and then call its {@link #onStartCommand} method with the arguments supplied by the client. The service will at this point continue running until {@link android.content.Context#stopService Context.stopService()} or {@link #stopSelf()} is called. Note that multiple calls to Context.startService() do not nest (though they do result in multiple corresponding calls to onStartCommand()), so no matter how many times it is started a service will be stopped once Context.stopService() or stopSelf() is called; however, services can use their {@link #stopSelf(int)} method to ensure the service is not stopped until started intents have been processed.For started services, there are two additional major modes of operation
they can decide to run in, depending on the value they return from onStartCommand(): {@link #START_STICKY} is used for services that are explicitly started and stopped as needed, while {@link #START_NOT_STICKY} or {@link #START_REDELIVER_INTENT} are used for services that should only remain running while processing any commands sent to them. See the linked documentation for more detail on the semantics.Clients can also use {@link android.content.Context#bindService Context.bindService()} to
obtain a persistent connection to a service. This likewise creates the service if it is not already running (calling {@link #onCreate} while doing so), but does not call onStartCommand(). The client will receive the {@link android.os.IBinder} object that the service returns from its {@link #onBind} method, allowing the client to then make calls back to the service. The service will remain running as long as the connection is established (whether or not the client retains a reference on the service's IBinder). Usually the IBinder returned is for a complex interface that has been written in aidl.A service can be both started and have connections bound to it. In such
a case, the system will keep the service running as long as either it is started or there are one or more connections to it with the {@link android.content.Context#BIND_AUTO_CREATE Context.BIND_AUTO_CREATE} flag. Once neither of these situations hold, the service's {@link #onDestroy} method is called and the service is effectively terminated. All cleanup (stopping threads, unregistering receivers) should be complete upon returning from onDestroy().Global access to a service can be enforced when it is declared in its
manifest's {@link android.R.styleable#AndroidManifestService <service>} tag. By doing so, other applications will need to declare a corresponding {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>} element in their own manifest to be able to start, stop, or bind to the service. *As of {@link android.os.Build.VERSION_CODES#GINGERBREAD}, when using
{@link Context#startService(Intent) Context.startService(Intent)}, you can also set {@link Intent#FLAG_GRANT_READ_URI_PERMISSION Intent.FLAG_GRANT_READ_URI_PERMISSION} and/or {@link Intent#FLAG_GRANT_WRITE_URI_PERMISSION Intent.FLAG_GRANT_WRITE_URI_PERMISSION} on the Intent. This will grant the Service temporary access to the specific URIs in the Intent. Access will remain until the Service has called {@link #stopSelf(int)} for that start command or a later one, or until the Service has been completely stopped. This works for granting access to the other apps that have not requested the permission protecting the Service, or even when the Service is not exported at all. *In addition, a service can protect individual IPC calls into it with
permissions, by calling the {@link #checkCallingPermission} method before executing the implementation of that call.See the Security and Permissions
document for more information on permissions and security in general.The Android system will attempt to keep the process hosting a service
around as long as the service has been started or has clients bound to it. When running low on memory and needing to kill existing processes, the priority of a process hosting the service will be the higher of the following possibilities: *If the service is currently executing code in its
{@link #onCreate onCreate()}, {@link #onStartCommand onStartCommand()}, or {@link #onDestroy onDestroy()} methods, then the hosting process will be a foreground process to ensure this code can execute without being killed.If the service has been started, then its hosting process is considered
to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed except in low memory conditions. However, since the user is not directly aware of a background service, in that state it is considered a valid candidate to kill, and you should be prepared for this to happen. In particular, long-running services will be increasingly likely to kill and are guaranteed to be killed (and restarted if appropriate) if they remain started long enough.If there are clients bound to the service, then the service's hosting
process is never less important than the most important client. That is, if one of its clients is visible to the user, then the service itself is considered to be visible. The way a client's importance impacts the service's importance can be adjusted through {@link Context#BIND_ABOVE_CLIENT}, {@link Context#BIND_ALLOW_OOM_MANAGEMENT}, {@link Context#BIND_WAIVE_PRIORITY}, {@link Context#BIND_IMPORTANT}, and {@link Context#BIND_ADJUST_WITH_ACTIVITY}.A started service can use the {@link #startForeground(int, Notification)}
API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)Note this means that most of the time your service is running, it may
be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service. An important consequence of this is that if you implement {@link #onStartCommand onStartCommand()} to schedule work to be done asynchronously or in another thread, then you may want to use {@link #START_FLAG_REDELIVERY} to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it.Other application components running in the same process as the service
(such as an {@link android.app.Activity}) can, of course, increase the importance of the overall process beyond just the importance of the service itself.One of the most common uses of a Service is as a secondary component
running alongside other parts of an application, in the same process as the rest of the components. All components of an .apk run in the same process unless explicitly stated otherwise, so this is a typical situation.When used in this way, by assuming the
components are in the same process, you can greatly simplify the interaction between them: clients of the service can simply cast the IBinder they receive from it to a concrete class published by the service.An example of this use of a Service is shown here. First is the Service
itself, publishing a custom class when bound: {@sample development/samples/ApiDemos/src/com/example/android/apis/app/LocalService.java service}With that done, one can now write client code that directly accesses the
running service, such as: {@sample development/samples/ApiDemos/src/com/example/android/apis/app/LocalServiceActivities.java bind}If you need to be able to write a Service that can perform complicated
communication with clients in remote processes (beyond simply the use of {@link Context#startService(Intent) Context.startService} to send commands to it), then you can use the {@link android.os.Messenger} class instead of writing full AIDL files.An example of a Service that uses Messenger as its client interface
is shown here. First is the Service itself, publishing a Messenger to an internal Handler when bound: {@sample development/samples/ApiDemos/src/com/example/android/apis/app/MessengerService.java service}If we want to make this service run in a remote process (instead of the
standard one for its .apk), we can useandroid:process in its manifest tag to specify one: {@sample development/samples/ApiDemos/AndroidManifest.xml remote_service_declaration}Note that the name "remote" chosen here is arbitrary, and you can use
other names if you want additional processes. The ':' prefix appends the name to your package's standard process name.With that done, clients can now bind to the service and send messages
to it. Note that this allows clients to register with it to receive messages back as well: {@sample development/samples/ApiDemos/src/com/example/android/apis/app/MessengerServiceActivities.java bind}
*/
public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {
private static final String TAG = "Service";
public Service() {
super(null);
}
/** Return the application that owns this service. */
public final Application getApplication() {
return mApplication;
}
/**
/**
/**
/**
/**
This mode makes sense for things that will be explicitly started
/**
This mode makes sense for things that want to do some work as a
/**
/**
/**
/**
/**
For backwards compatibility, the default implementation calls
If you need your application to run on platform versions prior to API
handleCommand method is implemented byNote that the system calls this on your
/**
public void onConfigurationChanged(Configuration newConfig) {
}
public void onLowMemory() {
}
public void onTrimMemory(int level) {
}
/**
Note that unlike other application components, calls on to the
/**
/**
/**
/**
/**
/**
Be careful about ordering of your calls to this function..
/**
/**
If you need your application to run on platform versions prior to API
/**
/**
// ------------------ Internal API ------------------
/**
final String getClassName() {
return mClassName;
}
// set by the thread after the constructor and before onCreate(Bundle icicle) is called.
private ActivityThread mThread = null;
private String mClassName = null;
private IBinder mToken = null;
private Application mApplication = null;
private IActivityManager mActivityManager = null;
private boolean mStartCompatibility = false;
}
Service(服务)是Android 核心组件之一,特点就是Android系统帮你实例化他的对象(就是 new 在内存中开辟空间来保存对象 )
使用它首先要在你的项目里创建一个类继承Android的Service类,还需要在清单配置文件中注册这个类
Android系统才能够通过反射找到这个Service类并创建对象
类就相当于一张汽车设计图(封装属性和方法),设计汽车有什么属性(变量),什么功能(方法)
如果你想要根据这个设计图生产出一辆能跑的车,就需要 new 创建这个类的对象
通过这个对象才能够调用一些方法,比如刹车.
public class Car{
//车的颜色
String color;
//车的重量
int heavy;
public void run(){
//怎么跑
}
public void stop(){
//怎么刹车
}
}
Car BMW = new Car();
BMW.run();
BMW.stop();