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

什么是綠色公約

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

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

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

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

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

這就是「綠色應用公約」的誕生背景：先讓一部分有良知有擔當的應用團隊，在保全流量利益的大前提下，卸去對設備體驗的傷害，轉而再推動手機廠商卸去它們對這部分應用的敵意和束縛，從而讓雙方都有機會攜手創造一個更加良性的國內 Android 生態。

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

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

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

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

綠色公約介紹

宗旨

這是一項旨在推動Android生態中的優秀應用共同維護一個更加良性的『設備體驗』而發起的開放公約。

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

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

因此，除了加強用戶對于設備體驗損害的辨識能力外，有必要推動整個Android開發社區以更高的標準優化各自應用的設備體驗影響，共同維護一個良性的Android生態。

開放編撰

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

核心原則

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

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

規約

必要部分

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

原因：Project Svelte在Android 7中得到了一些關鍵的的強化，有助于降低應用后臺行為對設備體驗的影響。

2， 不在運行時強制請求『讀取手機狀態和身份（READ_PHONE_STATE）』權限。

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

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

3， 除用戶的主動交互觸發外，避免啟動其它應用未處于運行中的進程。

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

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

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

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

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

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

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

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