项目的开发架构

由于没有参与一个大型的、要求性高的项目，自己之前对项目的架构不甚了解，很多时候是基于功能方面思考。但是对于一些项目，如果对项目本身有一个明确的架构认识，可以帮助自己从更高的层面上思考问题和具体实现方式，而不是仅仅完成当前功能那么简单。当别人问起的时候，没有一个架构打底，即使项目本身再优秀，当你说出来的时候，别人都不知道你在说什么。所以应当及时地记录下自己参与项目的架构、以及它的演变之路。

XXX Store 2.0.0

该项目是在第一个实习公司里参与开发的，是公司内部产品的应用商店，基于Hybrid模式开发。由于是上手的第一个项目，感觉一切都是处于学习阶段，写的代码现在看来十分的糟糕。而且由于是Hybrid模式，所以在native层上的东西比较少，Java包括Android在该项目上积累较少。但更多地熟悉了JavaScript还有网络请求方面，也第一次接触了业界上的某一角落。

基本的网络请求都在webview上进行，所以项目的开发很大程度上依赖于webview，当然hybrid app本来就是为了UI、移植、适配的方便而采用的方案。

WebView

webview上的请求都使用jQuery的ajax API，服务端返回的都是json数据，所以在web端解释起来十分方便。

UI用的是Framework7，组件和动画都做得十分像iOS(包括Android端)，所以理论上两大平台可以共用一套UI，这就是hybrid的优势。

请求得到的数据和UI之间的如何关联起来，可以使用优秀数据绑定框架Knockout，包括文字、列表、判断、图片等都可以被绑定，减少代码的编写量。

Bridge

当然，webview更多的是处理UI和网络请求方面的事情，对于一些问题还是需要native去处理。所以web端与native的交互就显得非常重要了。项目中撇开了Android原生的webview与native交互方案，而是使用一个github上开源库JsBridge。该库很好地适应项目的大部分场景。native和web都可以相互调用默认接口，也可以自定义接口供另一方调用。

Native

由于web端处理了开发过程中的大部分功能，native在项目中是被弱化了。native主要实现了四个模块：

Data Manager：数据的管理、本地储存、缓存、UI刷新管理，包括应用列表、用户信息token、应用刷新请求等；

Package Manager：本地应用的检测和状态监听（添加、替换、删除），还需要处理从web端传来的应用数据，在native进行比对之后返回正确数据；

Request Manager：与web端网络请求相比，在native端进行的请求都一些非显示性响应性的、有获取token、检查更新、上传日志、用户日志等；

Push Service：推送服务的集成，该模块与公司或者项目的策略有关，用的是极光，该模块主要接收应用的推送消息、以及在通知栏上显示出来。

可选优化：

1.数据本地缓存。由于Android系统的各种ROM还有内存限制，承载webview的Activity在后台时经常被杀死，每次返回前台时都请求一次网络的话，对服务器、用户流量、应用响应都不是一个很好的体验。由于应用消息并不是经常变化的，所以对一些数据可以在本地缓存起来。再次启动时先检查时效，缓存时间超过了上限时再执行请求，否则沿用缓存数据；

2.bridge的异步生成。web端上bridge是webview的一个组件，它的生成需要一定的时间，这就造成了一个异步的问题：在bridge生成前执行了需要bridge参与的工程，整个系统都会出错。刚开始时是进行1秒的同步（1秒内基本上可以生成，但这样依旧是不安全的），后来想到使用消息队列将要使用bridge的请求都储存起来，一旦bridge生成完毕，根据FIFO的原则执行请求；

3.Native封装请求：这个是典型的方式，由于没有使用第三方的网络请求库，所以需要靠自己在native对原生HttpUrlConnection进行封装。

即时通讯引擎设计与应用

这是大三时申请的一个大创项目，但由于各种方面的原因，实现的细节还在进行，暂时先画个架构图，后续再进行修改。

server

main server 提供三个功能模块：

admin protal为开始者提供服务，如注册创建用户、创建应用、SDK下载、信息帮助页面等；

