V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  xingheng  ›  全部回复第 18 页 / 共 19 页
回复总数  375
1 ... 10  11  12  13  14  15  16  17  18  19  
2019 年 11 月 22 日
回复了 Eagleyes 创建的主题 Apple 身份验证器哪家强?微软, Google 还是其他?
1Password 有身份验证器?是我 out 了还是👆的误解了?
2019 年 11 月 17 日
回复了 ichx 创建的主题 程序员 请问一下大佬们, ios 开发现在是真的不行了吗?
建议不要转,Java 的趋势一定是比 iOS 的前景稳。

什么公司,哪个城市,我是 7 年 iOS,求推荐公司呀,诚心找
2019 年 11 月 17 日
回复了 keepeye 创建的主题 程序员 你赞成软件开发中使用框架吗?
客观上的“框架不灵活”还是因为不合适,没有找到合适的框架。主观上的不灵活就是对别人的代码排外,不愿意接受事实而已,真香警告是早晚的
2019 年 11 月 17 日
回复了 anonymous256 创建的主题 程序员 招个人真难
最近也在找工作:iOS 或者 Python 的,诚心就坑位或内推。简历: https://xingheng.github.io/resume/iOS-Resume/
2019 年 11 月 17 日
回复了 anonymous256 创建的主题 程序员 招个人真难
楼主可能和老板那边的沟通有认知偏差:老板一般不在意新人具体是什么水平,从来都是能干活儿价钱划算就行,至于带人怎么带他才不在意。
2019 年 11 月 17 日
回复了 anonymous256 创建的主题 程序员 招个人真难
@MagicBoy 杠一下:Java 什么时候都开始并入计算机基础了,我还真不会🙃
2019 年 11 月 8 日
回复了 daijinming 创建的主题 程序员 dotnet 开发 API 的时候使用 asyn 、await 有什么优势吗
@crclz 学习了。我单独去查了一下“effective_spindle_count”的几篇文章,你说的 connection pool 大小是指的数据库层面的,不是 http/tcp connection 的。我觉得跟题主说的 API 层面上的 async 不太对等。
2019 年 11 月 8 日
回复了 daijinming 创建的主题 程序员 dotnet 开发 API 的时候使用 asyn 、await 有什么优势吗
@xuanbg 你说得对,是我上面对“并发量”的描述不对,应该算 keepalive connection/request 比较准确。
2019 年 11 月 8 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@samlee123 抱歉,是我没有描述清楚。确定不是 hook msgsend,面试官明确说了被调用方知道是谁调用了自己,参见#16 的示例代码。
2019 年 11 月 7 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@hoyixi 那种存服务器的统计以前我还真写过,就是先写内存然后批量发到服务器,发送失败就临时写文件。但是我觉得面试官在这里应该不是问的一个设计上的问题,还是语言级的内存管理问题。
2019 年 11 月 7 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@ai277014717 以我的理解,只有给对象发送了 autorelease 消息的对象才会在 autoreleasepool 闭合的时候 release,其他对象还是一直存在的。ARC 下,上面的 url, filename 可以算是 autorelease 对象。
我印象中以前有看过关于 dispatch queue 在执行的时候外围其实已经包了一个 @autoreleasepool{ },这样的话我觉得 autoreleased 对象并不能对内存构成威胁。

请指正。
2019 年 11 月 7 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
简单写一下目前我能想的代码结构再讨论吧

