谷歌浏览器免费下载安装(手机安卓版)（解决Chrome 浏览器ERR_INSUFFICIENT_RESOURCES过程）

目录

一    
    
    
    、背景

二 


     


     


     


、下载编译工具depot_tools

三

 




 




 




、下载Chromium源码        

四   

   

   

   、分析Chromium代码并加日志

四  

     

     

     

、编译Chrome

五


  




  




  




、定位问题

六  


  


  


  、解决方案

七   
     
     
     
、踩坑记录

一



   




   




   




、背景

最近公司客服同事经常反馈每到下午四点以后chrome浏览器经常会出现ERR_INSUFFICIENT_RESOURCES 异常
    
    
    
，导致客服系统无法正常工作
    
    
    
。主要特征就是新打开Tab时会报这个异常     


     


     


    ，在原来的tab内可以正常的使用     


     


     


    。清理一下浏览器缓存 




 




 




 


，过不了多久还会出现 




 




 




 


。这个问题我们团队的前端小伙伴也没有遇到过

   

   

   

，所以我们在网上也找了很多相关资料     

     

     

   ，发现有一个篇博客遇到的场景和我们遇到的场景较为相似  




  




  




  

，因此我们沿着这个思路尝试定位了一下


  


  


  


，最终验证了是相同的问题     
     
     
  ，接下来我把整个的定位和解决的过程描述一下   




   




   




   
，希望对遇到相关问题的同学有所帮助

   

   

   

。

二 



 



 



 、下载编译工具depot_tools

       （在下载chrome源码时



 



 



 



，确保能正常的访问google） deptool是下载和编译chromium的工具     

     

     

   。使用git把deptool工具克隆到本地：

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

此时fetch                   、gclient等命令行工具其实已经可以通过绝对路径访问并执行了                ，不过为了后续操作方便    




    




    




    ，可以将其加入到PATH中

export PATH="$PATH:/path/to/depot_tools"

完成后



















，在命令行里测试下 fetch 命令是否可用：

which fetch

三




    




    




    




、下载Chromium源码

        

因为 gclient














、fetch等工具核心下载代码的过程也是依赖于git的               ，所以有如下git全局设置建议调整下：

git config --global http.postBuffer 524288000 git config --global core.precomposeUnicode true

因为chrommium项目历史悠久     



     



     



     ，git仓库巨大无比


















，为更快的完成下载代码
    
    
    
，可以忽略历史提交代码的方式拉取能够加快速度  




  




  




  

。

fetch --no-history chromium

如果拉取失败可以执行以下命令继续拉取     


     


     


    ，此命令支持断点续传


  


  


  


。

gclient sync

四                    、分析Chromium代码并加日志

用VS打开Chromium/src/services目录 




 




 




 


，该目录是chrome的基础的系统服务层     
     
     
  。搜索ERR_INSUFFICIENT_RESOURCES,发现有100多处,我们发现在services/network/url_loader_factory.cc中有如下代码

