SmobilerService 開發者日誌（一）：什麼是 SmobilerService ，它爲開發者帶來了什麼價值？

初見 SmobilerService 你會發現幾個版本，以及一些價格。

因此，「Smobiler 是要收費了嗎？」 這是開發團隊在幕後悄悄觀察 Service 推廣開始後，用戶向運營團隊提出的最關心的幾個問題之一。

在此開發團隊替運營小組轉達全部的 Smobiler 用戶：請放心，Smobiler 此前免費的功能會一直免費下去。

這一次發佈的 SmobilerSevrice 嚴格意義上咱們能夠簡稱它爲 Service ，它並不涉及任何開發方面的功能。實際上，SmobilerService 是爲更好的託管 Smobiler 服務端併爲其賦予更強大的能力而生的。

雖然說盡管沒有 Service 你依舊能夠在服務器上用那個大大的二維碼窗口，無差異的運行你用 Smobiler 開發好的服務端，但藉助於 SmobilerService ，咱們但願可以幫助你把這一切作的更好。

在長期對開發者使用習慣的觀察中，咱們整理出了一些開發者一般在運營 Smobiler 應用時都會遇到的問題。而後某一天，基於這份問題清單，咱們坐下來討論，而後決定開始構建這款 SmobilerService ，來幫助用戶，知足他們在運營 Smobiler 應用過程當中的更加多樣性的需求，爲 Smobiler 應用的運營工做賦能。

下面咱們一塊兒來看看，你最終看到的這些 Service 功能，都是如何誕生的。

1.在界面上鋪滿一堆大大的二維碼窗口是個大問題……

咱們發現當用戶在同一臺服務器上同時運營多個 APP 時，服務器界面上會充斥着大量的二維碼窗口，就像這樣：

這太讓人沒法接受了。遠程桌面一般不是隻有一名用戶有權限訪問的， 而正式運營的 Smobiler 服務器就這樣暴露在外，隨時能夠被任何訪問遠程服務器的人（甚至是本身！）隨手關掉，這實在是太危險了。

就算是在 Smobiler 開發團隊內部，也發生過有開發者鏈接遠程桌面進行系統維護誤關閉服務端的問題，最終致使短期內大量內部員工沒法正常使用 APP 的問題。

咱們但願以一種更加優雅的方式去託管 Smobiler 應用。

• 它會整齊有序，同時隱藏起來，讓 Smobiler 服務端在暗中運行。
• 但應用配置也要像此前二維碼窗口同樣，作到足夠簡單。（誰會願意用記事本打開一個.config 配置文件，去逐行查找編輯目標呢？）
• 最好它還可以無需登陸遠程服務器就得以控制和操做，這樣將遠程服務器用戶密碼給予他人帶來的不可控風險被進一步降到最低。

因而最基礎的應用託管功能誕生了。 你只需將應用以類庫(.dll)的方式生成（而再也不是.exe），再提供應用所在的目錄， Service 就可以幫你暗中「拉起」服務端，讓它安全的在幕後運行。

這是咱們同時託管 4 個應用時，SmobilerService 所呈現的樣子：

足夠優雅。但這還不夠，咱們作了更多。

• 若是暗中運行的服務端被人意外的在任務管理器中結束了呢？
• 若是 Service 也被人在任務管理器中結束了呢？
• 或者有其餘異常中斷，致使了它們退出。

進程守護應運而生。

咱們試圖找到一種方式，來持續檢查應用服務器的運行狀態，若是發現進程丟失，會當即嘗試再次拉起服務端，以此來保證它的正常運行，用戶使用不受中斷。而這也被最終實現，如今，當服務端被意外停止時，進程能夠在 1 秒內被 Service 立刻恢復。

而另一個問題是，假若守護 Smobiler 服務端的 Service 自己被中斷了，又該怎麼辦呢？幸虧，由於 Service 是以 Windows 服務的方式運行在系統中的，則 Windows 系統自己也會對它提供保護，在出現意外退出時，根據服務守護策略，由 Windows 操做系統來恢復 SmobilerService 服務。

Windows 服務恢復策略的界面以下：

因此最後成了：

Windows 服務保證 SmobilerService 運行 → 而 Service 保證 Smobiler 服務端正常運行。

這樣一來，咱們得以將服務端的意外停機機率降至一個很是可觀的低數值。

2.咱們發現很多用戶使用 Smobiler 開發企業級內網應用

這首先給消息推送帶來困難。

此前 Smobiler 應用在設備鏈接公網的狀況下，藉助集成的極光推送插件可以輕鬆的實現消息推送功能。但當用戶將 Smobiler 應用純粹使用於內網之中後，這個方案再也不行得通了。咱們須要一個新的思路。

因此，最後咱們乾脆本身封裝出了一套推送服務。

若是你有心觀察，必定會在任務管理器中發現一個名爲 smopush.exe 的進程。沒錯，咱們將它最終集成於 Service 中，實現了內網推送功能。

如今，藉助於這套服務，當客戶端徹底運行於內網環境時，消息推送也可以正常運行。

固然，咱們還爲它略微追加了一點常見的個性化功能：

全體推送
推送給指定用戶羣

