iMacedonian
Áp phích gốc- Ngày 10 tháng 10 năm 2015
- Brno, CZ
- 15 thg 12, 2018
Tôi đang nghiêm túc xem xét việc mua MacBook Pro 13 '2018. Mục đích sử dụng chính của máy tính xách tay là để viết mã (phát triển web front-end) nhưng tôi muốn đi sâu vào phát triển ứng dụng iOS sau này. Như đã nói, liệu 8 GB RAM có đủ để chạy XCODE hay tôi nên đầu tư thêm một số để có được phiên bản 16 GB?
người ôn hòa
- 20 thg 10, 2018
- CÔNG DỤNG
- 15 thg 12, 2018
iMacedonian nói: Này đó.Tôi chạy Xcode trên máy Mac mini 2014 của mình - nó có RAM 4GB và tôi không gặp bất kỳ vấn đề nào. Sẽ có một số người nói với bạn rằng RAM 16GB trở lên là điều bắt buộc, nhưng tôi thấy rằng điều này đơn giản là không đúng.
Tôi đang nghiêm túc xem xét việc mua MacBook Pro 13 '2018. Mục đích sử dụng chính của máy tính xách tay là để viết mã (phát triển web front-end) nhưng tôi muốn đi sâu vào phát triển ứng dụng iOS sau này. Như đã nói, liệu 8 GB RAM có đủ để chạy XCODE hay tôi nên đầu tư thêm một số để có được phiên bản 16 GB?
Emanuel rodriguez
- 17 thg 10, 2018
- 15 thg 12, 2018
revmacian cho biết: Tôi chạy Xcode trên Mac mini 2014 của mình - nó có RAM 4GB và tôi không thấy bất kỳ vấn đề nào. Sẽ có một số người nói với bạn rằng RAM 16GB trở lên là điều bắt buộc, nhưng tôi thấy rằng điều này đơn giản là không đúng.Đã đồng ý. Tôi nhận thấy rằng ngay cả một Raspberry Pi với một GB RAM cũng có khả năng biên dịch hầu hết mọi thứ. Nếu một dự án có rất nhiều mã C ++ (nhìn bạn là LLVM) hoặc các ngôn ngữ phức tạp khác (yêu cầu trình biên dịch làm việc chăm chỉ và do đó sử dụng nhiều RAM hơn), thì nó thường không thể quản lý được. Theo kinh nghiệm của tôi, có vẻ như khoảng 3GB là mức tối thiểu an toàn cho công việc phát triển.
CHỈNH SỬA: Mặc dù hãy nhớ rằng đây là 3GB bên trong máy ảo, không có GUI. Hiện tại, tùy chọn 8GB chắc chắn là an toàn. Tuy nhiên, tôi khuyên bạn nên sử dụng 16GB chỉ để kiểm tra trong tương lai. 8GB đang bắt đầu trở nên kém thoải mái hơn so với thời gian trước đây. Lần sửa cuối: 15 tháng 12, 2018
ammulder
- Ngày 18 tháng 12 năm 2015
- 16 thg 12, 2018
con chó
- Ngày 19 tháng 10 năm 2014
- Cơ sở Apple, Cupertino CA
- 16 thg 12, 2018
960 thiết kế
- Ngày 17 tháng 4 năm 2012
- Định mệnh, FL
- 17 thg 12, 2018
iMacedonian nói: Này đó.8GB là quá nhiều, tôi sử dụng một MBPr 16GB và hiếm khi thấy áp suất bộ nhớ tăng lên trên 8GB.
Tôi đang nghiêm túc xem xét việc mua MacBook Pro 13 '2018. Mục đích sử dụng chính của máy tính xách tay là để viết mã (phát triển web front-end) nhưng tôi muốn đi sâu vào phát triển ứng dụng iOS sau này. Như đã nói, liệu 8 GB RAM có đủ để chạy XCODE hay tôi nên đầu tư thêm một số để có được phiên bản 16 GB?
Ngoài ra, hãy kiểm tra Expo.io ( https://expo.io/ ). Đó là thứ mà tất cả những đứa trẻ sành điệu sử dụng ngày nay (rất dễ triển khai trên nhiều nền tảng). Lưu ý: sẽ hoạt động với hầu hết các ứng dụng, nhưng một số có các yêu cầu / nhu cầu phần cứng cụ thể mà triển lãm sẽ không đáp ứng được. Tuy nhiên, một nơi khởi đầu tuyệt vời.
jtara
- Ngày 23 tháng 4 năm 2009
- 17 thg 12, 2018
Ý bạn là 'đủ để việc xây dựng không bị hỏng?'
Hay 'đủ để quá trình xây dựng hoàn thành trong một khung thời gian có thể chấp nhận được'?
Và / hoặc 'đủ để giao diện người dùng không bị lag và tôi có thể làm việc trong trình chỉnh sửa / duyệt web / đọc email trong quá trình xây dựng mà không bị chậm?
Nó phụ thuộc vào kỳ vọng của bạn và chuỗi công cụ của bạn.
Phát triển giao diện người dùng thường có một chuỗi công cụ ngắn / đơn giản. Tất cả những gì bạn thực sự cần là một trình soạn thảo tốt phù hợp với nhiệm vụ, một số máy chủ web 'đồ chơi' nhỏ, có lẽ một số công cụ để giảm thiểu Javascript / CSS (và có lẽ là một trình biên dịch Sass) cho các bản dựng sản xuất và trong quá trình phát triển, bạn thường sẽ không sử dụng điều đó.
Phát triển phụ trợ thường có thể không cần nhiều hơn phát triển giao diện người dùng. Hoặc có thể cần nhiều hơn một chút. Ví dụ, tôi sử dụng PostgreSQL làm cơ sở dữ liệu. Vì vậy, tôi có một phiên bản cục bộ để phát triển / thử nghiệm. Tôi chạy pgAdmin4, chạy trong vùng chứa Docker. Bạn có thể cần chạy một máy ảo sao chép môi trường phụ trợ của bạn. GB cộng lại.
Phát triển ứng dụng gốc thường được thực hiện với các công cụ tối thiểu. Để phát triển ứng dụng iOS cơ bản, bạn không cần gì khác ngoài Xcode. OK và trình mô phỏng iOS. Nếu bạn đang thực hiện một số kiểu phát triển kết hợp, đa nền tảng, có thể thêm các thành phần chuỗi công cụ bổ sung - và cần thiết là các SDK và công cụ xây dựng Android. Phát triển Android sử dụng một trình biên dịch khác. Thêm một trình mô phỏng khác. (Tôi sử dụng GenyMotion, vì cả hai cách tiếp cận do Google cung cấp đều chậm như mật.) Bất kỳ trình mô phỏng Android tốt nào đều chạy trong máy ảo.
Ồ, cần kiểm tra trang web đó trên Windows? Thêm một máy ảo Windows.
Vì vậy, nhiều công cụ ngày nay chạy trong một vùng chứa hoặc một máy ảo. Điều đó làm tăng thêm yêu cầu về bộ nhớ.
Nhận được nhiều bộ nhớ nhất trong khả năng ngân sách của bạn. Tôi nghĩ, mặc dù vậy, 64GB là giới hạn thực tế hiện nay cho hầu hết các sự phát triển. Gần đây tôi đã có một chiếc iMac Pro với 64GB để phát triển. Tôi sử dụng một bộ công cụ lớn. Tôi đã kiểm tra Activity Monitor và nhận thấy rằng tôi chưa sử dụng tệp hoán đổi. Nhưng một khi tất cả các công cụ được tải lên, tôi đang sử dụng khoảng từ 32GB đến 64GB, thường là 40-50GB. Nhưng tôi thực sự chưa tải MỌI THỨ cùng một lúc.
Những gì bạn phải tự hỏi mình là:
- Điều quan trọng là hệ thống có đáp ứng được trong khi xây dựng không?
- Bạn sẵn sàng chịu đựng bao lâu của một chu kỳ xây dựng?
Trong phát triển giao diện người dùng, bạn thường không có 'chu trình xây dựng', nghĩa là xây dựng / kiểm tra / lặp lại. Bạn sẵn sàng đợi bao lâu để biết mình đã mắc một lỗi đơn giản mà bạn sẽ mất vài giây để sửa? 15 phút? 5 phút? 1 phút? 30 giây?
Trong quá trình phát triển ứng dụng bằng ngôn ngữ đã biên dịch, bạn luôn có một chu trình xây dựng và nó có thể rất quan trọng. Tôi hiểu rằng chu kỳ xây dựng Swift về cơ bản dài hơn chu kỳ xây dựng Objective-C. (Bản thân tôi không sử dụng Swift vì tôi phát triển kết hợp và mã nền tảng cơ bản là Objective-C (Java cho Android), C và C ++ - không có Swift).
Dung lượng RAM khả dụng sẽ có tác động đáng kể đến thời gian chu kỳ xây dựng.
mpe
- Ngày 3 tháng 9 năm 2010
- 17 thg 12, 2018
Đúng. RAM 8GB là đủ cho hầu hết mọi thứ.
jtara
- Ngày 23 tháng 4 năm 2009
- 17 thg 12, 2018
mpe nói: Vâng. RAM 8GB là đủ cho hầu hết mọi thứ.
MacBook Pro có sử dụng bộ nhớ hệ thống cho màn hình không?
8GB chắc chắn là không đủ - ví dụ - Mac Mini, vì một phần khá tốt (tùy thuộc vào kiểu máy) được sử dụng cho màn hình.
Hầu hết các phản hồi quan trọng được đưa ra ở đây là trên những chiếc MacBook gần đây, bộ nhớ đã bị hàn xuống. Bạn đang đưa ra quyết định cho vài năm tới.
Toutou
đến
- Ngày 6 tháng 1 năm 2015
- Prague, Cộng hòa Séc
- 17 thg 12, 2018
iMacedonian
Áp phích gốc- Ngày 10 tháng 10 năm 2015
- Brno, CZ
- 17 thg 12, 2018
jtara đã nói: Hãy xác định những gì bạn có nghĩa là 'đủ'?Cảm ơn vì phản hồi rộng rãi đó, nó đã cho tôi một góc nhìn rõ hơn về các tài nguyên cần thiết cho các kịch bản mã hóa khác nhau mà bạn đã đề cập.
Ý bạn là 'đủ để việc xây dựng không bị hỏng?'
Hay 'đủ để quá trình xây dựng hoàn thành trong một khung thời gian có thể chấp nhận được'?
Và / hoặc 'đủ để giao diện người dùng không bị lag và tôi có thể làm việc trong trình chỉnh sửa / duyệt web / đọc email trong quá trình xây dựng mà không bị chậm?
Nó phụ thuộc vào kỳ vọng của bạn và chuỗi công cụ của bạn.
Phát triển giao diện người dùng thường có một chuỗi công cụ ngắn / đơn giản. Tất cả những gì bạn thực sự cần là một trình soạn thảo tốt phù hợp với nhiệm vụ, một số máy chủ web 'đồ chơi' nhỏ, có lẽ một số công cụ để giảm thiểu Javascript / CSS (và có lẽ là một trình biên dịch Sass) cho các bản dựng sản xuất và trong quá trình phát triển, bạn thường sẽ không sử dụng điều đó.
Phát triển phụ trợ thường có thể không cần nhiều hơn phát triển giao diện người dùng. Hoặc có thể cần nhiều hơn một chút. Ví dụ, tôi sử dụng PostgreSQL làm cơ sở dữ liệu. Vì vậy, tôi có một phiên bản cục bộ để phát triển / thử nghiệm. Tôi chạy pgAdmin4, chạy trong vùng chứa Docker. Bạn có thể cần chạy một máy ảo sao chép môi trường phụ trợ của bạn. GB cộng lại.
Phát triển ứng dụng gốc thường được thực hiện với các công cụ tối thiểu. Để phát triển ứng dụng iOS cơ bản, bạn không cần gì khác ngoài Xcode. OK và trình mô phỏng iOS. Nếu bạn đang thực hiện một số kiểu phát triển kết hợp, đa nền tảng, có thể thêm các thành phần chuỗi công cụ bổ sung - và cần thiết là các SDK và công cụ xây dựng Android. Phát triển Android sử dụng một trình biên dịch khác. Thêm một trình mô phỏng khác. (Tôi sử dụng GenyMotion, vì cả hai phương pháp do Google cung cấp đều chậm như mật.) Bất kỳ trình mô phỏng Android tốt nào đều chạy trong máy ảo.
Ồ, cần kiểm tra trang web đó trên Windows? Thêm một máy ảo Windows.
Vì vậy, nhiều công cụ ngày nay chạy trong một vùng chứa hoặc một máy ảo. Điều đó làm tăng thêm yêu cầu về bộ nhớ.
Nhận được nhiều bộ nhớ nhất trong khả năng ngân sách của bạn. Tôi nghĩ, mặc dù vậy, 64GB là giới hạn thực tế hiện nay cho hầu hết các sự phát triển. Gần đây tôi đã có một chiếc iMac Pro với 64GB để phát triển. Tôi sử dụng một bộ công cụ lớn. Tôi đã kiểm tra Activity Monitor và nhận thấy rằng tôi chưa sử dụng tệp hoán đổi. Nhưng sau khi tất cả các công cụ được tải lên, tôi đang sử dụng khoảng từ 32GB đến 64GB, thường là 40-50GB. Nhưng tôi thực sự chưa tải MỌI THỨ cùng một lúc.
Những gì bạn phải tự hỏi mình là:
- Điều quan trọng là hệ thống có đáp ứng được trong khi xây dựng không?
- Bạn sẵn sàng chịu đựng bao lâu của một chu kỳ xây dựng?
Trong phát triển giao diện người dùng, bạn thường không có 'chu trình xây dựng', nghĩa là xây dựng / kiểm tra / lặp lại. Bạn sẵn sàng đợi bao lâu để biết mình đã mắc một lỗi đơn giản mà bạn sẽ mất vài giây để sửa? 15 phút? 5 phút? 1 phút? 30 giây?
Trong quá trình phát triển ứng dụng bằng ngôn ngữ đã biên dịch, bạn luôn có một chu trình xây dựng và nó có thể rất quan trọng. Tôi hiểu rằng chu kỳ xây dựng Swift về cơ bản dài hơn chu kỳ xây dựng Objective-C. (Bản thân tôi không sử dụng Swift vì tôi phát triển kết hợp và mã nền tảng cơ bản là Objective-C (Java cho Android), C và C ++ - không có Swift).
Dung lượng RAM khả dụng sẽ có tác động đáng kể đến thời gian chu kỳ xây dựng.
[doublepost=1545084766][/doublepost]
ammulder said: Bạn định giữ máy trong bao lâu? Vì không thể nâng cấp bộ nhớ nên bạn thực sự mua dung lượng bộ nhớ mình cần trong 3-5 năm nữa, chứ không phải hôm nay. (Lưu ý rằng mọi bản phát hành của các công cụ phát triển sử dụng nhiều bộ nhớ hơn bản trước.) Đặc biệt nếu bạn kết thúc sử dụng vùng chứa hoặc máy ảo (ví dụ: để chạy phiên bản cục bộ của một số back-end mà ứng dụng của bạn kết nối với), năng suất của quá ít bộ nhớ sau này không đáng để tiết kiệm chi phí bây giờ.Máy tính xách tay của tôi thường có tuổi thọ từ 4-6 năm, hoặc thậm chí hơn, vì vậy dựa trên những gì tôi đã đọc cho đến nay, có lẽ tốt nhất nên chọn phiên bản 16 GB nếu tôi muốn tối đa hóa việc sử dụng. ĐẾN
Chuột ẩn danh
- Ngày 25 tháng 8 năm 2016
- 17 thg 12, 2018
jtara đã nói: Hãy xác định những gì bạn có nghĩa là 'đủ'?
(ảnh cắt)
Vì vậy, nhiều công cụ ngày nay chạy trong một vùng chứa hoặc một máy ảo. Điều đó làm tăng thêm yêu cầu về bộ nhớ.
Nhận được nhiều bộ nhớ nhất trong khả năng ngân sách của bạn. Tôi nghĩ, mặc dù vậy, 64GB là giới hạn thực tế hiện nay cho hầu hết các sự phát triển. Gần đây tôi đã có một chiếc iMac Pro với 64GB để phát triển. Tôi sử dụng một bộ công cụ lớn. Tôi đã kiểm tra Activity Monitor và nhận thấy rằng tôi chưa sử dụng tệp hoán đổi. Nhưng một khi tất cả các công cụ được tải lên, tôi đang sử dụng khoảng từ 32GB đến 64GB, thường là 40-50GB. Nhưng tôi thực sự chưa tải MỌI THỨ cùng một lúc.
Những gì bạn phải tự hỏi mình là:
- Điều quan trọng là hệ thống có đáp ứng được trong khi xây dựng không?
- Bạn sẵn sàng chịu đựng bao lâu của một chu kỳ xây dựng?
Trong phát triển giao diện người dùng, bạn thường không có 'chu trình xây dựng', nghĩa là xây dựng / kiểm tra / lặp lại. Bạn sẵn sàng đợi bao lâu để biết mình đã mắc một lỗi đơn giản mà bạn sẽ mất vài giây để sửa? 15 phút? 5 phút? 1 phút? 30 giây?
Trong quá trình phát triển ứng dụng bằng ngôn ngữ đã biên dịch, bạn luôn có một chu trình xây dựng và nó có thể rất quan trọng. Tôi hiểu rằng chu kỳ xây dựng Swift về cơ bản dài hơn chu kỳ xây dựng Objective-C. (Bản thân tôi không sử dụng Swift vì tôi phát triển kết hợp và mã nền tảng cơ bản là Objective-C (Java cho Android), C và C ++ - không có Swift).
Dung lượng RAM khả dụng sẽ có tác động đáng kể đến thời gian chu kỳ xây dựng.
Điều này tổng hợp khá nhiều. Nếu bạn cần chạy VM, thì 8 GB là có thể thực hiện được (bạn có thể chạy thoải mái một máy ảo với RAM 8 GB). Nếu bạn có SSD, sự khác biệt về tốc độ giữa việc có 8 GB và nhiều RAM hơn sẽ không quá rõ ràng trừ khi bạn đang chạy một số lượng lớn máy ảo và / hoặc cố gắng biên dịch một cơ sở mã lớn. NS
Xây dựng
- Ngày 23 tháng 6 năm 2010
- 17 thg 12, 2018
Các ứng dụng đói bộ nhớ như XCode và Android Studio sẽ hoạt động tốt với 8GB. Vấn đề sẽ xảy ra nếu bạn cố gắng chạy Slack được kết nối với nhiều nhóm, trong khi vẫn để Chrome mở với nhiều tab hoặc có thể một hệ thống VM để chạy một số vùng chứa Docker. Đó là sự đồng thời gây ra các vấn đề.
Nếu bạn có đủ khả năng để tăng lên 16GB và bạn định giữ chiếc máy này trong một thời gian, tôi nghĩ nó hoàn toàn xứng đáng để kiểm chứng trong tương lai. Nếu chi phí tăng thêm đủ khiến bạn phải đắn đo suy nghĩ, thì hãy quên nó đi và chỉ sử dụng 8GB. Bạn sẽ hạnh phúc theo cách nào đó.
người ôn hòa
- 20 thg 10, 2018
- CÔNG DỤNG
- 17 thg 12, 2018
jtara nói: 8GB chắc chắn là không đủ - ví dụ - Mac Mini, vì một phần khá tốt (tùy thuộc vào kiểu máy) được sử dụng cho màn hình.
Như tôi đã nói trước đó, tôi chạy Xcode trên máy Mac mini 2014 của mình - nó có RAM 4GB và tôi không gặp bất kỳ vấn đề nào. Nếu tôi có thể viết mã thoải mái với 4GB, thì 8GB là đủ. NS
jtara
- Ngày 23 tháng 4 năm 2009
- 30 thg 12, 2018
kadammanali987 cho biết: (Mọi người thường giữ ứng dụng để biên dịch và chơi trò chơi cho đến thời điểm đó. Điều này làm chậm quá trình xử lý)
Hoặc bạn có thể chỉ cần tăng tốc chu trình biên dịch-liên kết-chạy đến mức chỉ cần một vài phút là có thể ngồi ngay ngắn lại một cách lành mạnh.
Một phần của điều đó là có đủ bộ nhớ để trình biên dịch hoạt động hiệu quả, với sự hoán đổi tối thiểu / không.
Điều bạn CÓ THỂ không có nghĩa là bạn NÊN. Bạn phải quyết định thời gian của bạn có giá trị như thế nào.
Thời điểm xác định cho phương trình này đối với tôi là rất nhiều năm trước đây. Một sản phẩm có tên Instant-C. Nó làm giảm chu kỳ đó từ vài phút xuống vài giây. Nó truyền cảm hứng cho tôi để giảm chu kỳ biên dịch-liên kết-chạy cho một ứng dụng mô phỏng và phân tích các biến thể (từ một mô hình, ban đầu được viết bằng Fortran) trong các cụm máy móc từ 1/2 giờ xuống dưới một phút. (OK, tôi đã lừa dối - tôi đã loại bỏ chu trình biên dịch-liên kết-chạy ... bằng cách viết trình biên dịch dành riêng cho miền và trình thông dịch bytecode đồng hành) 35 năm sau, nó vẫn là giải pháp chủ yếu cho miền đó.
Dù sao thì OP cũng đã đưa ra quyết định của mình - tôi nghĩ đó là một quyết định khôn ngoan.
BTW, nếu tôi vẫn sử dụng i7 Mini 2012 cho các bản dựng, tôi sẽ sử dụng Ramdisk. Nó làm giảm khoảng một nửa thời gian xây dựng đối với tôi trên Mini. Tôi đã thử nó trên iMac Pro mới của mình, nhưng không có tác động tương tự. Tôi e rằng tôi đã không nghĩ đến việc thử đĩa ram cho đến khi tôi có iMac Pro. MacOS không thực sự có các giải pháp RamDisk tuyệt vời. Mini có 16GB. Không có lợi nhuận cho đĩa ram trên máy có 4GB. (IMac Pro có 64GB).
vbctv
đến
- Ngày 25 tháng 9 năm 2013
- Cleveland, OH
- 2 tháng 5, 2019
jtara đã nói: MacBook Pro có sử dụng bộ nhớ hệ thống cho màn hình không?
8GB chắc chắn là không đủ - ví dụ - Mac Mini, vì một phần khá tốt (tùy thuộc vào kiểu máy) được sử dụng cho màn hình.
Hầu hết các phản hồi quan trọng được đưa ra ở đây là trên những chiếc MacBook gần đây, bộ nhớ đã bị hàn xuống. Bạn đang đưa ra quyết định cho vài năm tới.
Tôi có một chiếc mac Mini 2018 được kết nối với 2 màn hình và có RAM 8GB, tôi không bao giờ gặp bất kỳ sự cố nào và thực hiện cả công việc phát triển Android Studio & Xcode cùng với chạy MAMP Pro trong nền. Máy đo áp suất bộ nhớ không bao giờ thực sự tăng và luôn ở trạng thái xanh và ở mức thấp. Tôi đã tranh luận về việc nâng cấp lên 16GB nhưng tôi không thực sự thấy cần thiết trừ khi tôi tìm thấy một hợp đồng giết người đang giảm giá .... NS
ChromeCloud
- Ngày 21 tháng 6 năm 2009
- Nước Ý
- 2 tháng 5, 2019
Khi tôi cố gắng sử dụng MacBook Air với 4GB RAM để phát triển các ứng dụng iOS (tôi đang nói về các ứng dụng thực, không chỉ là các dự án demo nhỏ), trải nghiệm trở nên khá khó chịu rất nhanh. Chỉ cần mở Xcode và Safari với 3 hoặc 4 tab sẽ làm bão hòa hoàn toàn RAM của bạn (hãy nhớ rằng hệ thống tự nó chiếm khoảng 2GB) và việc sử dụng trình mô phỏng để gỡ lỗi ứng dụng của bạn là khá bất khả thi (máy tính chạy chậm đến mức không phản hồi).
Với 8GB, bạn sẽ ổn. Nhưng không lâu. Giả sử 8GB là mức tối thiểu để chạy thoải mái bộ phát triển iOS đầy đủ + một vài ứng dụng bên cạnh nếu bạn muốn có một trình soạn thảo văn bản ưa thích hoặc một số công cụ để tạo đồ họa vector chẳng hạn.
Vì vậy, nếu tôi phải mua một chiếc máy mới ngay bây giờ và giữ nó trong 3 năm tới hoặc hơn, tôi sẽ nhận được ít nhất 16GB RAM.
Một lời cảnh báo khác: Tôi sẽ không bao giờ lường trước được điều này vài năm trước khi tôi mua iMac của mình (có 32GB RAM và đó là máy trạm chính của tôi), nhưng có vẻ như nếu bạn muốn chạy trình mô phỏng mà không bị giật toàn bộ GUI, VRAM (hay còn gọi là bộ nhớ video) cũng đóng một vai trò quan trọng trong phương trình.
Đối với iMac retina, thẻ video 2GB sẽ không đủ để chạy mọi thứ trơn tru: cứ sau vài giây bộ đệm sẽ đầy (tôi chỉ gặp điều này khi chạy trình mô phỏng) và iMac bị đóng băng trong một phần của giây trong khi nó được làm trống và lấp đầy lại. Thật là khó chịu.
Vì vậy, khuyến nghị của tôi cho một số thứ mà bạn có thể làm việc thoải mái trong 3 năm tới là: 16GB RAM (trở lên) + 4GB VRAM (trở lên) .
mkelly
- Ngày 29 tháng 11 năm 2007
- 3 tháng 5, 2019
đám đông
- 12 thg 2, 2019
- 4 tháng 5, 2019
Trong cùng một ứng dụng, tôi có thể thấy rằng việc sử dụng RAM dưới 8 GB mà không cần hoán đổi. Để sau này, tôi đang nghĩ đến việc cập nhật RAM nhưng tôi không vội vào lúc này. NS
Filipeteixeira
- Ngày 10 tháng 4 năm 2013
- 6 tháng 5, 2019
Bài ViếT Phổ BiếN