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進程中運行。
如何使用Message
zai 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（收費）。