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 继续探讨。

你的意见，非常重要！

标签：Smobiler,SmobilerService,Service,开发者,日志,推送,服务端
来源： https://www.cnblogs.com/smobiler/p/11114880.html