Firebase Storage เป็นบริการจัดเก็บไฟล์บนคลาวด์ที่เป็นส่วนหนึ่งของระบบนิเวศ Firebase ของ Google ออกแบบมาสำหรับการอัปโหลดและดาวน์โหลดรูปภาพ วิดีโอ เสียง และข้อมูลไบนารีอื่นๆ จากแอปพลิเคชันมือถือและเว็บ แตกต่างจากไดรฟ์คลาวด์ทั่วไป Storage ผสานรวมกับ Firebase Authentication และ Security Rules ทำให้สามารถควบคุมการเข้าถึงแต่ละไฟล์ได้อย่างยืดหยุ่นในระดับคำขอ ตามข้อมูลจาก Google Firebase (2026) บริการนี้ประมวลผลการดำเนินการกับไฟล์มากกว่า 500 ล้านครั้งต่อวัน ให้ พื้นที่จัดเก็บที่ปรับขนาดได้ โดยไม่จำเป็นต้องจัดการโครงสร้างพื้นฐานของเซิร์ฟเวอร์
ประเด็นสำคัญ
Firebase Storage คือพื้นที่จัดเก็บวัตถุบนคลาวด์ที่สร้างบน Google Cloud Storage ซึ่งให้ SDK สำหรับ Android, iOS และแพลตฟอร์มเว็บ ไฟล์แต่ละไฟล์จะถูกจัดเก็บเป็นวัตถุใน bucket ของ Google Cloud และถูกระบุตำแหน่งด้วยเส้นทางที่คล้ายระบบไฟล์: gs://bucket-name/path/to/file.jpg ไฟล์เดียวสามารถมีขนาดสูงสุด 5 TB ทำให้สามารถจัดเก็บข้อมูลสื่อใดๆ โดยไม่ต้องบีบอัดล่วงหน้า
สถาปัตยกรรมของ Firebase Storage ใช้ แบบจำลองการอ้างอิงลิงก์ (gsutil references) แทนลำดับชั้นโฟลเดอร์แบบคลาสสิก แม้ว่า SDK จะมีอินเทอร์เฟซไดเรกทอรีเพื่อความสะดวกของนักพัฒนา ทางกายภาพแล้ว วัตถุทั้งหมดจะถูกจัดเก็บในเนมสเปซแบบเรียบของ bucket และโฟลเดอร์เสมือนถูกสร้างขึ้นโดยใช้คำนำหน้าเส้นทาง ซึ่งรับประกันประสิทธิภาพการค้นหาเชิงเส้นโดยไม่ขึ้นกับจำนวนไฟล์
ข้อได้เปรียบหลักของ Firebase Storage เมื่อเทียบกับการใช้ Google Cloud Storage โดยตรงคือการผสานรวมในตัวกับ Firebase Authentication และ Security Rules นักพัฒนาไม่จำเป็นต้องกำหนดค่าบทบาท IAM และบัญชีบริการแยกต่างหาก: กฎการเข้าถึงเขียนด้วยภาษาประกาศที่คล้ายกับ Firebase Realtime Database Rules และถูกนำไปใช้โดยอัตโนมัติในทุกคำขอ
bucket ของ Firebase Storage ถูกสร้างขึ้นโดยอัตโนมัติเมื่อคุณเปิดใช้บริการในคอนโซล Firebase เส้นทางไฟล์เป็นไปตามรูปแบบ /ชื่อโฟลเดอร์/ชื่อไฟล์และสามารถมีระดับที่ซ้อนกันได้ แนะนำให้จัดระเบียบเส้นทางตามรูปแบบ /users/{userId}/images/{imageId}.jpg เพื่อแยกข้อมูลระหว่างผู้ใช้ โครงสร้างนี้ทำให้การเขียนกฎความปลอดภัยง่ายขึ้นเนื่องจากเส้นทางมีตัวระบุของเจ้าของ
สิ่งสำคัญคือต้องเข้าใจว่า Firebase Storage ไม่ใช่ ฐานข้อมูลเชิงสัมพันธ์หรือเซิร์ฟเวอร์ไฟล์ในความหมายดั้งเดิม มันคือพื้นที่จัดเก็บวัตถุที่ปรับให้เหมาะสมสำหรับการดำเนินการอ่านและเขียนไฟล์ทั้งไฟล์ การอัปเดตไฟล์บางส่วนไม่สามารถทำได้: หากคุณอัปโหลดซ้ำไปยังเส้นทางเดียวกัน วัตถุเก่าจะถูกแทนที่ด้วยวัตถุใหม่ สำหรับการจัดเก็บข้อมูลที่มีโครงสร้างขนาดเล็ก ให้ใช้ Firebase Realtime Database หรือ Cloud Firestore
ราคาของ Firebase Storage ขึ้นอยู่กับปริมาณข้อมูลที่จัดเก็บและจำนวนการดำเนินการ แผนฟรี (Spark) รวมพื้นที่เก็บข้อมูล 5 GB, การดำเนินการเขียน 20,000 ครั้ง และการดำเนินการอ่าน 50,000 ครั้งต่อวัน แผนแบบชำระเงิน (Blaze) คิดค่าบริการตามการใช้งานจริง: $0.026 ต่อ GB ของข้อมูลที่จัดเก็บ, $0.05 ต่อ 10,000 การดำเนินการเขียน และ $0.004 ต่อ 10,000 การดำเนินการอ่าน มีค่าใช้จ่ายเพิ่มเติมสำหรับการรับส่งข้อมูลขาออก
สำหรับ แอปพลิเคชันมือถือ ส่วนใหญ่ที่มีผู้ใช้ไม่กี่พันคน ขีดจำกัดฟรีก็เพียงพอในช่วงการสร้างต้นแบบและการทดสอบ เมื่อขยายไปสู่ผู้ใช้หลายแสนคน ค่าใช้จ่าย Storage แทบจะไม่เกิน $50–$100 ต่อเดือนด้วยวิธีการอัปโหลดที่ปรับให้เหมาะสมและการแคชฝั่งไคลเอนต์
การอัปโหลดไฟล์ไปยัง Firebase Storage ดำเนินการผ่านวิธี SDK ที่เหมาะสม ซึ่งรับเส้นทางพื้นที่จัดเก็บและข้อมูลไฟล์ (อาร์เรย์ไบต์, URI, สตรีม หรือ Bitmap) SDK จัดการการเชื่อมต่อโดยอัตโนมัติ แบ่งไฟล์เป็นส่วนๆ สำหรับขนาดใหญ่ และให้การเรียกกลับสำหรับการติดตามความคืบหน้า การอัปโหลดดำเนินการโดยตรงจากอุปกรณ์ไคลเอนต์ไปยัง Google Cloud โดยไม่ผ่านเซิร์ฟเวอร์ของคุณ ซึ่งลดภาระบนโครงสร้างพื้นฐานของคุณเอง
สำหรับ Android SDK ของ Firebase Storage ใช้คลาส StorageReference และ UploadTask StorageReference ถูกสร้างขึ้นจากเส้นทางรากผ่าน Firebase.storage.reference และชี้ไปยังไฟล์เฉพาะใน bucket UploadTask ส่งคืนตัวฟังสำหรับความคืบหน้า การหยุดชั่วคราว และการเสร็จสมบูรณ์ เมื่อการเชื่อมต่อถูกขัดจังหวะ UploadTask จะเริ่มการอัปโหลดต่อโดยอัตโนมัติจากไบต์สุดท้ายที่ส่งสำเร็จ — พฤติกรรมนี้เรียกว่า การอัปโหลดต่อได้
ข้อมูลเมตาของไฟล์ (Content-Type, ฟิลด์ที่กำหนดเอง) ถูกส่งเป็นวัตถุ SettableMetadata แยกต่างหากเมื่อเริ่มการอัปโหลด การตั้ง Content-Type อย่างถูกต้องเป็นสิ่งสำคัญสำหรับการแสดงไฟล์ในเบราว์เซอร์และการแคช CDN อย่างถูกต้อง Firebase Storage รองรับชนิด MIME มาตรฐานทั้งหมด: image/jpeg, image/png, video/mp4, application/pdf และอื่นๆ
ข้อมูลเมตาของไฟล์ ประกอบด้วยฟิลด์ระบบ (Content-Type, Cache-Control, Content-Disposition) และคู่คีย์-ค่าที่กำหนดเอง (customMetadata) ฟิลด์ระบบควบคุมส่วนหัว HTTP ระหว่างการดาวน์โหลด ตัวอย่างเช่น Cache-Control: public, max-age=31536000 เปิดใช้งานการแคชการตอบสนองเป็นเวลาหนึ่งปี ซึ่งลดการดาวน์โหลดไฟล์ซ้ำๆ อย่างมีนัยสำคัญและประหยัดการรับส่งข้อมูล
ข้อมูลเมตาที่กำหนดเอง สะดวกสำหรับการส่งข้อมูลเพิ่มเติมเกี่ยวกับไฟล์โดยไม่ต้องสร้างคอลเลกชันแยกต่างหากใน Firestore ตัวอย่างเช่น ฟิลด์ uploadedBy สามารถเก็บ userId ของผู้ใช้ที่อัปโหลด ซึ่งทำให้การนำแกลเลอรีที่มีเนื้อหาที่ผู้ใช้สร้างขึ้นง่ายขึ้น ข้อมูลเมตาที่กำหนดเองไม่ได้รับการปกป้องแยกต่างหากโดย Security Rules — การเข้าถึงของพวกเขาถูกควบคุมโดยกฎเดียวกันกับไฟล์เอง
เมื่อคุณต้องการ อัปโหลดหลายไฟล์ พร้อมกัน (เช่น รูปภาพจากแกลเลอรี) ไม่แนะนำให้เรียกใช้ UploadTask อิสระแบบขนานโดยไม่มีข้อจำกัด บนอุปกรณ์มือถือ การอัปโหลดแบบขนานมากกว่า 3–5 ไฟล์จะทำให้สแต็กเครือข่ายโอเวอร์โหลดและทำให้เกิดการหมดเวลา กลยุทธ์ที่เหมาะสมที่สุดคือการใช้ขีดจำกัดพร้อมกันที่ 3 หรือการอัปโหลดตามลำดับพร้อมแถบความคืบหน้าที่ใช้ร่วมกัน
สำหรับ การประมวลผลฝั่งเซิร์ฟเวอร์ หลังการอัปโหลด (การสร้างภาพขนาดย่อ, การบีบอัด, การตรวจสอบเนื้อหา) ให้ใช้ทริกเกอร์ Firebase Cloud Functions: functions.storage.object().onFinalize() ฟังก์ชันนี้ถูกเรียกโดยอัตโนมัติหลังจากแต่ละไฟล์อัปโหลดเสร็จสมบูรณ์และสามารถบันทึกสำเนาที่ประมวลผลแล้วไปยังเส้นทางอื่น รายละเอียดเพิ่มเติมอยู่ในส่วนกรณีการใช้งานทั่วไป
Firebase Storage รองรับสองวิธีในการดาวน์โหลด: การดาวน์โหลดโดยตรงผ่าน SDK (รับอาร์เรย์ไบต์หรือไฟล์ในเครื่อง) และการรับ URL ดาวน์โหลดโดยตรงสำหรับการเข้าถึงผ่าน HTTP URL โดยตรงสามารถใช้เพื่อแสดงรูปภาพใน ImageView, ใน WebView หรือเพื่อให้ลิงก์แก่ผู้ใช้ URL ดาวน์โหลดถูกสร้างขึ้นพร้อมกับโทเค็นความปลอดภัยที่สามารถเพิกถอนได้ในคอนโซล Firebase
วิธี storageReference.downloadUrl ส่งคืน URL ในรูปแบบ https://firebasestorage.googleapis.com/v0/b/{bucket}/o/{path}?alt=media&token={token} โทเค็นความปลอดภัยถูกรวมอยู่ใน URL โดยอัตโนมัติระหว่างการสร้าง ดังนั้นลิงก์จึงสามารถแชร์กับบุคคลที่สาม (เช่น ในแอปส่งข้อความ) โดยไม่มีความเสี่ยงจากการเข้าถึงโดยไม่ได้รับอนุญาต อย่างไรก็ตาม หาก โทเค็นถูกบุกรุก สามารถเพิกถอนได้ผ่านคอนโซล Firebase ในส่วน Storage — หลังจากนั้น ลิงก์ทั้งหมดที่มีโทเค็นนี้จะหยุดทำงาน
สำหรับ การแคชไฟล์ที่ดาวน์โหลด บนไคลเอนต์ ให้ใช้พื้นที่จัดเก็บในเครื่องกับกลไก ETag หรือแฮช MD5 Firebase Storage ส่งคืนส่วนหัว HTTP ETag เมื่อร้องขอไฟล์ ซึ่งสามารถเปรียบเทียบกับค่าที่เก็บไว้ในเครื่องเพื่อหลีกเลี่ยงการดาวน์โหลดไฟล์ที่ไม่เปลี่ยนแปลงซ้ำ ซึ่งมีประโยชน์โดยเฉพาะอย่างยิ่งสำหรับเนื้อหาสื่อ: รูปโปรไฟล์ รูปปก ตัวอย่าง — ไฟล์ที่อัปเดตน้อยครั้งแต่ถูกขอใช้บ่อย
URL ดาวน์โหลด ที่มีโทเค็นเป็นวิธีหลักในการให้การเข้าถึงไฟล์แก่ผู้ใช้ที่ไม่ได้รับการรับรองความถูกต้อง (เช่น การแสดงรูปภาพในฟีดข่าว) โทเค็นถูกสร้างขึ้นครั้งเดียวและไม่เปลี่ยนแปลงจนกว่าจะถูกเพิกถอน ดังนั้น URL จึงสามารถเก็บไว้ในฐานข้อมูล (เช่น ถัดจากฟิลด์ avatarUrl ใน Firestore) เมื่อเปลี่ยนรูปโปรไฟล์ ไฟล์เก่าจะถูกลบ และ URL ใหม่จะถูกสร้างและบันทึก
สิ่งสำคัญที่ต้องจำ: การมี URL ดาวน์โหลดไม่ได้แทนที่ Security Rules หากกฎปฏิเสธการอ่านไฟล์ วิธี downloadUrl จะส่งคืนข้อผิดพลาดการปฏิเสธการอนุญาต ซึ่งหมายความว่าแม้จะรู้เส้นทางไฟล์ที่ถูกต้อง ไคลเอนต์ที่ไม่ได้รับการรับรองความถูกต้องก็ไม่สามารถรับลิงก์ได้ เมื่อได้รับแล้ว URL จะให้การเข้าถึง HTTP โดยข้าม Security Rules — ดังนั้นโทเค็นจึงเป็นเพียงการป้องกันเดียวสำหรับลิงก์ดาวน์โหลด
HTTP ETag คือตัวระบุเวอร์ชันไฟล์ที่เปลี่ยนแปลงทุกครั้งที่เนื้อหาถูกแก้ไข Firebase Storage ส่งคืน ETag โดยอัตโนมัติในการตอบสนอง GET แอปพลิเคชันไคลเอนต์สามารถเก็บ ETag ไว้ในแคชในเครื่องและส่งส่วนหัว If-None-Match: {etag} ในคำขอครั้งต่อไป หากไฟล์ไม่เปลี่ยนแปลง เซิร์ฟเวอร์จะส่งคืนสถานะ 304 Not Modified โดยไม่ส่งข้อมูล
เพื่อใช้ การแคชอัจฉริยะ ในแอปพลิเคชันมือถือ ให้ใช้ระบบไฟล์ในเครื่องและฐานข้อมูลร่วมกัน (เช่น Room สำหรับเก็บคู่เส้นทาง-ETag) เมื่อโหลดไฟล์ ให้ตรวจสอบ ETag จากฐานข้อมูล: หากตรงกับเซิร์ฟเวอร์ ให้ใช้สำเนาในเครื่อง วิธีการนี้ช่วยลดการรับส่งข้อมูลลง 60–80% สำหรับไฟล์สื่อแบบคงที่และเพิ่มความเร็วในการโหลดหน้าจอที่มีแกลเลอรี
Security Rules คือภาษาประกาศสำหรับการควบคุมการเข้าถึงไฟล์ใน Firebase Storage ที่ดำเนินการฝั่งเซิร์ฟเวอร์ Firebase แต่ละกฎผูกกับเส้นทาง bucket และกำหนดเงื่อนไขที่อนุญาตให้ดำเนินการอ่านหรือเขียน กฎจะถูกตรวจสอบก่อนทุกคำขอและไม่สามารถหลีกเลี่ยงได้โดยโค้ดไคลเอนต์ นี่คือแนวป้องกัน唯一的สำหรับข้อมูลต่อการเข้าถึงโดยไม่ได้รับอนุญาต
กฎพื้นฐานคือ การเข้าถึงสำหรับผู้ใช้ที่ได้รับการรับรองความถูกต้องเท่านั้น: allow read, write: if request.auth != null. กฎนี้รับประกันว่าเฉพาะผู้ใช้ที่เข้าสู่ระบบแล้วเท่านั้นที่สามารถอ่านและเขียนไฟล์ได้ สำหรับการกำหนดค่าที่ละเอียดยิ่งขึ้น ตัวแปร request.auth.uid ถูกใช้ ซึ่งมีตัวระบุของผู้ใช้ปัจจุบัน โดยการเปรียบเทียบ uid กับส่วนของเส้นทางไฟล์ คุณสามารถสร้างพื้นที่จัดเก็บที่แยกออกจากกันสำหรับแต่ละผู้ใช้
สำคัญ: Security Rules ไม่ใช่ กลไกการตรวจสอบเนื้อหา หากคุณต้องการตรวจสอบชนิดไฟล์ ขนาด หรือการมีอยู่ของโค้ดที่เป็นอันตราย ให้ใช้กฎ request.resource ซึ่งมีข้อมูลเมตาของไฟล์ที่อัปโหลด คุณสมบัติที่มีให้คือ request.resource.size (ขนาดไฟล์), request.resource.contentType (ชนิด MIME) และ request.resource.md5Hash (ผลรวมตรวจสอบ) อย่างไรก็ตาม การตรวจสอบเนื้อหาอย่างสมบูรณ์จะดำเนินการฝั่งเซิร์ฟเวอร์ผ่าน Cloud Functions
| สถานการณ์ | กฎ Security Rules |
|---|---|
| เฉพาะผู้ที่รับรองความถูกต้อง | allow read, write: if request.auth != null |
| เฉพาะเจ้าของ | allow write: if request.auth.uid == userId |
| อ่านสาธารณะ | allow read: if true; allow write: if request.auth != null |
| จำกัดขนาด | allow write: if request.resource.size < 5 * 1024 * 1024 |
| จำกัดชนิด | allow write: if request.resource.contentType.startsWith('image/') |
การกำหนดค่าทั่วไป สำหรับแอปพลิเคชันที่มีรูปโปรไฟล์ผู้ใช้และแกลเลอรีมีดังนี้ ผู้ใช้สามารถเขียนได้เฉพาะในไดเรกทอรีของตนเอง /users/{userId}/ แต่สามารถอ่านไฟล์ใดๆ ในไดเรกทอรีนี้ได้ (แกลเลอรีสาธารณะ) ขนาดไฟล์จำกัดที่ 5 MB และชนิดจำกัดเฉพาะรูปภาพเท่านั้น การรวมกฎนี้ครอบคลุม 80% ของกรณีการใช้ Firebase Storage ในแอปพลิเคชันสังคมและ UGC
เคล็ดลับความปลอดภัย: อย่าใช้กฎ allow read, write: if true สำหรับทั้ง bucket สิ่งนี้เปิดการเข้าถึงการเขียนสำหรับใครก็ตามที่รู้ projectId ของคุณ ในปี 2025 การโจมตีบน bucket Firebase ที่ไม่มีการป้องกันเพิ่มขึ้น โดยผู้โจมตีใช้การเข้าถึงแบบเปิดเพื่อจัดเก็บเนื้อหาที่ผิดกฎหมาย เริ่มต้นด้วยสิทธิ์ขั้นต่ำที่จำเป็นเสมอและขยายเมื่อจำเป็นอย่างชัดแจ้งเท่านั้น
ทริกเกอร์ Cloud Functions functions.storage.object().onFinalize() ช่วยให้ดำเนินการตรวจสอบเนื้อหาหลังการอัปโหลดได้ หากไฟล์ไม่ผ่านการตรวจสอบ (เช่น มีไวรัสหรือละเมิดกฎของแพลตฟอร์ม) ฟังก์ชันสามารถลบไฟล์และแจ้งให้ผู้ใช้ทราบ นี่เป็นวิธีเดียวในการตรวจสอบเนื้อหาจริง เนื่องจาก Security Rules เห็นเฉพาะข้อมูลเมตา (ขนาดและชนิด MIME) ไม่ใช่ข้อมูลไบนารี
ตัวอย่างการตรวจสอบ: ฟังก์ชัน Node.js ดาวน์โหลดไฟล์ที่อัปโหลดไปยังไดเรกทอรีชั่วคราว เรียกใช้ผ่านตัวตรวจจับไวรัส (เช่น ClamAV) และหากพบภัยคุกคาม — ลบไฟล์และบันทึกเหตุการณ์ใน Firebase Crashlytics เวลาดำเนินการฟังก์ชันจำกัดที่ 540 วินาที ซึ่งเพียงพอสำหรับตรวจสอบไฟล์ขนาดสูงสุด 50 MB
มาดู ตัวอย่างเชิงปฏิบัติ ของการผสานรวม Firebase Storage ในแอปพลิเคชัน Android โดยใช้ Kotlin โค้ดใช้คลาส SDK Firebase มาตรฐานและสาธิตการอัปโหลดรูปภาพจากแกลเลอรีอุปกรณ์ การดาวน์โหลดไฟล์พร้อมติดตามความคืบหน้า และการรับ URL ดาวน์โหลด ตัวอย่างทั้งหมดรวมถึงการจัดการข้อผิดพลาดและการระงับงานเมื่อสูญเสียการเชื่อมต่อ
ก่อนใช้โค้ด ตรวจสอบให้แน่ใจว่าไฟล์ build.gradle มีการพึ่งพา implementation(platform("com.google.firebase:firebase-bom:33.0.0")) และ implementation("com.google.firebase:firebase-storage") Firebase BOM เลือกเวอร์ชันที่เข้ากันได้ของ SDK ทั้งหมดโดยอัตโนมัติ กำจัดความขัดแย้งของเวอร์ชัน
ตัวอย่างแรกสาธิต การอัปโหลดไฟล์ ที่ผู้ใช้เลือกผ่าน Intent ACTION_GET_CONTENT URI ของไฟล์ที่ได้รับจะถูกส่งไปยัง SDK Firebase Storage ซึ่งอ่านข้อมูลจาก URI นี้ วิธี putFile รับ URI และส่งคืน UploadTask — วัตถุที่คุณสามารถติดตามความคืบหน้า หยุดชั่วคราว และเริ่มการอัปโหลดต่อได้
val storageRef = Firebase.storage.reference
val imageRef = storageRef.child(
"users/${auth.uid}/profile.jpg"
)
val metadata = SettableMetadata().apply {
contentType = "image/jpeg"
customMetadata = mapOf(
"uploadedBy" to auth.uid!!
)
}
imageRef.putFile(imageUri, metadata)
.addOnSuccessListener {
Log.d("Storage", "อัปโหลดไฟล์แล้ว")
}
.addOnFailureListener { e ->
Log.e("Storage", "ข้อผิดพลาด: ${e.message}")
}
ในตัวอย่างข้างต้น ตัวแปร storageRef คือการอ้างอิงรากไปยัง bucket ของโปรเจกต์ วิธี child รับสตริงเส้นทางและส่งคืน StorageReference ที่ชี้ไปยังไฟล์เฉพาะ หากมีไฟล์อยู่แล้วในเส้นทางที่ระบุ ไฟล์นั้นจะถูกเขียนทับ ข้อมูลเมตา contentType และ customMetadata ถูกส่งผ่านวัตถุ SettableMetadata ซึ่งแนบไปกับคำขอ putFile
ตัวอย่างที่สองสาธิต การดาวน์โหลดไฟล์ โดยรับอาร์เรย์ไบต์สำหรับแสดงใน ImageView วิธี getBytes(maxSize) โหลดไฟล์ทั้งหมดลงในหน่วยความจำ สำหรับไฟล์ที่ใหญ่กว่า 10 MB ให้ใช้ getFile(localUri) — มันบันทึกเนื้อหาลงในไฟล์ในเครื่องโดยตรงโดยไม่เก็บใน RAM ป้องกัน OutOfMemoryError
val islandRef = storageRef.child("images/island.jpg")
val ONE_MEGABYTE: Long = 1024 * 1024
islandRef.getBytes(ONE_MEGABYTE)
.addOnSuccessListener { bytes ->
imageView.setImageBitmap(
BitmapFactory.decodeByteArray(
bytes, 0, bytes.size
)
)
}
.addOnFailureListener { e ->
Log.e("Storage", "อัปโหลดไม่สำเร็จ: ${e.message}")
}
เพื่อ รับ URL ดาวน์โหลด (เช่น เพื่อบันทึกลิงก์ใน Firestore) ให้ใช้วิธี downloadUrl:
islandRef.downloadUrl.addOnSuccessListener { uri ->
Log.d("Storage", "URL ดาวน์โหลด: $uri")
// บันทึก uri.toString() ใน Firestore
}
เคล็ดลับ: URL ดาวน์โหลดถูกสร้างครั้งเดียวและคงที่จนกว่าจะถูกเพิกถอน บันทึกในฐานข้อมูลในการอัปโหลดครั้งแรกแทนที่จะขอทุกครั้งที่แสดงไฟล์ ซึ่งลดจำนวนคำขอไปยัง Firebase Storage และปรับปรุงประสิทธิภาพ UI
Firebase Storage ถูกใช้ในแอปพลิเคชันมือถือเพื่อจัดเก็บไฟล์ผู้ใช้และระบบใดๆ สถานการณ์ที่พบบ่อยที่สุดรวมถึงรูปโปรไฟล์และรูปประจำตัว รูปภาพในฟีดเนื้อหา ไฟล์วิดีโอและเสียง เอกสาร (PDF, DOCX) สำหรับการแชร์ระหว่างผู้ใช้ และการสำรองข้อมูลขนาดเล็ก ในทุกกรณีเหล่านี้ Storage ทำหน้าที่เป็นพื้นที่จัดเก็บไฟล์เฉพาะร่วมกับ Firestore สำหรับจัดเก็บข้อมูลเมตาและลิงก์
แอปพลิเคชันสังคม เป็นกรณีการใช้งานที่พบบ่อยที่สุด ผู้ใช้แต่ละคนอัปโหลดรูปโปรไฟล์ รูปโพสต์ และไฟล์สื่อ โครงสร้างเส้นทาง /users/{uid}/posts/{postId}/image.jpg แยกข้อมูลและทำให้ Security Rules ง่ายขึ้น เมื่อผู้ใช้ถูกลบ Cloud Function สามารถเดินทางผ่านไดเรกทอรีทั้งหมดของผู้ใช้และทำความสะอาดพื้นที่จัดเก็บ ตามบล็อก Firebase (2025) รูปแบบนี้ใช้ใน 70% ของโปรเจกต์ Firebase ที่ใช้งานจริง
แอปพลิเคชันอีคอมเมิร์ซ ใช้ Firebase Storage สำหรับจัดเก็บรูปภาพสินค้า แคตตาล็อก และไฟล์ PDF พร้อมคำแนะนำ ในกรณีนี้ การเข้าถึงไฟล์มักจะเป็นสาธารณะ (อ่านโดยไม่ต้องรับรองความถูกต้อง) ในขณะที่การเขียนถูกจำกัดให้เฉพาะผู้ดูแลระบบผ่าน Cloud Functions พร้อมการตรวจสอบสิทธิ์ URL ดาวน์โหลดสินค้าถูกเก็บใน Firestore ข้างข้อมูลสินค้าอื่นๆ ทำให้สามารถแสดงรูปภาพได้โดยไม่ต้องขอข้อมูลเพิ่มเติมไปยัง Storage
แอปส่งข้อความและแชท จัดเก็บรูปภาพและข้อความเสียงที่ส่งในการสนทนาใน Firebase Storage เส้นทางถูกจัดโครงสร้างเป็น /chats/{chatId}/messages/{messageId}.jpg การเข้าถึงการอ่านจำกัดเฉพาะผู้เข้าร่วมแชท ซึ่งตรวจสอบผ่าน Security Rules โดยใช้ข้อมูล Firestore นี่เป็นหนึ่งในไม่กี่สถานการณ์ที่กฎอ่านข้อมูลจากบริการ Firebase อื่น: allow read: if firestore.exists(/databases/(default)/documents/chats/{chatId}/members/{request.auth.uid})
คำถามที่พบบ่อย
Firebase Storage คือชั้นเหนือ Google Cloud Storage ที่มีการผสานรวม Firebase Authentication และ Security Rules นักพัฒนาไม่จำเป็นต้องกำหนดค่าบทบาท IAM และบัญชีบริการ Google Cloud Storage ให้ความสามารถที่กว้างขึ้น (การแจ้งเตือน Pub/Sub, การจัดการวงจรชีวิตวัตถุ) แต่ต้องการการจัดการการเข้าถึงด้วยตนเองผ่าน GCP IAM
การจำกัดขนาดถูกกำหนดใน Security Rules ผ่าน request.resource.size ตัวอย่าง: allow write: if request.resource.size <= 5 * 1024 * 1024 จำกัดไฟล์ที่ 5 MB นอกจากนี้ คุณสามารถตรวจสอบฝั่งไคลเอนต์ก่อนส่งเพื่อไม่ให้สิ้นเปลืองการรับส่งข้อมูลของผู้ใช้กับไฟล์ที่ไม่ถูกต้องอย่างชัดเจน
ได้ การลบทำได้โดยใช้วิธี delete() ของวัตถุ StorageReference: storageRef.child("path").delete() การดำเนินการลบไม่สามารถย้อนกลับได้และลบไฟล์ออกจาก bucket ทันที ไฟล์สามารถถูกลบได้ก็ต่อเมื่อ Security Rules อนุญาตการเขียนสำหรับเส้นทางที่กำหนด หลังจากการลบ URL ดาวน์โหลดจะหยุดทำงาน
ใน Security Rules อนุญาตการอ่านสำหรับทุกคน (หรือผู้ใช้ที่รับรองความถูกต้อง) และปฏิเสธการเขียน: allow read: if request.auth != null; allow write: if false การเขียนในโหมดนี้ทำได้ผ่านบัญชีบริการ Firebase Admin SDK เท่านั้น — ตัวอย่างเช่น จาก Cloud Functions ที่มีสิทธิ์การดูแลระบบ นี่เป็นรูปแบบมาตรฐานสำหรับแคตตาล็อกสินค้าและเนื้อหาสาธารณะ
UploadTask ใช้โปรโตคอลการอัปโหลดต่อได้บนพื้นฐาน HTTP PUT พร้อมการแบ่งส่วน เมื่อการเชื่อมต่อถูกขัดจังหวะ การอัปโหลดจะเริ่มต่อจากไบต์ที่ได้รับการยืนยันล่าสุดแทนที่จะเริ่มใหม่ ไม่จำเป็นต้องกำหนดค่าเพิ่มเติมสำหรับพฤติกรรมนี้ — SDK ทำโดยอัตโนมัติสำหรับไฟล์ที่ใหญ่กว่า 1 MB
สรุป
เราจะพัฒนาแอปพลิเคชันบนมือถือแบบครบวงจร
IT Sectr สร้างแอปพลิเคชัน iOS และ Android สำหรับสตาร์ทอัพและธุรกิจตั้งแต่ปี 2017 เราจะให้คำแนะนำและเสนอวิธีแก้ปัญหาที่ดีที่สุดแก่คุณ
อ่านเพิ่มเติม