猿急送>

南京Android兼职程序员

ID：307290

さとうダヒイ

Android开发初级工程师

公司信息：
纳里健康科技有限公司

工作经验：
3年

兼职日薪：
600元/8小时

兼职时间：
下班后
周六
周日
可工作日远程

所在区域：
南京
全区

技术能力

1 可进行不是特复杂的安卓模块化设计
2 可以用c++，python，java，go等语言实现部分算法
3 熟悉mysql编程和部分redis编程，有一定的算法研究经历，也用过一些ui框架写过pc客户端
4 还有就是对各种常见的三方框架如rxjava，okhttp3，volley还有retrofit等和组件较为熟悉，一般使用MVP架构，有时会使用MVVM架构。在能力范围内可以对framework层代码进行操作和修改。最重要的是会时刻学习新的安卓方面的知识

项目经验

一、精仿今日头条，使用RxJava + Retrofit + MVP开发。
数据来源：今日头条，
接口获取：
所有数据：fidder尝试抓取今日头条数据(非正常渠道，仅做测试)
视频解析（目前策略已改，暂时不想修复）：
1、获取videoID
2、生成16位随机数r，补全视频链接后进行CRC32加密，这两个参数将作为视频真实链接的query参数
3、请求真实链接，返回json数据，video节点的main_url参数是经过base64加密过的链接，解密即可得到结果

用到的部分第三方库：
okhttp
Retrofit
RxJava
ButterKnife
Gson
EventBus
BGARefreshLayout
Klog
BaseRecyclerViewAdapterHelper（新闻列表显示，经过自定义封装）

目前可实现的部分
1.获取各种频道的新闻列表,只包括非视频新闻（如果是文字带视频的可通过网页解析的方式显示）；
2.查看新闻详情，只包括非视频新闻（如果是文字带视频的可通过网页解析的方式显示）的详情；
3.查看新闻评论列表；
4.新闻数据本地存储，已经获取到的新闻数据保存在本地数据库中，上拉加载更多时可查看历史新闻；
5.底部页签点击下拉刷新;
6.查看和保存图片。(文件夹路径为：手机存储/Android/data/com.bytedancer.toutiao.read/files/pic/)

二、一款用kotlin语言编写，使用协程+MVVP模式的电子阅读器，仅支持在线+缓存阅读模式(由于api更新后代码更新，导致获取数据时只能解析出源码)
主要框架有: Lifecycle、ViewModel、LiveData、Kotlin + 协程
主要网络框架有OKhttp、Retrofit
主要缓存框架是okhttputil(自定义的)
解析框架Jsoup（目前已失效，不是框架失效而是数据失效）

我担任绝大部分角色，包括逻辑层的代码和后端接口的查找。前端代码在项目开始前有看过部分大神的布局代码，进而一步步摸索写出。项目中最难的就是找接口和解析接口方面。因为不光是要找到合适的接口，还要对接口返回的html数据进行json解析。不过还好有几位网友在网上贴出了较容易解析的几个接口，我选了一个较适合我想要的接口，经过一到两个月的努力，终于把前期的布局和逻辑弄完了。

三、读卡器项目
业务背景：
配置读卡器的项目，主要针对德卡设备，以适配第三代社保卡读卡
业务目标：
实现第三代社保卡能读取出身份证号，性别，出生年月等
具体工作内容：
重新适配了厂商提供的 SDK ，并重构了读卡部分的代码，
最终获得成果：
读卡效率提高了40%

四、平板界面优化
业务背景：
用户反馈，部分模块页面未合理配置平板，导致页面较扁，操作比较麻烦
业务目标：
模仿分屏的方式将不同操作区域分成不同子页面
具体工作内容：
使用水平线性布局处理每个子页面，针对全局的按钮或者其他组件，使用相对布局设置
最终获得成果：
用户体验感提升，操作便捷，并且经过重构，代码加载速度有显著提升(40%到50%)

