JBoss 的推播方案 - Unified Push Server(現在叫 AeroGearPush)

前言

2016年獨立開發者最慘痛的第一個消息，大概就是臉書併購的 Parse 要收起來不玩了，我手上的專案用到 Parse 的推播功能也中鏢了，想到要自己把 GCM 接起來真的是一個頭兩個大。

簡單說明一下 Parse 是一個 BaaS(Back end as Service) 服務，可以想成臉書幫你養了一台提供資料庫/會員註冊/排程工作/推播的雲端主機，對開發者來說省去了架設/部署的工作，能夠專注於開發。

Parse 預計明年一月要收掉，整個 Parse 也已經開源出來，如果你本身也熟悉 Node.js 的開發生態，基本上可以整包拿下來架站。我最終選擇是改用 JBoss 提供的推播方案，下文大概介紹一下架構、功能，詳細實作的程式碼因為會隨著改版而失效，這邊就不會寫上程式碼。

JBoss Unified Push 架構

JBoss 的推播方案一開始叫做 Unified Push，現在就整進 AeroGearPush 裡頭(算是其中一個子專案)，整個程式碼也有開源出來，其實是一個跑在 JAVA EE Server 上的 war 檔。

因為我只有實作 Android Push 這一塊，以下就用 GCM 為例說明。Push Server 封裝了 GCM，如果沒有 Push Server，我們就必須自己去管理手機從 GCM 取得的註冊資訊。當有跨手機平台的推播需求的話，我們也只需與 Push Server 介接，Push Server 負責實作推播至不同手機平台的功能。

以下說明上圖每個元件的作用：

• Push Server：收集所有手機傳回的註冊資訊。發送訊息給各平台的推播系統，再推播至手機上。
• Application Backend Server：實作 APP 的後台邏輯，當有推播需求(ex：商品上架、有新事件)時透過 SDK 將訊息傳給 Push Server。
• Push Networks：就是指 Android / iOS 原生的推播系統。
• 手機：除了接收訊息外，最重要的將從原生推播系統取得註冊資訊傳給 Push Server。以 Android 來說，透過 SDK 將從 GCM 取得的 token 傳給 Push Server。

環境架設

除了把 Push Server 架起來外，上面可以看到手機 APP 和後台 Server 還會需要用到以下 SDK：

• aerogear-android-push (用來跟 PushServer 註冊裝置)
• unifiedpush-java-client (包裹 Web API 用來將要傳送的訊息交給 PushServer 推播)。

很多程式碼，名字變來變去，版號很多，這就代表有很多雷可以踩，建議先裝好 Push Server，裝好以後在 Web GUI 把推播相關的參數設定好，在 Web GUI 上有自動產生樣本程式碼的功能，這時候再來去抓最新 SDK，如果找不到類別或錯誤就降一版 SDK 試看看。我也是花了一點時間才找出來可以動的組合。

建議的步驟如下：

1. 安裝 Push Server。
2. 在 Push Server 上建立 Application。
3. Application 下設定 variant，variant 主要用來介接 iOS/Android 推播系統，介接的資料欄位需要從 iOS/Android 推播系統後台得到。
4. 此時，你 Push Server 上應該有一個 Application，一個以上的 variant。
5. 利用 Push Server > Application > variant 產生回傳註冊資訊至 Push Server 的範例程式碼，整合至手機 APP 程式碼，看看與下載的 aerogear-android-push 相不相容，不相容就找別的版本。
1. 開啟手機 APP，利用 Push Server 的 WEB GUI 觀察手機有無註冊成功。
2. 利用 Push Server 的 WEB GUI 發送訊息，驗證 Push Server 可以將訊息推到手機上。
6. 利用 Push Server > Application 產生推播訊息至 Push Server 的範例程式碼，整合 APP 後台程式碼，看看與下載的 unifiedpush-java-client 相不相容，不相容就找別的版本。
1. APP 後台發訊息給 Push Server，驗證可以透過 Push Server 將訊息推到手機上。

其他

關於 Push Server 的註冊部分，看到的寫法是每次打開 APP 或是某個頁面就重新註冊，這部分觀察資料庫，除非重新安裝 APP 否則上傳的註冊資料(GCM token)都是一樣的。解除註冊部分，看到的寫法可能寫在使用者勾選的開關上(讓使用者決定要不要收到推播)，或是離開某個頁面就解除註冊。以 GCM 來說，唯一知道這裝置已經解除 GCM 註冊的時機點是在推播的時候，然後如果是自己寫的 Push Server 就可以將這些裝置清掉，但 JBoss (我用的版本是1.0.0 beta 2)的做法是沒寫這塊邏輯，所以必須自己處理，我自己的做法是定時下 SQL 去清除一個月以上沒有向 Push Server 回傳註冊資訊的裝置。

