綠色公約是AppSo與綠色守護(hù)聯(lián)合推出的一款綠色應(yīng)用軟件，主要是為了改善安卓手機卡、耗電快的問題，目前已有2萬多的支持，認(rèn)證的應(yīng)用也有13個，可以說是安卓手機的救星，有興趣的可以下載安卓綠色公約app體驗一下。

什么是綠色公約

自從推出這個公約后，AppSo 的后臺收到最多的質(zhì)疑是：這件事情太理想主義了，不僅是 Google 在國內(nèi)缺失的問題，還有背后行業(yè)利益鏈等問題，能成事的機會實在太渺茫了。

但在 Oasis Feng 心中，綠色守護(hù)（Greenify）這個產(chǎn)品，本身就是一次理想主義的嘗試。

它是一個誕生于 2012 年業(yè)余開發(fā)的小工具，如今已經(jīng)走過了近 5 年的道路。5 年的堅持，最大的動力還是源于用戶的支持和那份單純的捐贈。

相比五年前，Android 生態(tài)早已今非昔比，廠商和開發(fā)者間的斗爭，用戶成了最大的犧牲者，我們的手機內(nèi)存被大量重復(fù)的后臺推送服務(wù)給塞滿，國外 2G 內(nèi)存的手機就能流暢使用，在國內(nèi)連翻一番都捉襟見肘。

這場無盡之戰(zhàn)已深陷囚徒困境，每一個局中人都明知這是玉石俱焚，任何一方都無路可退。究其根源，還是互聯(lián)網(wǎng)長期被扭曲的商業(yè)模式塑造了這一切，早已埋下了這一死局的種子。

這就是「綠色應(yīng)用公約」的誕生背景：先讓一部分有良知有擔(dān)當(dāng)?shù)膽?yīng)用團(tuán)隊，在保全流量利益的大前提下，卸去對設(shè)備體驗的傷害，轉(zhuǎn)而再推動手機廠商卸去它們對這部分應(yīng)用的敵意和束縛，從而讓雙方都有機會攜手創(chuàng)造一個更加良性的國內(nèi) Android 生態(tài)。

今年初，我回阿里去做過一個內(nèi)部分享，其中一個主題是談的「流量圈地時代的終結(jié)，對移動應(yīng)用的發(fā)展會有什么沖擊」。實際上，當(dāng)流量圈地結(jié)束后，將迎來的是刺刀見紅的注意力肉搏戰(zhàn)。你搶奪的每一分用戶注意力，都是別人損失的用戶注意力。

移動應(yīng)用最懼怕的用戶流失是什么？顯然是卸載。所以，好死不如賴活著，跪舔用戶的時代大潮很快就要到來了；其次是「打開率」的問題，當(dāng)應(yīng)用被大量后臺凍結(jié)、休眠后，也喪失了主動激活用戶的機會。

當(dāng)然，這個趨勢肯定不是從巨頭開始的，畢竟他們的提供了用戶無法割舍的服務(wù)。但是，行業(yè)中的先知先覺者，已經(jīng)意識到即將到來的問題，開始行動了。

綠色守護(hù)聯(lián)合 AppSo 推出的「綠色應(yīng)用公約」，正是看準(zhǔn)了這個時代轉(zhuǎn)變的契機，給中小應(yīng)用一個讓用戶無需卸載的理由，和免于被休眠的機會；給行業(yè)第二、第三的挑戰(zhàn)者一個虎口拔牙的武器。

綠色公約介紹

宗旨

這是一項旨在推動Android生態(tài)中的優(yōu)秀應(yīng)用共同維護(hù)一個更加良性的『設(shè)備體驗』而發(fā)起的開放公約。

設(shè)備體驗：影響效應(yīng)超出用戶與應(yīng)用進(jìn)行顯性交互的過程之外，在用戶感知中屬于設(shè)備整體性的體驗因素的總稱。包括設(shè)備的安全性、整體流暢性、耗電程度、發(fā)熱程度等。

由于Android系統(tǒng)的設(shè)備體驗是由設(shè)備本身的軟硬件及安裝在設(shè)備中的眾多應(yīng)用所共同影響的，后者的影響往往隨著安裝的應(yīng)用數(shù)量增長而迅速擴(kuò)大。這種由應(yīng)用所造成的外溢性影響，存在著典型的 『公地悲劇』 。安裝的眾多應(yīng)用中，某一個應(yīng)用對于設(shè)備體驗的損害往往很難被用戶直接辨識，以至設(shè)備體驗問題長期得不到應(yīng)用開發(fā)團(tuán)隊的足夠重視。造成的后果間接的由全部應(yīng)用，乃至整個Android生態(tài)共同承擔(dān)。

因此，除了加強用戶對于設(shè)備體驗損害的辨識能力外，有必要推動整個Android開發(fā)社區(qū)以更高的標(biāo)準(zhǔn)優(yōu)化各自應(yīng)用的設(shè)備體驗影響，共同維護(hù)一個良性的Android生態(tài)。

開放編撰

此公約的內(nèi)容修訂和擴(kuò)充面向整個Android開發(fā)社區(qū)，采取開放接納、充分討論、積極修訂的原則。如果對規(guī)約有任何的疑問（包括實施中的困難）和建議，請通過此公約的 GitHub issue tracker 提交。

核心原則

此公約的核心原則完全遵照Android本身的演進(jìn)方向（包括 Android O 所引入的新變化），積極引導(dǎo)和協(xié)助應(yīng)用開發(fā)團(tuán)隊平滑完成對接Android最新變化的節(jié)奏，在確保應(yīng)用核心功能不受影響的前提下，減少不必要的應(yīng)用后臺行為，并以更加高效、節(jié)能的調(diào)度機制改善后臺行為的調(diào)度。