五、Dchat聊天工具（仿微信）
一款基于Android和golang后端的IM聊天软件
主要实现多功能聊天等功能，粗略分为三大模块:
聊天主界面模块、消息传递模块以及其它控制模块。聊天主界面模块：主要有展示聊天信息的界面区域、聊天信息输入框、发送按钮、私聊群聊界面等
消息传递模块：主要负责消息从客户端分发到服务端以及服务端消息消费存储的逻辑组件。消息分发部分会用到Kafka，RPC，ETCD等中间件。服务端离线消息缓存会用到Mongodb，全量消息存储会用到Mysql
其他控制模块：由应用栏的菜单键实现，用来控制各类功能。还包括部分工具类，例如文件(图片)选择，视频播放等。
服务端运行于Docker容器中，由访问层、逻辑层和存储层组成，好处在于各个层次能够依据业务特点专注于自己的事情，提高系统复用性，降低业务间的耦合。
（1）访问层：消息通过 Websocket 协议[11]接入，其他通过 http/https 协议接入，消息是高频及核心功能，通过双协议路由，体现了轻重分离的设计思想。
（2）逻辑层：通过 RPC 实现无状态逻辑服务[12]，易于平行扩展，消息通过 MQ 解耦。（3）存储层：Redis [13]存储 token 和 seq；MongodDB 存储离线消息，并定时删除 14 天（可自行配置）前数据； Mysql 存储全量历史消息以及用户相关资料。数据分层存储，充分利用不同存储组件的特性。
（4）ETCD：服务注册和发现、以及分布式配置中心。

消息模型的时序过程如下：
1、客户端通过webSocket发送消息到消息网关。
2、网关通过gRPC调用消息服务的 UserSendMsg方法发送消息。
3、消息服务(主要是本地)生成唯一消息ID（去重）和发送时间。
4、然后投递到Kafka，等待所有Kafka的Slave都收到消息后判断发送成功。
5、gRPC返回投递结果。
6、给客户端回复ACK，携带错误码和服务端生成的MsgID等。
7、Transfer中的消费组Mysql消费到2条消息（发送者的发件箱、接收者的收件箱）。
8、持久化到Mysql中全量存储，而客户端是从MongoDB中拉取消息的（拉取后删除），这里和微信逻辑类似。微信号称不在服务器存储数据，所以用微信登录PC端时，如果出现手机接收到的消息PC端接收不到，要么是PC端没有pull的过程，要么是离线消息只针对APP端，PC端拉不到。
9、同理，transfer中消费组MongoDB消费到2条消息。
10、调用Redis的incr，递增用户的消息序号，key格式为："REDIS_USER_INCR_SEQ: " + UserID，因为本身用户只有一个收件箱，所以是用户范围内递增。
11、插入MongoDB中的消息集合中。
12、优先通过gRPC调用pusher进行推送，否则走Kafka，通过Pusher消费的方式推送。
13、pusher也同样通过gRPC调用消息网关中的sendMsgToUser推送消息。
14、通过Websocket推送。
15、用户B上线的时候，从MongoDB中拉取离线消息（成功后会从MongoDB中删除）。

案例展示

Dchat

主要实现多功能聊天等功能，粗略分为三大模块: 聊天主界面模块、消息传递模块以及其它控制模块。聊天主界面模块：主要有展示聊天信息的界面区域、聊天信息输入框、发送按钮、私聊群聊界面等消息传递模块：主要负责消息从客户端分发到服务端以及服务端消息消费存储的逻辑组件。消息分发部分会用
本地音频播放

一款本地音频播放器，内置MediaPlayer，Exoplayer以及ijkplayer，目前仅支持代码层自定义播放框架。其中Mediaplayer支持音效播放。目前主要的功能有自定义通知栏播放控制，线控播放，睡眠模式，播放历史记录，后台持久化等未来将加入的功能。支持音频