```

void core_func(NSString *caller)
{
static NSMutableDictionary<NSString *, NSNumber *> *dict;
static dispatch_queue_t serialQueue;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
dict = [NSMutableDictionary new];
serialQueue = dispatch_queue_create("initializer.serial.queue", DISPATCH_QUEUE_SERIAL);
});

dispatch_async(serialQueue, ^{
if (dict[caller]) {
dict[caller] = @([dict[caller] unsignedIntegerValue] + 1);
} else {
dict[caller] = @1;
}

if (dict.count > 1000) {
NSString *url = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).firstObject;
NSString *filename = [NSString stringWithFormat:@"stastics-data-%.3f", NSDate.date.timeIntervalSince1970];

url = [url stringByAppendingPathComponent:filename];

if ([dict writeToFile:url atomically:YES]) {
[dict removeAllObjects];
}
}
});
}

```
2019 年 11 月 7 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@ai277014717 NSNumber 拆装箱过程中可能会产生局部变量,内存会在每次退出函数的时候就被释放了,我觉得不至于影响 NSMutableDictionary 所持有的内存。
2019 年 11 月 7 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@kera0a 对方明确说明了调用方数量确实会有很大,我猜测还是 NSString 作为 key 的内存占用量会很大。

也不排除因为他们的 app 在正常运行的时候其他需求上已经占用大量内存了,只是针对或者设计了这样一个问题来优化这个统计结果。
2019 年 11 月 7 日
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@w99wen 确实想过串行的方法,把初始化和 dict 的操作都挪到串行队列里面去。主要问题还是内存,以我的理解,NSMutableDictionary 在 setValue:forKey:的时候确实会对 NSString \*key 进行 copy,但是这个 copy 不会产生新的内存分配(假定是 inmutable string ),只是把原有的 imutable string's retain count 加 1。上面说 NSMutableDictionary 的撑爆内存其实是指 NSMutableDictionary 持有的 NSString 把内存撑爆了。

这个理解有错误吗?请指正。

写 io 的话也想过,一旦 NSMutableDictionary 的数量级到了某个设定量就写文件,这样的话就还需要再次汇总结果了,可能不符合对方的预期。

这个问题来自蚂蚁金服的面试官。
2019 年 11 月 7 日
回复了 daijinming 创建的主题 程序员 dotnet 开发 API 的时候使用 asyn 、await 有什么优势吗
@crclz 有理。那我们再往下(main thread)追溯,(我没有写过 c#服务端,从其他语言推断的),main thread 或者说函数入口一定是 sync,每一个从 port 过来的请求一定是在 c#服务端对应一个 working thread 的,高效管理是语言级的特性,但是 working thread 的数量一定是不会减少的,working thread 之间(对外)也没有依赖关系,所以并发量还是没有增大。

我上面的蛋炒饭(async)假定确实很 critical,全程只有一个 async task 的需求是非常少见的,async 在这种情况下应该是没有什么好处的,高效管理只是说损耗很小,但不是没有。

async 在设计层面上是成功的,也推荐使用。在 API 设计层面上我觉得只是相对提高了响应请求处理的单位时间,勉强上可以说是间接地提高了并发量。

请指正。
pydoc -k
2019 年 11 月 7 日
回复了 hjq98765 创建的主题 Python Python 的 json 包好像有个小 bug?
Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 29 2018, 20:59:26)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin

>>> json.dumps({'y': 17318, 'info_total_periods': 12})
'{"y": 17318, "info_total_periods": 12}'
>>> json.dumps(cc)
'{"y": 17318, "info_total_periods": 12}'
>>>

没有重现
2019 年 11 月 7 日
回复了 daijinming 创建的主题 程序员 dotnet 开发 API 的时候使用 asyn 、await 有什么优势吗
@xuanbg 这个🌰好。但是如果有客人(request)就点了一个蛋炒饭(async),这样的话我觉得 sync 版的蛋烧饭会比 async 版的蛋炒饭更快,因为没有切换线程的损耗了。

关于楼上提到的并发量提高的问题我有些质疑,一个 request 在发起到完成之前,这个 working thread 应该是一直存在的,并不会因为 async 的使用导致 working thread dispose 或者 reuse 的情况。

我的理解对吗?
1 ... 10  11  12  13  14  15  16  17  18  19  
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1159 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 23:25 · PVG 07:25 · LAX 16:25 · JFK 19:25
♥ Do have faith in what you're doing.