涉及到功能與設(shè)備體驗之間的潛在沖突時，遵循最終選擇權(quán)給予用戶的原則。

規(guī)約

必要部分

1， Target SDK Version >= 24 (Android 7.0)

原因：Project Svelte在Android 7中得到了一些關(guān)鍵的的強化，有助于降低應(yīng)用后臺行為對設(shè)備體驗的影響。

2， 不在運行時強制請求『讀取手機狀態(tài)和身份（READ_PHONE_STATE）』權(quán)限。

原因：IMEI泄露是目前用戶隱私和手機安全中的一個突出問題。它具有相當(dāng)?shù)碾[蔽性，在Android 6.0之后的運行期權(quán)限體系中依然未能獲得足夠清晰的信息披露。由于Android系統(tǒng)僅僅將其顯示為『讀取手機狀態(tài)和身份』，使得大部分用戶在應(yīng)用請求此項權(quán)限時雖然困惑，但仍未意識到授予這個權(quán)限背后存在的安全隱患。

若應(yīng)用中的某些功能（如通話相關(guān)的特性）依賴此權(quán)限（須具備邏輯上的合理性），則只能在對應(yīng)功能交互中請求此權(quán)限。即便用戶拒絕授予權(quán)限，不依賴此權(quán)限的功能仍須保持可用。

3， 除用戶的主動交互觸發(fā)外，避免啟動其它應(yīng)用未處于運行中的進(jìn)程。

原因：用戶在主動交互中通常對交互的響應(yīng)時間（例如從觸摸到界面變化）存在一定的寬容度，而被動交互（例如啟動過程的等待、媒體播放中）中出現(xiàn)的延遲或卡頓更易引發(fā)用戶的反感。此間如果涉及到啟動多個進(jìn)程，除進(jìn)程創(chuàng)建本身的顯著開銷和內(nèi)存壓力之外，如果啟動的是其它應(yīng)用的進(jìn)程（即通常所說的『交叉喚醒』），對方的初始化開銷則是一個完全不可控的因素。而交叉喚醒在應(yīng)用之間往往具有連鎖效應(yīng)，在安裝有較多關(guān)聯(lián)應(yīng)用（例如集成了相同SDK的多個應(yīng)用）的情況下極易觸發(fā)『鏈?zhǔn)絾拘选唬�引發(fā)CPU、內(nèi)存、IO等資源短時間內(nèi)的巨大壓力，造成設(shè)備流暢性的急劇下降、耗電上升，帶來嚴(yán)重的應(yīng)用啟動階段用戶體驗和全局設(shè)備體驗的雙重?fù)p害。

4，使用請求喚醒CPU的周期性Alarm、JobScheduler的周期最小不低于30分鐘，建議不低于1小時。避免在不必要的時間段（如夜間）繼續(xù)調(diào)度周期性事件

原因：周期性喚醒CPU會打斷設(shè)備的深度睡眠狀態(tài)，造成設(shè)備待機時長的明顯縮短。按照Google在Project Volta中的粗略測算，設(shè)備每1秒鐘的活躍工作會讓待機時間損失大約2分鐘。大部分應(yīng)用的后臺周期性任務(wù)往往以網(wǎng)絡(luò)訪問為主，通常會持續(xù)數(shù)秒至數(shù)十秒（甚至超過1分鐘）。如果此類周期性后臺活動調(diào)度過于頻繁，對待機時間的影響是極其顯著的。Android從4.4開始，不斷在迭代中優(yōu)化周期任務(wù)的后臺調(diào)度，但所有這些努力都只能在長周期任務(wù)中產(chǎn)生明顯的效果。倘若有一個應(yīng)用請求過于頻密的周期任務(wù)，則整個系統(tǒng)的待機時長就會因為短木桶效應(yīng)而受制，

5，為用戶提供可達(dá)成『后臺純凈 (Background-free)』目標(biāo)的選項。（不必默認(rèn)開啟）

原因：后臺持續(xù)運行的服務(wù)，是一系列設(shè)備體驗問題的溫床，如長連接基帶持續(xù)工作增加的耗電、低內(nèi)存時服務(wù)循環(huán)重啟引起的設(shè)備遲緩、間歇性CPU和IO資源占用造成的卡頓…… 后臺純凈是Android O對應(yīng)用后臺約束的一項重大原則性變化，它倡導(dǎo)的是『如非必要，勿啟后臺』的新原則。

后臺純凈 (Background-free)：指符合面向Android O的應(yīng)用開發(fā)要求中關(guān)于后臺運行的約束。其核心要求是應(yīng)用進(jìn)入后臺短時間內(nèi)（至多3分鐘，并在屏幕關(guān)閉前）停止所有后臺服務(wù)，且在除了收到廣播和執(zhí)行來自通知的PendingIntent之外的其它條件（如JobScheduler）觸發(fā)的后臺行為期間不可以再啟動新的后臺服務(wù)。

6， 對于存在內(nèi)容更新、數(shù)據(jù)同步或弱實時性通知的應(yīng)用場景，建議在『后臺純凈』模式下以周期性輪詢替代推送。 （參見前述的最低周期約束）

對于Android 5.0及以上版本的系統(tǒng)，不在AndroidManifest.xml中靜態(tài)注冊以下廣播：（從Android O開始，以下全部廣播均已不再支持靜態(tài)注冊）