项目A 1.0优化总结

一:把折叠效果换成只有滑动到服务顶部再下滑才让顶部分类显示出来

mRecyclerView.getLocationOnScreen(location);
Logger.e("onScrollStateChanged----------------》Screen x is " + location[0] + " Screen y is " + location[1]);
if (location[1] == COMPLETELY_STRETCH_HEIGHT) {
    mRefreshLayout.setPullDownRefreshEnable(true);
} else {
    mRefreshLayout.setPullDownRefreshEnable(false);
}

二:优化要求:在快速滑动时(不是手一拖一拖的那种,而是手指离开后的滑动,即SCROLL_STATE_SETTLING)不加载图片,停下来才加载

解决办法:

mRecyclerView.addOnScrollListener(new RecyclerView.OnScrollListener() {
    @Override
    public void onScrollStateChanged(RecyclerView recyclerView, int newState) {
        super.onScrollStateChanged(recyclerView, newState);
        //方案一:滑动时(指SCROLL_STATE_SETTLING状态下)暂停in progress的加载否则恢复加载,
        // Glide不支持暂停或恢复单个request的加载要么暂停所有,要么恢复所有
        if (newState == RecyclerView.SCROLL_STATE_SETTLING) {
            requestManager.pauseRequests();
        } else {
            requestManager.resumeRequests();//恢复加载时会加载R个item(R为用来复用的item个数)
        }
      //方案二:每次不滑动时只加载屏幕可见的item 比方案一更省流量,
      // 假设一屏容纳V个item,那么每次停下时少加载R-V个item图片
        if (newState == RecyclerView.SCROLL_STATE_IDLE || newState == RecyclerView.SCROLL_STATE_DRAGGING) {
            loadVisibleItemImage();
        }
@Override
public void onScrolled(RecyclerView recyclerView, int dx, int dy) {
    super.onScrolled(recyclerView, dx, dy);
    Logger.e("onScrolled---------------->");
    //下面为方案二所需代码
    lastVisibleItemPosition = linearLayoutManager.findLastVisibleItemPosition();
    firstVisibleItemPosition = linearLayoutManager.findFirstVisibleItemPosition();
 private void loadVisibleItemImage() {
        for (int i = firstVisibleItemPosition; i <= lastVisibleItemPosition; i++) {
            ServiceView serviceView = (ServiceView) mRecyclerView.findViewWithTag(i);//onBindViewHolder里面进行的setTag
            if (serviceView != null) serviceView.setCover();
//            Logger.e("current serviceView is " + serviceView);
        }
    }

        方案一中之所以滑动时停止所有加载,停下来后恢复加载可以节省流量(这里加载完所有图的所需总流量没变,是指快速滑动到某位置前不会加载从而消耗没必要的流量),是因为停下来后,加载的最多也就N个item(N为用于复用的原始item个数)
而滑动时加载虽然加载的对象也是那N个,但是那N个是在不停加载的,只不过不停切换Url而已(网速好的情况下基本下滑的同时对应position的图已加载好),所以消耗的流量很大。

        对于已加载好但滑过去了然后滑回来发现会有重新“加载”现象:即由先展示默认placeholder然后再变成应有的图片,这其实重新加载是必然的因为view是复用的(不信看微信朋友圈也有),之所以修改前不明显,那是因为之前滑动时可以加载,而且此时滑回去加载的是缓存所以速度极快,几乎看不到,而修改后滑动时不可加载,所以滑动时看到的是默认图片,只有停下来才开始加载缓存,这也是为何滑回去的话,虽然看似再次加载,却不耗流量的!!!!!!!(流量监测app可证明)

        主页耗流量原因:之前人写的代码设置头像时上传的url就是原始图,而不是小图,所以主页头像是原始图,另外普通动态图虽然是显示的压缩图,但是相比微信我们的压缩图还很大,加之之前滑动时仍然加载,所以不断滑动翻页结果就发现流量飞跑!!!!!!!!!!!!!!!!!


1.获取View在屏幕中的位置使用view.getLocationOnScreen()或者getLocationInWindow()

2.对于可滑动的View(RecyclerView ,ListView,ScrollView),如果设置了滑动监听,那么初始化显示时会回调onScrolled(),不过不会回调onScrollStateChanged().不过前提是

其其自身宽/高要大于屏幕,否则即使用手去拖动onScrolled()也不会回调,即只有它能真正滑动时onScrolled()才会回调,不过它不能滑动时如果用手去拖还是会回调onScrollStateChanged()而且还会监听到完整的三种状态:DRAG,SETTLING,IDLE.(不过要注意拖动方向必须是由其头部指向尾部方向)

3.使用recyclerView.canScrollVertically(1/-1)  canScrollHorizontally(1/-1)来判断RecyclerView是否滑动到底部/顶部

RecyclerView.canScrollVertically(1)的值表示是否能向上滚动,false表示已经滚动到底部
RecyclerView.canScrollVertically(-1)的值表示是否能向下滚动,false表示已经滚动到顶部

4.View的Visibility (VISIBILE,INVISIBILE,GONE) :View.getVisibility ==VISIBILE时并不一定 view对用户可见,例如:本次项目中放在CoordinateLayout中的顶部分类的RecyclerView 随着上滑退出屏幕后此时判断其Visibility仍然是VISIBILE。正如其语义——可见性,当为VISIBILE时只说明是可以被看见的,但是有时候可能被遮挡!








 mContentView.getViewTreeObserver().addOnScrollChangedListener(new ViewTreeObserver.OnScrollChangedListener() {
            @Override
            public void onScrollChanged() {
                Rect rect = new Rect();
                boolean isShown =mCategoryList.getGlobalVisibleRect(rect);
//                Logger.e("content view onScrollChanged width is "+isShown+mCategoryList.getMeasuredWidth()+"\nheight is "+mCategoryList.getMeasuredHeight()+"\n rect width is "+rect.width()+"\n rect height is"+rect.height());
                if(isShown){
                    EventBus.getDefault().post("1");
                }else {
                    EventBus.getDefault().post("0");
                }

            }
        });
//        mContentView.setOnScrollChangeListener(new View.OnScrollChangeListener() {
//            @Override
//            public void onScrollChange(View v, int scrollX, int scrollY, int oldScrollX, int oldScrollY) {
//                Logger.e("content view onScrollChanged");
//            }
//        });

 
  @Override
    protected void onWindowVisibilityChanged(int visibility) {
        super.onWindowVisibilityChanged(visibility);
//        if(visibility==View.VISIBLE){
//            Logger.e("onWindowVisibilityChanged-------->可见"+this);
//        }else if(visibility == INVISIBLE || visibility==GONE){
//            Logger.e("onWindowVisibilityChanged-------->不可见"+this);
//        }
    }


<think>好的,用户之前问过关于项目经历编写的问题,现在又问了项目总结,我需要确定这两者的区别和联系。用户可能是想了解在完成项目后如何有效总结,或者是在简历或面试中如何呈现项目总结。 首先,项目经历更多是描述项目本身的结构和内容,而项目总结可能更侧重于项目完成后的成果、经验教训以及个人成长。需要明确用户的具体需求,是用于简历中的总结部分,还是项目结束后的复盘报告? 从用户提供的上下文来看,之前的回答是关于项目经历的编写技巧,所以这次的项目总结可能也是用于求职材料或者工作总结。用户可能是求职者,特别是应届生或转行者,或者是希望提升简历竞争力的职场人士。 接下来要考虑项目总结的关键要素。通常包括成果展示、技术亮点、经验教训、个人成长等部分。需要结构清晰,重点突出量化成果,同时体现反思和提升。还要注意避免常见的错误,比如泛泛而谈或只列技术栈。 用户可能希望知道如何将项目中的具体工作转化为有说服力的总结,尤其是在面试或汇报中使用。因此,需要提供具体的结构和示例,帮助用户理解如何组织内容,如何量化结果,如何展示解决问题的能力。 另外,可能需要注意不同行业的项目总结特点,比如开发类、数据分析类、设计类的侧重点不同。同时,用户可能关心如何在总结中体现个人贡献,特别是在团队项目中如何明确自己的角色。 还需要考虑用户可能的深层需求,比如如何通过项目总结展示自己的成长潜力,或者在转行时如何将过往经验与新领域结合。因此,在回答中应该包括如何突出迁移能力和学习成果的部分。 最后,要确保建议实用,有可操作性,比如使用模板、避免的误区以及加分技巧,帮助用户快速应用这些建议到实际的项目总结撰写中。</think>以下是关于项目总结的详细指南,包含专业写作方法和实用技巧: --- ### **一、项目总结的核心要素** 1. **成果展示** - 量化指标:$订单处理速度提升150\%$ | $用户留存率提高22.5\%$ - 技术突破:$实现1000QPS高并发$ | $模型准确率超行业基准8\%$ - 业务价值:$节省年度运维成本\$50万$ | $带动销售额增长\$300万$ 2. **技术亮点** ```markdown ■ 架构设计: ✓ 采用DDD领域驱动设计解耦业务模块 ✓ 通过Redis Cluster实现分布式缓存 ■ 创新方案: ✦ 自研动态线程池解决资源浪费问题 ✦ 提出改进型A*算法优化路径规划 ``` 3. **经验沉淀** - 方法论:$形成标准化开发流程文档$ | $建立AB测试评估体系$ - 工具链:$开发内部CLI工具提升部署效率$ | $构建自动化测试平台$ --- ### **二、结构化写作模板** #### **1. 研发类项目** ```markdown **智慧物流调度系统**(2023.03-2023.08) ▌关键技术:Spring Cloud Alibaba + Kafka + 蚁群算法 ▌核心成果: • 设计动态权重调度算法,车辆空驶率降低27% • 实现百万级订单的实时路径规划(<500ms响应) • 搭建风控模块拦截85%异常订单 ▌经验总结: ✓ 分布式事务方案选型:TCC模式 vs 最终一致性 ✓ 技术债务:技术栈版本碎片化导致维护成本增加 ``` #### **2. 数据分析项目** ```markdown **用户生命周期价值预测**(2022.11-2023.02) ▌模型架构:XGBoost+SHAP可解释性分析 ▌项目产出: • 清洗处理2000万+用户行为数据 • 构建7维度特征工程体系 • 模型KS值达0.42(超行业基准0.35) ▌改进方向: ▶ 引入图神经网络捕捉用户社交关系 ▶ 建立自动化特征监控体系 ``` --- ### **三、高级表达技巧** 1. **对比论证法** - 技术选型对比: $$ \text{方案} \begin{cases} \text{方案A:响应时间 } 1200\text{ms} \\ \text{方案B:响应时间 } 450\text{ms} \end{cases} $$ - 效果对比:$CPU使用率从85\% \downarrow 40\%$ 2. **技术深度展示** - 性能优化:$$ T(n) = O(n^2) \rightarrow O(n\log n) $$ - 架构演进:单体架构 → 微服务 → 服务网格 3. **问题解决路径** ``` 问题现象:接口超时率突增 → 根因分析:慢查询+线程阻塞 → 解决方案:SQL优化+熔断降级 → 验证结果:TP99从3s降至200ms ``` --- ### **四、常见误区与改进** 1. **避坑指南** - ✘ 流水账式记录:_"完成了需求开发、测试、上线"_ - ✔ 价值导向表述:_"通过代码预编译技术,发布效率提升3倍"_ - ✘ 技术堆砌:_"使用SpringBoot/Redis/MySQL..."_ - ✔ 技术关联:_"基于Redis管道技术实现批量操作,吞吐量提升8倍"_ 2. **加分细节** - 成果可视化:$ \text{系统架构图} $ | $ \text{性能对比曲线} $ - 技术影响力:_"方案被纳入团队技术规范"_ - 持续优化:_"迭代3个版本,错误率从5\% → 0.3\%"_ --- ### **五、特殊场景处理** 1. **失败项目总结** - 客观分析:$ \text{需求变更率} \uparrow 300\% → \text{项目延期} $ - 经验转化:_"建立需求变更评估矩阵,后续项目延期率下降60\%"_ 2. **跨领域项目** - 能力迁移:_"将金融风控经验应用于医疗欺诈检测"_ - 创新融合:_"结合CV算法实现工业质检流程自动化"_ --- **高质量示例:** ``` 智能客服系统优化(2023.05-2023.09) ▌技术突破: • 实现基于BERT的意图识别模型(F10.91) • 构建知识图谱包含50万+实体关系 • 对话打断准确率提升至89% ▌关键决策: ✓ 放弃规则引擎,采用端到端深度学习方案 ✓ 引入主动学习机制降低标注成本 ▌后续计划: ▶ 部署模型蒸馏方案(模型体积↓70%) ▶ 接入多模态输入支持 ``` --- **注意事项:** 1. 数据脱敏:隐藏敏感业务指标 2. 重点突出:技术难度 > 业务规模 3. 版本管理:区分V1.0/V2.0迭代差异 4. 可验证性:所有数据可解释来源 建议结合MECE原则(Mutually Exclusive, Collectively Exhaustive)构建总结框架,确保内容既全面又无重复。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值