这太让人无法接受了。远程桌面通常不是只有一名用户有权限访问的， 而正式运营的 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 开发者日志，以期为你充分介绍 Service 的功能由来，或是探索未来的开发方向，并交流设计构思，以期能以此优化最终产品。
更多问题欢迎回帖讨论，开发团队将会选取有价值的回复共同探讨。而你的一个想法，也有可能会最终影响 SmobilerService 某个功能模块的开发方向，因为开发团队确实能够真切的听到你的声音。
也欢迎加入石磨官方开发者讨论 QQ 群：308522976 继续探讨。
你的意见，非常重要！