最後還是想唸一下，紅帽的文件不是寫不好寫不夠多，是整理的很沒系統，這次找文件找 SDK 的時間大概比寫扣的時間還要多，只能說免費的最貴。

解譯 Android APK

前言

最近有個需求需要看一下別的 APK 是怎麼做的，原本以為有現成的工具應該蠻簡單的，沒想到命令列苦手跟一些不熟悉的技術問題還是把我弄的很慘，寫個筆記記錄一下。

透過本文，可以知道我用了哪些工具跟這些工具的功用，最後我把所有步驟寫成一個 Groovy Script ，我會簡單介紹用法，透過這個 Script 最終可以得到 APK 所有的資源檔案、java 檔案、或是一包 jar 檔案。

工具

透過我走過的流程順便帶出我使用的工具，APK 轉換的結果，對我來說重要的就是資源檔案(layout、語系...)和程式碼，我嘗試過的三個流程如下(最後當然是用最後一個流程)：

APK -> 透過 Apktool 解出來 -> 可以取得資源檔案，但只有 Smali(VM 上的虛擬語言，語法介於 Java 和 組合語言之間) 可以看但要花很多時間看。

APK -> 透過 dex2jar 直接把 APK 轉成 jar -> 沒有資源檔案，當 APK 裡頭有不只一個 dex 檔案時它只會解第一個 dex 出來，代表原始碼會缺少。

APK -> 改副檔名為 zip 解壓縮 -> 可以取得資源檔案和 dex -> 透過 dex2jar 把所有 dex 檔轉成 jar -> 解壓縮所有 jar 檔會得到所有的 .class 檔案 -> 把所有 .class 組成一個單一 jar 檔就可以用 JD-GUI 來看原始碼，或是透過 JAD 將所有 .class 轉成 .java。

怎麼使用我的 Script 

問我為何不寫 linux script 就好，我是有寫一版 linux script，但條件判斷和檔案搜尋結果再利用在 linux script 下真的是很難拼出來，所以我讓 groovy 做他擅長的部分，但執行指令還是會用下指令的方式。為什麼不用 python，因為我主力寫 Java，Groovy 跟 Java 語法相容。

Script 放在 github，所有會用到的工具就直接包含在專案裡了，使用環境是在 MAC 上，當然要先裝好 groovy 環境，然後修改 script 中 APK 的指定路徑，執行完後所有結果都會放在桌面上的 output 資料夾。

資源檔可以去 output/apktool 下找到。最終完成的單一 jar 檔可以去 output/onejar 下找到，用 JD-GUI 直接開這個 jar 就能看到原始碼。所有轉出來的 .java 放在 output/jad 下，這樣就能用 IDE 或文字編輯器來看。

解開 APP 百萬下載次數的成就

最近某支 APP 達到一百萬人次下載了，個人第一個想法是如果下載次數可以換成錢就好了，目前大概除了每個月廣告的零用錢，和履歷上可以多寫這一項成就以外，大概就沒啥屁用了。避免本篇走向流於無意義的自我感覺良好閃光文，寫一些心得給想寫 APP 賺錢的人分享。

先說本人的背景，主力 Java，寫過韌體（CP / Merge 也算的話），早期用 Swing 寫桌面 APP，SQL 會用但不到 DBA 等級，網頁幼幼班（CSS/HTML/JS 看得懂可以改從無到有就有點強人所難），後台比較熟 Java EE 相關（Tomcat/JBoss 7/Wildfly），雲端服務看到會接看看（Amazon/Google/Openshift/Parse/Memcache...反正需要什麼就接什麼），SA 技術也是幼幼班（Linux 會 ps 會 ls 真的要用還是要查鳥杯杯）。技術講完講其他，有結婚有小孩有一份正職，所以只能用六點下班後的時間搞這些阿沙布魯的東西，以前很愛畫圖，所以美工自己來，勉勉強強可用，然後前台到後台都有碰過，所以基本上整個 APP 開發所需要的知識都算有涵蓋到。

因為技術點上 Java 點的比較多，所以理所當然就是開發 Android APP，需要的成本除了時間以外（個人是覺得時間最貴啦），開發者帳號終身約臺幣800元（如果你沒被停帳號的話，後面會提），其他的花費不一定，但基本上我花過的大致有雲端服務的費用（例如：Amazon S3 儲存檔案），買素材的費用（例如：圖示），下廣告的費用（例如：臉書廣告）。

