【社区江湖 源码】【穿越源码透视】【定制源码目的】load源码
1.Glide源码分析
2.unimrcpclient源码分析mrcp components
3.源码详解Pytorch的源码state_dict和load_state_dict
Glide源码分析
深入剖析Glide源码：解析与理解其架构与机制
1. Glide三大关键流程
使用Glide加载时，主要包含三大关键流程：with、源码load、源码into。源码通过链式调用这些方法，源码能轻松完成加载任务，源码社区江湖 源码但背后蕴含的源码原理复杂且源码规模庞大。分析源码时，源码需抓住重点。源码
1.1 with主线
with方法是源码Glide中的重要接口，可传入Activity或Fragment，源码与页面生命周期紧密关联。源码在分析中，源码我们曾遇到线上事故，源码因伙伴在with方法中传入了Context而非Activity，源码导致页面消失后请求仍在后台运行，最终刷新页面时找不到加载的容器直接崩溃。因此，穿越源码透视with方法与页面生命周期息息相关。
1.1.1 Glide创建
通过getRetriever方法最终获得RequestManagerRetriever对象。在Glide的构造方法中，通过双检锁方式创建Glide对象。之后，调用Glide的build方法创建一个Glide实例，传入缓存和Bitmap池等对象。
1.1.2 RequestManagerRetriever
Glide的build方法直接创建RequestManagerRetriever对象，需requestManagerFactory参数，若未定义则默认为DEFAULT_FACTORY。获取此对象后，方便后续加载。
1.1.3 生命周期管理
在获取RequestManagerRetriever后，调用其get方法。当with方法传入Activity时，会在子线程调用另一个get方法，而主线程中通过fragmentGet方法，定制源码目的创建空Fragment并同步页面生命周期。
1.1.4 总结
with方法主要完成：创建Glide对象，绑定页面生命周期。
1.2 load主线
通过with方法获得RequetManager，调用load方法创建RequestBuilder对象，将加载类型赋值给model。剩余操作由into方法负责。
1.3 into主线
into方法负责Glide的创建和生命周期绑定。传入ImageView，根据其scaleType属性复制RequestOption。into方法调用buildRequest返回Request，并判断是否能执行请求。执行请求或从缓存获取后回调onResourceReady。
1.3.1 发起请求
创建request后，调用RequetManager的track方法，执行请求并添加到请求队列。判断isPaused状态，天启挂机 源码决定是否发起网络请求。成功加载或从缓存获取后回调onResourceReady。
1.3.2 三级缓存
通过EngineKey获取资源，从内存、活动缓存和LRUCache中查找。若未获取到，则发起网络请求。成功后加入活跃缓存并回调onResourceReady。
1.3.3 onResourceReady
资源加载完成或从缓存获取后，调用SingleRequest的onResourceReady方法。判断是否设置RequestListener，最终调用target的onResourceReady方法，显示。
1.3.4 小结
into方法主要步骤包括：创建加载请求、判断请求执行、从缓存获取资源、网络请求与资源回调。psd源码 站长
2. 手写简单Glide框架
实现Glide需理解其特性，特别是生命周期绑定和三级缓存。手写时，着重实现这两点。在load方法中，支持多种资源加载，并使用RequestOption保存请求参数。在into方法中，传入ImageView控件，并在buildTargetRequest方法中判断是否发起网络请求。实现三级缓存逻辑，确保加载效率。使用协程进行线程切换，提高性能。通过简单API加载本地或网络链接，实现Glide功能。
unimrcpclient源码分析mrcp components
配置样例包含六个部分。
函数unimrcp_client_components_load主要负责这六个组件的加载，下面详细解析各个组件的加载过程。
加载resource组件时，其结构体mrcp_resource_t定义在mrcp_resource.h，字符串使用apt_str_table_item_t（定义在mrcp_resource_loader.c），mrcp_resource_loader_t和mrcp_resource_factory_t分别位于mrcp_resource_loader.c和mrcp_resource_factory.c。构造mrcp_resource_loader内部是mrcp_resource_factory_t *factory，factory通过mrcp_resource_factory_create构建，参数为MRCP_RESOURCE_TYPE_COUNT的第5个值，整型值为4。
加载sip-uac组件时，mrcp_sofia_client_config_t结构体（mrcp_sofiasip_client_agent.c）应用于sofia sip协议栈。默认端口和名称设定如下：config->local_port = DEFAULT_SIP_PORT; 默认端口为，config->user_agent_name = DEFAULT_SOFIASIP_UA_NAME; 默认agent name为UniMRCP SofiaSIP，config->origin = DEFAULT_SDP_ORIGIN; 默认sdp origin为UniMRCPClient。IP地址配置通过unimrcp_client_ip_address_get（unimrcp_client.c）实现，可配置为“auto”或“iface”。然后使用mrcp_sofiasip_client_agent_create（mrcp_sofiasip_client_agent.c）创建sofiasip_client。
加载rtsp-uac组件时，指代MRCPv1版本的uac组件。rtsp_client_config_t结构体（mrcp_unirtsp_client_agent.h）用于配置。组件加载通过unimrcp_client_rtsp_uac_load函数完成。
加载media-engine组件时，配置项仅包含realtime_rate。unimrcp_client_media_engine_load函数负责加载此组件。mpf_engine_t结构体（mpf_engine.c）用于创建mpf_engine，使用mpf_engine_create函数。
加载rtp-factory组件时，mpf_rtp_config_t结构体（mpf_rtp_descriptor.h）包含可配置项。unimrcp_client_rtp_factory_load函数用于加载此组件，并通过mpf_rtp_termination_factory_create（mpf_rtp_termination_factory.c）创建相应的工厂。
源码详解Pytorch的state_dict和load_state_dict
在Pytorch中，保存和加载模型的一种方式是通过调用model.state_dict()，该函数返回的是一个OrderDict，包含网络结构的名称及其对应的参数。要深入了解实现细节，我们先关注其内部逻辑。
在state_dict函数中，主要遍历了四个元素：_parameters，_buffers，_modules和_state_dict_hooks。前三种在先前的文章中已有详细介绍，而最后一种在读取state_dict时执行特定操作，通常为空，因此不必过多考虑。重要的一点是，当读取Module时，采用递归方式，并以.作为分割符号，方便后续load_state_dict加载参数。
最后，该函数输出了三种关键参数。
接下来，让我们深入load_state_dict函数，它主要分为两部分。
首先，load(self)函数会递归地恢复模型参数。其中，_load_from_state_dict源码在文末附上。
在load_state_dict中，state_dict表示你之前保存的模型参数序列，而local_state表示你当前模型的结构。
load_state_dict的主要作用在于，假设我们需恢复名为conv.weight的子模块参数，它会以递归方式先检查conv是否存在于state_dict和local_state中。如果不在，则将conv添加到unexpected_keys中；如果在，则进一步检查conv.weight是否存在，如果都存在，则执行param.copy_(input_param)，完成参数拷贝。
在if strict部分中，主要判断参数拷贝过程中是否有unexpected_keys或missing_keys，如有，则抛出错误，终止执行。当然，当strict=False时，会忽略这些细节。
总结而言，state_dict和load_state_dict是Pytorch中用于保存和加载模型参数的关键函数，它们通过递归方式确保模型参数的准确恢复。