17上半年工作总结

一、客户端的工作

1、系统框架从MVC转MVP

MVP是MVC的一个衍生，主要目的是为了解耦，使项目易于维护，后续功能易于扩展。在MVC模型里，更关注Model的不变，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致更改View也是比较困难的，至少那些业务逻辑是无法重用的。
在以前的版本中，随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，使其变得庞大臃肿，最终变成了上帝类，无处不能。现在转为MVP，就可以将Activity内部的复杂逻辑移至到另外的一个类Presenter中，Activity就成为MVP模式中的View，并且只处理简单的逻辑，这就更加容易扩展。
客户端目前使用MVP框架的模块功能有：首页、头条频道，新闻详情页。

2、首页原生化：

首页界面复杂，功能点较多，以前的版本使用webview显示，它的优点较为明显：内容更新及时，不需要版本升级，在用户无感知的情况下立即更新。但是缺点也较明显，内容交互不流畅，滑动时界面容易出现抖动，随着客户端愈加稳定，首页UI升级的次数越来越少，所以这样功能就弱化很多。
首页webview已经被原生代替，这就解决了，首页加载慢、webview不安全（主要是容易被劫持嵌入广告等）、webview和Activity交互耦合度过高的问题。实现的方式是自定义LinearLayout+ListView，自定义LinearLayout上滑至一定距离时，LinearLayout禁止滑动，滑动权限交给ListView滑动。
当用户关闭该页面的时候，在onPause的生命周期内保存该页面的数据至本地，这样在下次启动的时候如果网络请求服务器数据失败，就可以加载本地缓存数据。

3、天气功能的升级

首页右上角UI的重新布局，以及城市选择界面的实现，客户端可以实时查看自己当前定位的城市，底部列表可以选择全国大部分的城市，并且可以在客户端进行搜索用户想查看的城市。返回后即可查看当前天气状况。点击天气icon可以查看最近今天的天气状况。

4、内存泄露问题：

随着项目的功能愈加的集成，内存泄露的问题越来越明显

5、用户行为的统计：

行为分析的基础是统计，必须有详细数据才能更好分析用户行为，对用户行为进行总结，是为了做出更受欢迎的产品/应用，再或者对用户的智能精准推送，推送用户感兴趣的内容，增加用户的黏性。目前统计的有首页各个频道的操作、新闻列表的操作、实时热搜的操作、分享的操作、天气的操作

6、网络框架从Volley转换到Retrofit2

对于移动互联网产品，网络框架的设计尤为重要，请求速度、流量、丢失率等等都是需要重点考虑的范围。从最初的HTTPClient，到后来的Volley，再到现在的Retrofit2，网络请求越来越稳定，越来越高效。在速度、易用性、简洁性、兼容性、以及重构所需要花费的时间上，Retrofit2都是比较优秀的。

Volley是官方出推出的，Volley在设计的时候是将具体的请求客户端做了下封装：HurlStack，也就是说可以支持HttpUrlConnection, HttpClient, OkHttp，相当于模版模式。

Retrofit的跟Volley的思路是一致的，但解耦的更彻底:比如通过注解来配置请求参数，通过工厂来生成CallAdapter，Converter，可以使用不同的请求适配器(CallAdapter), 比方说RxJava，Java8，Guava。可以使用不同的反序列化工具(Converter)，比方说json，protobuff，xml，moshi等等。
Retrofit比较有特色的的地方是，它提供了对RxJava的支持，可以让开发无缝衔接当前流行的响应式编程，目前项目也已部分引入RxJava。

7、图片加载框架的升级

图片加载功能无处不在，相比文字是费流量比较大的。图片的加载也经历了从Volley到Picasso，再到glide。
Volley是将AsyncHttpClient和Universal-Image-Loader的优点集成一身。Volley使用ImageLoader可以对图片进行缓存，过滤重复的链接，避免重复发送请求。缺点是不能加载本地图片
Picasso的方式简单：Picasso.with(context).load(“加载地址”).placeholder(“加载前显示的图片”).error(“错误显示的图片”).centerCrop(“类型吧”).resize(“大小”).into(“要显示的Image”)。有内存和外存两种缓存方式。相比Volley使用简单。
在最新版本中，Picasso已完全被Glide替代，Glide是Google官方推荐使用的，使用方法和Picasso一样。相比Picasso，Glide加载速度更快，更适合ListView/RecyclerView图片的加载，并且支持GIF图片和本地视频的播放。

8、启动页的优化

启动页作为应用开启的第一页，不但要加载广告、新闻等不同类型的内容，还要启动服务加载后台数据并且缓存至本地，以便第二页，也就是首页能够立即使用，省去加载的时间。

启动页的需求如：由于编辑并不是每天都发稿，而是一次发最近几天的稿子，比如一次发稿五篇，但这五篇的显示是按顺序显示的，也有可能不显示，完全取决于定义的字段和当前的时间，和已显示的内容。
在上个版本中服务器会一次返回给客户端最近几天稿子的所有内容。客户端根据事先定义好的逻辑和当前时间来显示哪篇文章。这样的优点很明显，不同设备，显示的内容不一样，客户端比较容易判断，缺点就是逻辑一旦定好，后台就没法修改了，并且IOS和Android都要开发两遍，大大增加了出错的概率和工作量。

优化后的逻辑是，业务逻辑从客户端移至到服务器端，服务器只返回当前要显示的一条内容，而不是以前的五篇内容。客户端在下次请求要显示的内容时候，把上次以获取的内容的ID传给服务器端，有服务器端判断该客户端应该显示的下条内容。

9、视频详情页的优化：

从网页播放升级到原生VideoView的播放，增加了播放的控制：快进、暂停、全屏，并且可以看到视频时长以及当前播放的位置。为了可以做多码率的适配，根据网络宽带，客户端会选择一个适合自己码率的文件进行播放，保证视频流的流程，视频格式由.mp4转到.m3u8。

二、头条V1.0发布

头条的第一版本发布，使用React Native和部分原生控件实现。React Native的优点较为明显：拥有原生的体验，开发效率很高，三个月完成最初两个版本，打好基础后基本上比原生开发要快，维护成本要低很多。

三、领导交代的其他工作