千万不要试图在已经不维护的框架下，并且异常陈旧项目下开发新功能！血和泪的教训!
先说一下感觉，感觉就是，“累”， “心累”，身心疲惫！
image.png
本次项目迭代，牵扯到app等项目，这里只分享一下本下次开发中遇到的问题，以及广告对接，数据上报,页面缓存处理，渲染的处理等问题！
1.首页缓存渲染的处理
在开发此处时，第一版因为思考不充分，缓存利用不合理，导致页面加载异常缓慢，并且会闪屏，体验异常的差！
解决方案：
首次加载，立马拉去数据不做渲染处理，渲染处理的数据立马放置到缓存中去。渲染页面的话，判断从缓存中拉取，拉取的数据尽量不要做太多的逻辑数据处理，否则在性能比较差的手机上面，会出现卡顿的现象！
当页面切换的时候，再次去拉取数据，放置到缓存中去，然后只更新对应的图片链接的地址，更新渲染的话，也是从缓存中拿取！这样的话当你页面来回切换的时候页面不会出现闪屏的现象和性能比较差的手机上的卡顿现象！同时页面的图片也会更新！
因为具体的业务逻辑比较复杂，这里只说的是很简单的一个思路!
这里在提示一个比较重要的点：
缓存中获取的数据以及数据结构，尽量不要做太多的逻辑处理，否则在性能比较差的手机上面，你就哭去吧！
2.原生端数据的转发，前端数据接收处理
简单介绍：
因业务需求，开屏广告的数据需要从原生端进行转发，前端接收到广告数据，进行逻辑处理个页面渲染！
这里只说前端数据的接收，我们用的是插件的形式，通过事件监听的方式进行数据的接收；
前端全局监听一个事件，通过接收事件的参数来确定，所需要的数据也就是参数数据！
- 数据上报
这里是通过接收的参数，也就是我所需要的数据，数据里存在一个上报的链接，我只需请求一下此链接，那么数据就相当于上报成功了，但是这只是简单的上报，一般需要你通过链接的形式，将一些坐标信息，时间戳等等一些列的参数上报，我这边上报了十几个参数，都需要自己组织！这就不一一列举了！
数据上报的时候可能有多个链接，这个时候就要自己处理了，我这边是先将对应的链接放到一个数组里面，然后写了一个闭包，加延迟处理，里面放置的事get方法，每隔1s或多秒上报一次数据，这样就减轻了服务器的压力，比同时上报要好许多！
遇到了不少坑，也是因为项目的技术栈异常陈旧，导致很多语法不兼容以及要做很多兼容处理！再加上app逻辑异常复杂及混乱，导致这期的项目迭代加了很多班！幸好，最后按时上线!
特写此，以记录！我自己踩过的坑！
后面还有，暂时写这些吧！
接着,以上的问题！
- 项目迭代预估时间
由于我们采用的敏捷开发的流程，分配任务时 ，首先是先进行工作量的评估，然后在进行开发！
自己的问题，对自己负责的工作，评估时间过于乐观！
一步一个坑，总也填不完，导致很多意想不到的问题的出现！
但是也得一个一个解决啊！很无奈🤩!
- 项目需求不明确
细想，需求不是很明确也是一个问题，导致开发思路不明确！需要一遍遍反复确认！
- 需求增加
开发过程中，需求不断增加，最后发现，产品逻辑不能形成闭环！导致开发过程中，需要用代码或者程序员开发的思维去弥补产品上的缺陷或者说是去强制使产品形成闭环！
7.总结
简单总结一下，
1.个人问题可能占主要原因吧！
2.产品开发流程不规范！
3.填坑所花费的时间较长！
4.坑太多！
......
image.png
网友评论