void URLLoaderFactory::CreateLoaderAndStartWithSyncClient( mojo::PendingReceiver<mojom::URLLoader> receiver, int32_t request_id, uint32_t options, const ResourceRequest& resource_request, mojo::PendingRemote<mojom::URLLoaderClient> client, base::WeakPtr<mojom::URLLoaderClient> sync_client, const net::MutableNetworkTrafficAnnotationTag& traffic_annotation) { // 省略前面代码 bool exhausted = false; if (!context_->CanCreateLoader(params_->process_id)) { exhausted = true; } int keepalive_request_size = 0; if (resource_request.keepalive && keepalive_statistics_recorder) { const size_t url_size = resource_request.url.spec().size(); size_t headers_size = 0; net::HttpRequestHeaders merged_headers = resource_request.headers; merged_headers.MergeFrom(resource_request.cors_exempt_headers); for (const auto& pair : merged_headers.GetHeaderVector()) { headers_size += (pair.key.size() + pair.value.size()); } keepalive_request_size = url_size + headers_size; const auto& top_frame_id = *params_->top_frame_id; const auto& recorder = *keepalive_statistics_recorder; if (!exhausted) { if (recorder.num_inflight_requests() >= kMaxKeepaliveConnections || recorder.NumInflightRequestsPerTopLevelFrame(top_frame_id) >= kMaxKeepaliveConnectionsPerTopLevelFrame || recorder.GetTotalRequestSizePerTopLevelFrame(top_frame_id) + keepalive_request_size > kMaxTotalKeepaliveRequestSize) { LOG(ERROR) << "url_loader_factory.cc>>>>CreateLoaderAndStartWithSyncClient>>keepalive_request_size:" << keepalive_request_size << "kMaxTotalKeepaliveRequestSize" << kMaxTotalKeepaliveRequestSize << "recorder.num_inflight_requests()" << recorder.num_inflight_requests() << "kMaxKeepaliveConnections" << kMaxKeepaliveConnections << "recorder.NumInflightRequestsPerTopLevelFrame(top_frame_id) " << recorder.NumInflightRequestsPerTopLevelFrame(top_frame_id) << kMaxKeepaliveConnectionsPerTopLevelFrame << kMaxKeepaliveConnectionsPerTopLevelFrame << " recorder.GetTotalRequestSizePerTopLevelFrame(top_frame_id) + keepalive_request_size " << recorder.GetTotalRequestSizePerTopLevelFrame(top_frame_id) + keepalive_request_size ; exhausted = true; } } } if (exhausted) { //新增日志便于测试 LOG(ERROR) << "url_loader_factory.cc>>>>ERR_INSUFFICIENT_RESOURCES"; URLLoaderCompletionStatus status; status.error_code = net::ERR_INSUFFICIENT_RESOURCES; status.exists_in_cache = false; status.completion_time = base::TimeTicks::Now(); mojo::Remote<mojom::URLLoaderClient>(std::move(client))->OnComplete(status); return; } //省略后面代码 }

分析services/network/url_loader_factory.cc的CreateLoaderAndStartWithSyncClient方法发现

   

   

   

，当exhausted=true时     

     

     

   ，会抛出ERR_INSUFFICIENT_RESOURCES异常   




   




   




   
。我们继续查看是在什么场景下exhausted=true



 



 



 



。

bool NetworkContext::CanCreateLoader(uint32_t process_id) { auto it = loader_count_per_process_.find(process_id); uint32_t count = (it == loader_count_per_process_.end() ? 0 : it->second); //新增日志便于测试 LOG(ERROR) << "network_context.cc>>>>CanCreateLoader>>count" << count << "process_id:" << process_id; return count < max_loaders_per_process_; } // A count of outstanding requests per initiating process. //每一个初始化进程所能承受的最大未完成的请求数                。 std::map<uint32_t, uint32_t> loader_count_per_process_; // static constexpr uint32_t kMaxOutstandingRequestsPerProcess = 2700; //便于复现问题将数值调整为100================================================= static constexpr uint32_t kMaxOutstandingRequestsPerProcess = 100; uint32_t max_loaders_per_process_ = kMaxOutstandingRequestsPerProcess;

services/network/network_context.cc的CanCreateLoader方法会根据相同process_id

下的count是否大于kMaxOutstandingRequestsPerProcess的值（默认值为2700）  




  




  




  

，来决定exhausted的值


  


  


  


，为了便于复现问题     
     
     
  ，我把它调整成了100    




    




    




    。同时我也加入了相应的日志



















。

四



     



     



     



、编译Chrome

Google的C++项目大多使用ninja这样一个跨平台的编译工具   




   




   




   
，在mac端ninja底层会调用苹果公司的clang编译器               。

由于ninja的编译参数较为复杂



 



 



 



，Google又提供了gn 这样一个工具用于 根据当前系统环境生成合适的ninjaFile                ，此后使用autoninja进行编译时就不用设置任何参数了    




    




    




    ，直接基于ninjaFile配置文件进行编译     



     



     



     。

具体过程如下：

gn gen out/Default

现在会在out目录下生成编译Chrome所需的一系列参数和配置



















，然后开始编译（整个过程大概耗时8个小时左右               ，这个取决于电脑配置）：

autoninja -C out/Default chrome

编译完成后     



     



     



     ，你会看到在out目录下出现了 ./out/Default/Chromium.app/Contents/MacOS/Chromium 这样一个可执行文件


















。

为了能够查看加入的日志


















，需要使用命令行启动并加上--enable-logging参数

/个人文件目录/chromium/src/out/Default/Chromium.app/Contents/MacOS/Chromium --enable-logging

这样操作chrome时就会输出相应的日志
    
    
    
。

五















、定位问题

[38514:19971:1103/151157.874646:ERROR:network_context.cc(915)] network_context.cc>>>>LoaderCreated>>process_id:0 count>>101 [38514:19971:1103/151157.875321:ERROR:url_loader_factory.cc(182)] url_loader_factory.cc>>>>CreateLoaderAndStartWithSyncClient>>url:https://content-autofill.googleapis.com/v1/pages/ChNDaHJvbWUvMTA5LjAuNTM4MS4wEjMJBAwQwvyO8h4SBQ2RYZVOEgUNkWGVThIFDZFhlU4SBQ2BkPF8EgUNgZDxfBIFDZFhlU4SEAkcC8bFxOA28RIFDQbtu_8=?alt=proto [38514:19971:1103/151157.875475:ERROR:network_context.cc(933)] network_context.cc>>>>CanCreateLoader>>count101process_id:0 [38514:19971:1103/151157.875565:ERROR:url_loader_factory.cc(263)] url_loader_factory.cc>>>>ERR_INSUFFICIENT_RESOURCES [38514:19971:1103/151157.876158:ERROR:network_context.cc(926)] network_context.cc>>>>LoaderDestroyed>>process_id:0 count>>100

分析发现每次创建新tab时
    
    
    
，都会触发process_id:0 的进程     


     


     


    ，因为前端项目中用到了autofill功能 




 




 




 


，会不断的触发https://content-autofill.googleapis.com/v1/pages的请求

   

   

   

，而本机又无法访问google     

     

     

   ，会导致process_id:0 的进程中未完成的请求数一直在累加  




  




  




  

，而我们公司的客服系统会持续工作8个小时往上     


     


     


    。这就导致了当每次开启新的tab时会先执行process_id:0 进程的校验逻


  


  


  


，进而导致了前面代码中的exhausted=true     
     
     
  ，但我们再次打开新的tab无论访问任何网站都会抛出ERR_INSUFFICIENT_RESOURCES这个异常 




 




 




 


。

六    
    
    
    、解决方案

我采用的方案是在本地配置host   




   




   




   
，将*.googleapis.com域名指向了127.0.0.1



 



 



 



，这样.googleapis.com的请求会快速结束                ，进而不会触发chrome的阈值    




    




    




    ， 进而避免了exhausted=true的情况



















，后续再也没有收到客服团队反馈相关的问题

   

   

   

。

七 


     


     


     


、踩坑记录

1.如果开启了科学上网               ，仍然无法拉取代码 fatal: unable to access https://chromium.googlesource.com/chromium/tools/depot_tools.git/: Failed to connect to chromium.googlesource.com port 443 after 75123 ms: Operation timed out

 export https_proxy=http://127.0.0.1:7890

 export http_proxy=http://127.0.0.1:7890

2.在克隆大型git仓库时出现问题：

error: RPC failed; curl 18 transfer closed with outstanding read data remain

（错误：RPC失败；curl 18传输已关闭     



     



     



     ，但仍有未完成的读取数据）

经查原因是curl的postBuffer的默认值太小


















，我们需要在终端重新配置大小：

//设置全局http.postBuffer为200M
    
    
    
，即2000x1024x1024=2097152000 bite

//（如果目标实在大于200M,自行根据实际需求更改）

git config --global http.postBuffer 209715200000

//改完后可查看现有git私有配置列表确定是否成功

git config --list

 

参考：分享一次替Boss直聘企业端Debug的经历 - 知乎

Mac上本地编译Chrome浏览器踩坑笔记（2021.02最新） - 知乎