A. 清单文件中注册时分别采用什么标签进行注册。
Androidstudio或者eclipse。通过标签注册当前活动，Androidstudio会自动注册，eclipse需要手动注册。
B. android中关于service在Manifest.xml文件中注册的问题
这个不是Service引起的，是因为你的代码中有做Activity跳转，没有找到跳转至的Activity，你没有配置该Activity.
C. Android应用组件 —— Service
官方原文： 地址 本文摘录自官方原文，方便自己观看。
service 是一个可以在后台长时间运行的操作而不提供用户界面的应用组件。服务可以由其他应用组件启动，而且即使用户切换到其他应用程序，服务仍将在后台继续运行。此外，组件可以绑定到服务，以与之进行交互，甚至执行进程间的通信（IPC）
服务基本分为两种形式：
启动
绑定
上述虽然分开概括这两种服务，但是服务可以同时以这两种方式运行，也就是说，他既可以是启动服务（以无限期运行），也允许绑定。问题在于是否实现了一组回调方法： onStartCommand() （允许组件启动服务）和 onBing() （允许绑定服务）。
无论应用是出于启动状态还是绑定状态，亦或处于启动并且绑定状态，任何应用组件均可以像使用Activity那么调用Itent来使用服务（即使此服务来自另一应用）。 不过，您可以通过清单文件将服务声明为私有服务，并阻止其他应用访问。 使用清单文件声明服务部分将对此做更详尽的阐述。
注意： 服务在其托管进程的主线程中运行，它既不创建自己的线程，也不在单独的进程中运行（除非另行指定）。这意味着，如果服务将执行任何CPU密集型工作或者阻止性操作（我理解为耗时操作，例如 MP3 播放或联网），则应在服务内创建新线程来完成这项工作。通过使用单独的线程，可以降低发生“应用无响应”(ANR) 错误的风险，而应用的主线程仍可继续专注于运行用户与 Activity 之间的交互。
要创建服务，您必须创建 Service 的子类（或使用它的一个现有子类）。在实现中，您需要重写一些回调方法，以处理服务生命周期的某些关键方面并提供一种机制将组件绑定到服务（如适用）。 应重写的最重要的回调方法包括：
onStartCommand()
onBind()
onCreate()
onDestroy()
如果组件通过调用 startService() 启动服务（这会导致对 onStartCommand() 的调用），则服务将一直运行，直到服务使用 stopSelf() 自行停止运行，或由其他组件通过调用 stopService() 停止它为止。
如果组件是通过调用 bindService() 来创建服务（且未调用 onStartCommand() ，则服务只会在该组件与其绑定时运行。一旦该服务与所有客户端之间的绑定全部取消，系统便会销毁它。
如同 Activity（以及其他组件）一样，您必须在应用的清单文件中声明所有服务。
要声明服务，请添加 <service> 元素作为 <application> 元素的子元素。例如：
为了确保应用的安全性， 请始终使用显式 Intent 启动或绑定 Service，且不要为服务声明 Intent 过滤器。 启动哪个服务存在一定的不确定性，而如果对这种不确定性的考量非常有必要，则可为服务提供 Intent 过滤器并从 Intent 中排除相应的组件名称，但随后必须使用 setPackage() 方法设置 Intent 的软件包，这样可以充分消除目标服务的不确定性。
此外，还可以通过添加 android:exported 属性并将其设置为 “false” ，确保服务仅适用于您的应用。这可以有效阻止其他应用启动您的服务，即便在使用显式 Intent 时也如此
Service
IntentService
简单地说，服务是一种即使用户未与应用交互也可在后台运行的组件。 因此，您应仅在必要时才创建服务。
如需在主线程外部执行工作，不过只是在用户正在与应用交互时才有此需要，则应创建新线程而非服务。 例如，如果您只是想在 Activity 运行的同时播放一些音乐，则可在 onCreate() 中创建线程，在 onStart() 中启动线程，然后在 onStop() 中停止线程。您还可以考虑使用 AsyncTask 或 HandlerThread，而非传统的 Thread 类。
前台服务被认为是用户主动意识到的一种服务，因此在内存不足时，系统也不会考虑将其终止。 前台服务必须为状态栏提供通知，放在“正在进行”标题下方，这意味着除非服务停止或从前台移除，否则不能清除通知。
要请求让服务运行于前台，请调用 startForeground() 。此方法采用两个参数：唯一标识通知的整型数和状态栏的 Notification 。例如：
注意 ：提供给 startForeground() 的整型 ID 不得为 0。
要从前台移除服务，请调用 stopForeground() 。此方法采用一个布尔值，指示是否也移除状态栏通知。 此方法不会停止服务。 但是，如果您在服务正在前台运行时将其停止，则通知也会被移除。
与 Activity 类似，服务也拥有生命周期回调方法，您可以实现这些方法来监控服务状态的变化并适时执行工作。 以下框架服务展示了每种生命周期方法：
注 ：与 Activity 生命周期回调方法不同，您 不 需要调用这些回调方法的超类实现。
注 ：尽管启动服务是通过调用 stopSelf() 或 stopService() 来停止，但是该服务并无相应的回调（没有 onStop() 回调）。因此，除非服务绑定到客户端，否则在服务停止时，系统会将其销毁 — onDestroy() 是接收到的唯一回调。
D. SpringCloud组件之Ribbon深入
在上一节 SpringCloud组件之Ribbon 中，实现了一个Ribbon的Helloword,使用的是Spring Eureka 和Spring Ribbon结合使用，并且使用Ribbon的默认轮询注册清单的负载均衡策略。
Ribbon参数配置通常有两种方式：全局配置和知道客户端配置
通用格式：ribbon.<key>=<value> key：表示参数名称 value：表示参数值 例如：全局配置Ribbon创建连接的超时时间
针对指定的服务进行配置 通用格式 <client>.ribbon.<key>=<value> key：表示参数名称 value：表示参数值 client：表示客户端服务的名称 例如：我们调用的Rest请求时是 http://hello-service/hello/hello ，现在我们来为服务hello-service服务指定他的实例清单（和注册中心中的服务清单一样）
下面将单独使用Spring Ribbon组件来介绍几种Ribbon负载均衡策略，单独使用Ribbon组件，不结合Eureka组件的不同之处在于，不能根据服务名称自动从Eureka的注册中心获取一个服务的实例清单，必须手动在配置文件中添加服务实例清单。
RandomRule策略：该策略实现了从服务实例清单中 随机选择 一个服务实例，作为请求服务对象。
首先创建一个SpringBoot的服务。 pom.xml
application.yaml
LoadBalanceController类
LoadBalanceMain类
启动main，在浏览器中输入 http://localhost:8015/loadbalance/hello ，多次请求，可以看到页面呈现不同的请求路径。而且这些请求都是随机出现，查看后台打印
RoundRobinRule：该策略实现了按照 线性轮询 的方式一次轮询服务清单上的每个服务实例。
结合上面的例子，修改两个部分，一个是application.yaml中 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
一个是LoadBalanceMain 中 修改ribbonRule()的返回值
RetryRule：该策略具备重试机制的实例选择功能，在给定时间内能够得到选择到具体的服务实例就返回，当超过时间还有没选到就返回null，参数maxRetryMillis控制这个超时时间。
WeightedResponseTimeRule：该策略是对RoundRobinRule的扩展，增加了根据实例的响应时间来计算权重，并从权重中选择对应的实例。该策略实现主要有三个核心内容
定时任务
WeightedResponseTimeRule策略在初始化的时候会启动一个定时任务，默认每隔30秒计算一次每个服务实例的权重
权重计算 累计所有实例的响应时间，得到总的totalResponseTime，然后为实例清单中的每个实例逐个计算权重，计算公式为 weightSoFar = weightSoFar + totalResponseTime – 该实例的平均响应时间 weightSoFar 起始为零 例子 有A，B，C，D四个实例，他们的平均响应时间是10,40,80,100， 计算总的响应时间10+40+80+100 =230 计算各个实例的权重 A: 230-10=220 B:220+(230-40)=410 C:410+(230-80)=560 D:560+(230-100)=690; 计算各个实例的权重区间 A:[0,220] B:(220,410] C:(410,560] D:(560,690)
实例选择 WeightedResponseTimeRule策略会在[0,最大权重值)之间随机选取一个数，然后在看这个数落在哪个实例的权重区间内，接着WeightedResponseTimeRule就会去选择该实例。
：该策略一般不直接使用，有些高级的策略会继承该类，完成一些高级的策略，策略默认使用 RoundRibinRule的线性轮询机制
BestAvailableRule策略继承，通过遍历负载均衡中维护的所有服务实例，会过滤掉故障实例，并找出并发数请求数最小的实例，所以该策略的特性就是选出最空闲的实例
PredicateBasedRule策略继承，该策略主要特性是“先过滤，在轮询”，也就是先过滤掉一些实例，得到过滤后的实例清单，然后轮询该实例清单，PredicateBasedRule中“过滤”功能没有实现，需要继承它的类完成，也就是说不同继承PredicateBasedRule的类有不同的“过滤特性”
AvailabilityFilteringRule策略继承PredicateBasedRule策略的“先过滤，在轮询”特性， AvailabilityFilteringRule策略的过滤特性是 1：是否故障，即断路器是否生效已断开 2：实例的并发请求数大于阈值，默认2的32次方减一，该阈值可以通过 <clientName>.<nameSpace>.ActiveConnectionsLimit来设置，只要满足其中一个那么就会过滤掉
E. android中怎么在AndroidManifest.xml文件中配置Service
第一个name是你service位置的，包括完整的包名和service名。如果包名就是你定义的程序包名，也就是和gen目录下那个包的名字一样的话，直接".service名"就可以了。第二个name是你调用service时intent.setAction();中的参数，这个你可以自己随便定义的。
F. kubernetes(九) Service介绍、类型及使用
在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。
为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。
Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后 它会将最新的Service信息转换成对应的访问规则 。
规则有iptables，ipvs等，简单介绍下ipvs规则
10.97.97.97:80 是service提供的访问入口，当访问这个入口的时候，可以发现后面有三个pod 的服务在等待调用，kube-proxy 会基于rr（轮询）的策略，将请求分发到其中一个pod上去，这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以。
kube-proxy目前支持三种工作模式: userspace 模式 userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。
iptables 模式 iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。
ipvs 模式 ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。
此模式必须安装ipvs内核模块，否则会降级为iptables，开启ipvs
Service的资源清单文件：
type：
在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置 app=nginx-pod 的标签 创建deployment.yaml，内容如下：
是集群内部地址，只能通过Node集群内部访问，创建service-clusterip.yaml文件
Endpoint
Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。
一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来， Endpoints是实现实际服务的端点集合 。换句话说，service和pod之间的联系是通过endpoints实现的。
负载分发策略 对Service的访问被分发到了后端的Pod上去，目前kubernetes提供了两种负载分发策略：
在某些场景中，开发人员可能不想使用Service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了HeadLiness Service，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。
创建service-headliness.yaml
在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是 将service的端口映射到Node的一个端口上 ，然后就可以通过 NodeIp:NodePort 来访问service了。
创建service-nodeport.yaml
LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。
ExternalName类型的Service用于引入集群外部的服务，它通过 externalName 属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。
G. 如何让android的service一直在后台运行
<serviceandroid:enabled=["true" | "false"]android:exported=["true" | "false"]android:icon="drawable resource"android:label="string resource"android:name="string"android:permission="string"android:process="string">. . .</service>被包含于（CONTAINED IN）： <application> 可能包含的元素（CAN CONTAIN）： <intent-filter> <meta-data> 说明（DESCRIPTION）： 这个元素用于声明一个服务（Service类的子类）作为应用程序的组件之一。跟Activity不一样，服务没有可见的用户界面。它们被用于实现长时的后台操作，或提供能够被其他应用程序调用的通信API。 所有的服务都必须用清单文件中的<service>元素来代表。任何没有在清单中声明的服务都不能被系统看到，也不会被运行。 属性（ATTRIBUTES）： android:enabled 这个属性用于指示该服务是否能够被实例化。如果设置为true，则能够被实例化，否则不能被实例化。默认值是true。 <application>元素有它自己的enabled属性，它的这个属性适用于应用中所有的组件，包括service组件。对于被启用的服务，<application>和<service>元素的enabled属性都必须是true（默认值都是true）。如果有一个元素的enabled属性被设置为false，该服务就会被禁用，而不能被实例化。 android:exported 这个属性用于指示该服务是否能够被其他应用程序组件调用或跟它交互。如果设置为true，则能够被调用或交互，否则不能。设置为false时，只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该服务。 它的默认值依赖与该服务所包含的过滤器。没有过滤器则意味着该服务只能通过指定明确的类名来调用，这样就是说该服务只能在应用程序的内部使用（因为其他外部使用者不会知道该服务的类名），因此这种情况下，这个属性的默认值是false。另一方面，如果至少包含了一个过滤器，则意味着该服务可以给外部的其他应用提供服务，因此默认值是true。 这个属性不是限制把服务暴露给其他应用程序的唯一方法。还可以使用权限来限制能够跟该服务交互的外部实体。 android:icon 这个属性定义了一个代表服务的图标，它必须要引用一个包含图片定义的可绘制资源。如果这个属性没有设置，则会使用<application>元素的icon属性所设定的图标来代替。 无论是<application>元素设置的图标，还是<service>元素所设置的图标，它们都是该服务所有的Intent过滤器的默认图标。 android:label 这个属性用于设定一个要显示给用户的服务的名称。如果没有设置这个属性，则会使用<application>元素的label属性值来代替。 无论是<service>设定的标签，还是<application>元素设定的标签，它们都是该服务所有的Intent过滤器的默认标签。 这个标签应用引用一个字符串资源，以便它能够像用户界面中的字符串一样能够被本地化。但是，为了开发应用程序方便，也可以使用原生字符串来设置这个属性。 android:name 这个属性用于指定实现该服务的Service子类的类名。它应该是完整的Java类名（如：com.example.project.RoomService）。但是，也可以使用简写（如：.RoomService），系统会把<manifest>元素中package属性所设定的值添加到简写名称的前面。 一旦发布了应用程序，就不应该改变这个名称（除非android:exported=”false”）。 这个属性没有默认值，名称必须要指定。 android:permission 这个属性定义了要启动或绑定服务的实体必须要有的权限。如果调用者的startService()、bindService()和stopService()方法没有被授予这个权限，那么这些方法就不会工作，并且Intent对象也不会发送给改服务。 如果这个属性没被设置，那么通过<appliction>元素的permission属性所设定的权限就会适用于该服务。如果<application>元素也没有设置权限，则该服务不受权限保护。 android:process 这个属性用于设定服务所运行的进程名称。通常，应用程序的所有组件都运行在给应用程序创建的进程中，进程名与应用程序的包名相同。<application>元素的process属性能够给应用程序的所有组件设置一个不同的默认名称。但是每个组件自己的process属性都能够覆盖这个默认值，这样允许把应用程序分离到不同的多个进程中。 如果这个属性值用“:”开头，则在需要的时候系统会创建一个新的，应用程序私有的进程，并且该服务也会运行在这个进程中。如果这个属性值用小写字母开头，那该服务就会运行在以这个属性值命名的全局进程中，它提供了使其工作的权限。这样就允许不同的应用程序组件来共享这个进程，从而降低资源的使用。 再说几个service的属性标识 android:isolatedProcess="true" ，官方解释：通过指定的[[android:isolatedProcess="true"]]中的[[<service>]]标签，您的[[Service]]将在没有自身权限的被隔离的用户ID进程下运行。在android4.1中出现隔离服务 ，说明这个service将在被隔离的用户id进程中运行。如何使用Messagezai service li final Messenger mMessenger = new Messenger(new IncomingHandler());public IBinder onBinder(Intent intent){return mMessenger.getBinder();}在activity里的onServiceConnected方法里得到服务Messenger的引用mServiceMessenger = new Messenger(service);//向service注入本activity的Messenger的引用 Message msg = Message.obtain(null, MessengerService.MSG_REGISTER_CLIENT); msg.replyTo = mMessenger; //主要是通过replyTo将Messenger引用传过去 mService.send(msg);这样，远程服务就可以与本activity进行通信了，而且不需要写aidl方法
H. 投标服务配置清单怎么填
服务类投标文件的报价明细表如何填的相关内容如下，供您参考希望对您有帮助。1、封面工程量清单投标报价封面(投标总价表)应按规范格式填写完整，要求法定代表人或其授权人签字或盖章;编制清单的造价人员(造价工程师或造价员)签字盖执业专用章。2、总说明总说明的内容应包括：(1)采用的计价依据;(2)采用的施工组织设计;(3)综合单价中包含的风险因素，风险范围(幅度);(4)措施项目的依据;(5)其他有关内容的说明等。3、投标报价汇总表投标报价汇总表分为工程项目投标报价汇总表、单项工程投标报价汇总表、单位工程投标报价汇总表。(1)工程项目投标报价汇总表表中单项工程名称应按单项工程投标报价汇总表的工程名称填写。表中金额应按单项工程投标报价汇总表的合计金额填写。(2)单项工程投标报价汇总表表中单位工程名称应按单位工程投标报价汇总表的工程名称填写。表中金额应按单位工程投标报价汇总表的合计金额填写。(3)单位工程投标报价汇总表单位工程投标报价汇总表中的金额应分别按照分部分项工程量清单计价表、措施项目清单计价表、其他项目清单计价汇总表、规费和税金项目清单计价表的合计金额填写。需要特别注意的是，投标报价汇总表与投标函中投标报价金额应当一致。就投标文件的各个组成部分而言，投标函是最重要的文件，其他组成部分都是投标函的支持xing文件，投标函是必须经过投标人签字，并且在开标会上必须当众宣读的文件。如果投标报价汇总表的投标总价与投标函填报的投标总价不一致，应当以投标函中填写的大写金额为准。实践中，对该原则广直缺少一个明确的依据，为了避免出现争议，可以在“投标人须知”中给予明确，用在招标文件中约定的方式来弥补法律、法规依据的不足。
I. android xml配置文件中一些标签的作用
第一个xml是控件动画的xml，interpolator设置动画播放的速度模型，这个设置的是播放速度逐渐变慢。第一个scale是缩放的动画，ration是动画时间，从0.9倍放大到1倍，pivot是指参照哪个点进行缩放，这个设置的50%是指中心。alpha是改变透明度的动画，从0完全透明到1完全不透明。第二个xml官方叫法是背景选择器，就是改变按钮之类的控件在选中、获得焦点及通常状态时的背景的，可以是纯色，也可以像你这个似的是drawable中的图片。在选择背景时从上到下找到第一个符合条件的为准，state_之类的是各种条件，pressed按下，focused获得焦点，等等，最后一个item是表示默认条件即之前条件都不满足时的背景。
J. Android app的渠道包是什么意思
1、渠道包： 渠道包指的是在各大应用市场，发布的apk包的清单文件中，某个meta-data标签下，配置的value不一样，这个标签的作用就是用来区分是哪个市场的，比如你发布到360.这个值就是你就可以配置成360，豌豆荚就可以配置成wandoujia，那么这么配置的作用是干嘛的？很简单，就是用来做统计的，比如我们项目中用的是友盟统计，它可以统计用户从哪个平台下载了你们的app，从而更好的掌握用户的操作习惯。所以，如果app没有统计功能的需求，你只需要打一个同样的包，直接发布到各个平台即可，根本不用关心什么渠道。2、首发渠道包的含义我并不理解，字面的意思可能是说 在同一个apk版本中，有些渠道平台拥有优先体验最新版本的权限，那么这些平台就是首发平台，之后过了一个星期，才将这个apk发布到另外一些的平台。3、抓包 首先要明白，抓包和渠道包没有半点关系。 抓包指的是我们在请求服务器的时候，发出去的所有请求我都可以直观的看到，包括请求的地址，请求头，请求体，以及服务器返回的结果：响应头，响应体等等。这个从不可见到直观可见的抓取过程，才是抓包。 抓包的主要作用是方便与服务端人员的配合。Windows比较好用的抓包工具是Filder，OS可以使用Charles（收费）。