做 APP 不考慮到人力成本，一定是做遊戲要不就是搞出一個社群然後這群人會生內容出來（例如：臉書）。個人覺得寫遊戲的物理一定要很好，另外企劃和對遊戲系統的平衡都要很有料，真的不是買一本書，弄個飛機射子彈還是青蛙過街就有人會買單了。再來是社群的東西，一來要經營社群，二來後台未來也不是隨便一台 PC 搞定，三來該有的社群也都有了，人家為什麼要用你的 APP。考慮以上，果然還是跟 Sam Lu 大講的差不多，只有工具類 APP 的規模和後續維護的心力比較符合我能投入的時間。

至於 APP 的主題，我自己是開發前問自己三個問題，如果都是正向的，才會花時間下去弄，寫出來給各位參考一下：

1. 使用者是誰？
2. 需要每天用嗎？
3. 一定得用手機嗎？ 

基本上就是強迫練習自己找問題來用技術解決，而不是看到新技術或是想練技術才找題目。成效如何？如果一萬人次下載就算成功，做了10+個 APP 有五個 APP 達標，所以這三個問題基本上應該還算可以刪掉一些無用的 APP 點子吧！

如果真的有幸，APP 做出來了，也上架了，我自己推廣的方式大概就是到 PTT / Mobile 01 寫推薦文，如果有相關的論壇也會上去推推文。付費的話有玩過 Google AdWords / Facebook。不管免費或者是付費，我自己的經驗效果都不會是很好，PTT / Mobile 01 頂多就是當天會有些人下載，隔天就沒了。付費廣告則是瀏覽量一直都有，但實際安裝人數並沒有上來，按點擊收費看起來也是只要點到 Google Play 就算你錢了，實際上從 Google Play 點安裝的轉換率並不會是100%。個人碰過比較有效的方式，一個是部落客名人/媒體推薦，（但這種可遇也不可求），第二個是 APP 搜尋結果/排行在很前面，新上架一個月有進“最新熱門項目”前三名，那以後就輕鬆得多，搜尋結果至少要排進第二名，不過現在 Google 會管你描述裡是不是有塞垃圾敘述，一不小心又會被下架，等等會提到。

再來提到違規了，說到違規我應該可以說是專家，個人違規有發生過以下項目：

1. 被人檢舉內容不符合普級（但明明三點不露，同類型 APP 也是普級）。
2. APP 描述頁面有重複詞彙（我不是亂塞，就是寫個“關鍵字：xxx，yyy，zzz”這種等級）。
3. 侵犯智慧財產權（當時一堆人都做進擊的巨人也都還活著）。
4. APP 內容裡頭有品牌名稱被說意圖假冒是別人做的 APP。

不說心得，直接說說要注意的事項，一個帳號只要犯三次，整個帳號會被終止，連同帳號底下其他的 APP 都會被下架，所以最好的方法是一個產品一個帳號，免得被拖累。再來基本上申訴也沒屁用，建議犯規一次就可以開新帳號準備了。

最後，回答大家可能最關心的問題，到底有沒有辦法賺錢，看我還在上班就知道沒有辦法賺到大錢，個人手上 APP 所有的使用者大概是45萬人左右，然後都是工具類，使用者大概點開來看個10分鐘就了不起了（抱歉我 APP 沒塞 GA 所以沒有詳細數據不是我不提供），這樣子的前提下，一個月的零用錢大概是5000~9000新台幣的水準，給各位參考一下。

當然啦我沒有辦法全心全意寫出並且經營一個很大很棒的點子，不過最前面有介紹我的個人背景，看官可以比對一下，也許你單身你技術強你有人脈你有錢請人，那我相信一定可以賺比我多很多啦！最後大家點一下小弟全家合力經營的 APP 作品集一和作品集二（Google Play 連結無毒），看看有沒有什麼剛好合用的 APP，下載或是推薦，小弟感恩不盡！

最後的最後，想當初讓一隻超爛手機（記得是台哥大的 A3）能超順瀏覽小海嚴選的美女圖，真的是超爽的。牛頭不對馬尾的舉例，其實我只是想說，下班以後寫程式這件事本身就是要有愛才做得到的，如果你夠幸運你會賺到大錢，如果不幸只有幾百人用，想想看有幾百人在用你寫的東西，不也是很爽的事情嗎！