Node register为节点服务器提供一个注册的接口，当一个节点服务器可用时，便向该节点提交请求加入到服务集群中。该模块还需要定时检查节点的可用性，及时维护有效的服务集群信息；

Access service提供统一服务接口给sdk，该接口返回可用节点服务信息给sdk，对外屏蔽所有节点服务的信息。

Redis2为main server提供缓存，主要记录可用节点、节点使用情况等信息，给Access service提供有效的信息。

Node server最底层需要保证维持长连接以保持服务，在长连接的基础有个协议管理器，用来解释并应用自定义协议的内容如注册、转发、发送，upload用于向数据库提交通讯、注册数据。redis3缓存其他用户的连接情况，为转发提供高速访问。

全局MySQL提供数据储存功能，包括用户、应用、通讯信息。

全局redis1缓存全部连接的用户-节点信息，为全局转发通讯信息提供支持。

Client 

Client SDK设计采用层级形式

底层需要实现接入服务以及重连服务（因为移动数据的特点，连接可能容易断）的逻辑；

然后需要有一个机制来维持整个连接，避免系统查死无法及时推送消息；

sender 提供给开发者来发送数据，receiver接收数据；

由于是自定义协议，需要协议建造者和解析器来简化操作；

最后就是通知服务，采用广播的形式向全局发送收到的信息。

场景模拟智能车

学院的工程实训作品，架构是别人帮忙搭建好的，只需要添加特定的逻辑即可。

arduino实现的功能逻辑都比较简单，复杂计算决策问题交给树莓派：

电机驱动模块实现四轮小车的移动，抽象成速度、转向、后退等接口；

超声波提供近距离的避障；

树莓派：

通过WiFi与局域网内的小车进行自定义协议的通信，共同完成场景；

摄像头和人脸识别用于辨别方位；

移动决策根据当前信息，通过算法计算出下一步的移动动作，通过数据总线发送指令给arduino执行。

EWork

大三时做的第一个小应用，由于是初入坑，实现的东西十分糟糕。没什么规范，而且没有接触过业界，不知道有什么注意事项。

处于底层的模块两个，网络请求和数据库封装帮助类：网络请求可以简化服务端的get和post接口请求。由于初入坑，选择的实现方式是Thread+HttpUrlConnection，而且抽象程度不够；数据库储存了包括用户信息、工作组、任务列表、签到情况数据，供上层模块调用。不过也有因为考虑不足，最重要的数据同步问题没有深究实现下去。

当时对json不甚了解，所以选择了一个虽强大但复杂的XML格式作为数据交互格式。所以在请求层上添加了一层XML parser，对请求数据做解析。

交互与解析有了，就可以添加功能模块。由于应用比较简单，所以大致有登录、注册、群组模块。群组模块需要操作本地数据和数据库，而群组内又有任务模块作为组成群组一个部分，另外的位置模块主要用于基于地理位置的签到功能，需求较为简单。

随心带APP

在完成XXX Store 2.0.0之后，有感可以利用hybrid独立完成一些小应用。随心带APP是个人开发的休闲音乐型应用，基于hybrid易移植，界面简洁优美。主要功能有：背景音乐盒、步数记录、手机使用频率提醒、心情趣文推送、主题样式下载；目前处在测试阶段，最新版本1.0.2.4，测试版本下载链接http://beta.qq.com/ty3x。

该项目的web端应用比较简单，使用的都是Framework7里面的组件，包括UI、模板引擎（主要是商城里面的数据需要用到）、Ajax。

native层需要集成较多的功能：

Music player：对应用全局的音乐播放器，web实现progress的拖放显示，player实现播放逻辑以及刷新；

User Detect：用户行为的监测，项目最初是希望收集用户信息，根据数据来推送特定信息。行为包括步数（界面会显示出来）、应用使用情况、用户收集使用情况等；

Common request：封装了一些基本的网络请求，包括商城皮肤的下载、用户行为的上传、检查更新等；

Data Storge：为文件（商城皮肤）、用户数据提供储存、获取方案；

Push Service：该模块暂时没有发挥作用，主要用于推送心情趣文、应用更新等信息。