若是你將系統交付給並不具有開發能力的運營人員維護，則咱們爲你開發了一個操做界面，這應當可以知足手動推送消息的須要：

而對於真正有開發能力的開發者，也許直接進行界面操做不是你想要的（畢竟這樣效率過低了），咱們直接向你開放了一個簡潔的口子，你能夠經過引用類庫並調用指定的方法來實現代碼級的消息推送，讓一切自動化：

• 引用位於安裝目錄下 /server/rpc/Smobiler.Service.Push.dll 類庫

而後根據方法簽名提供參數便可。

一個簡單的示例以下：

int appId = 163;
int pushServicePort = 1883;
PushClient mPush = new PushClient("127.0.0.1", appId, pushServicePort);
if (mPush.IsConnected == false)
{
     mPush.Connect();
}
string title = "消息標題";
string content = "這裏是推送消息的內容";
//使用此行代碼推送全體消息：
MessageResult result = mPush.PushAll(title, content);
//或使用此行代碼推送部分用戶（與上一行代碼二選一）
MessageResult result = mPush.Push(title, content, new List<string>(){"DeviceID1","DeviceID2","DeviceID3","DeviceID4"});

固然，做爲開發者日誌咱們最想表達的仍是設計思想和功能由來的故事，並但願藉此可以與最終用戶討論溝通，以改善產品給你帶來更好的使用體驗。有關如何使用的細節和代碼問題，你還須要查閱文檔，或向官方技術支持團隊尋求幫助。

3.用戶並不但願本身的某些企業級應用被隨意傳播和使用

就像上面提到過的，有很多開發者使用 Smobiler 開發的最終產品，是企業級應用。

這意味這它會有特定的使用場景和用戶羣體，而並不是像面向最終我的消費者的 APP 那樣，裝機量越多越好。

有時，咱們只但願部分用戶安裝咱們的應用，而對非法訪問的用戶直接踢出，或者永久禁止訪問。再幹脆一點，甚至直接限定設備範圍，使得此應用只可以被固定的幾臺設備訪問。

客戶端管理、黑白名單功能正是咱們針對這類問題所給出的答案。

你能夠直接查看當前鏈接的全部設備，將未經受權但闖入的非法設備當即踢出，使其失去與服務器的鏈接（經過點擊設備後紅色的Kill）：

也能夠配置黑白名單模式，並啓用一種策略類型來永久的阻止或開放一部分用戶訪問應用的權限：

以上兩種方式，在目前看來都足以應對 APP 使用權限和範圍受權的管理需求。

4.「每次一出問題都要到一線作技術支持，太累了……」

Smobiler 部分開發者作出的應用，是運行在倉儲或者是物流行業當中的。

運行在這樣的環境也意味着當一線員工持槍掃描或者進行其餘操做遇到問題時，開發者是頗有可能被立刻「召喚」到現場去作技術支持的，而倉庫和物流場地實在是...太大了。

當開發人員趕赴一線，觀察員工操做後，三下五除二就搞定了問題，讓工做得以繼續進行。

因此是否是能夠坐在位置上就解決這個問題呢。開發人員須要的，僅僅是看到一個流暢的「遠程畫面」，進而重現故障或指導操做而已。

是否是能夠嘗試作出一個 APP 遠程監控來提高解決問題的效率，減小往復時間呢。爲何不呢？

遠程監控正是爲此而生。

經過在設備列表內點擊 Monitor 按鈕，便可實現 APP 遠程畫面監控：

由此咱們能夠幫助開發者最大限度的提高效率，在最少的時間內，解決最多的問題。這也是咱們認爲在 SmobilerService 第一版中，最爲激動人心的一個功能，但願它可以真的，爲你帶來可見的價值和明顯的效率提高。

好了，以上就是 SmobilerService 產品故事的開始，它到底如何起步，以及爲何咱們決定先作出這些功能，相信都有了一個很好的概述。

===================分割線===================

結束語

日後，SmobilerService 會有更多新奇的功能被不斷加入，咱們亦會繼續更新 SmobilerService 開發者日誌，以期可以在功能最終發佈前與你充分接觸，探討設計構思的合理性、並優化最終產品模塊的使用方式與操做體驗，直至功能最終與你正式見面（ 或是某些緣由中途決定放棄咱們也會盡量的告訴你緣由 :-) ）。

固然，開發團隊僅能經過開發者日誌來與各位最終用戶進行設計思路和功能實現上的溝通和交流，並在這其中改善產品，提高使用體驗，使其更符合最終用戶的需求，實實在在知足你對產品運營的需求，並幫助開發者在應用運營與管理上作的更好。而最終發佈時具體哪一項功能劃入哪個銷售版本中、訂價多少，開發團隊不會去關心也無權干涉，這一切仍是基於石磨發展角度由專業的決策團隊去作考慮，有這方面的問題，還請多多關注運營推廣的相關信息~

更多問題歡迎回帖討論，開發團隊將會選取有價值的回覆共同探討。而你的一個想法，也有可能會最終影響 SmobilerService 某個功能模塊的開發方向，由於開發團隊確實可以真切的聽到你的聲音。

也歡迎加入石磨官方開發者討論 QQ 羣：308522976 繼續探討。

你的意見，很是重要！