Mengapa perangkat pengembangan memberi Anda lebih banyak sumber daya daripada perangkat biasa?

9

Saya telah membuat aplikasi yang berfungsi pada iPod Touch generasi ke-4 dan iPod touch generasi ke-5 perusahaan saya.

Kami akan merilis, ketika kami menemukan kerusakan yang terjadi setelah perangkat non-pengembang menjalankan aplikasi *.

Gagasan muncul bahwa perangkat yang terdaftar sebagai 'perangkat pengembang' memberi sumber daya lebih banyak untuk digunakan aplikasi Anda. Ini sepertinya tidak tepat bagi saya, karena saya tidak dapat memikirkan alasan apa pun yang akan ada - saya merasa sepertinya ini lebih merupakan masalah dengan pembuatan profil bangunan atau penyediaan.

Namun, itu memicu diskusi. Mengapa perangkat seperti kit pengembangan konsol game, perangkat yang memiliki kemampuan lebih dari platform target, ada di tempat pertama? Tentu saja itu baik untuk stress test suatu program, tetapi bukankah representasi yang lebih akurat dari platform target lebih masuk akal?

TL; DR - Mengapa kit pengembangan memiliki lebih banyak sumber daya daripada platform target?

* Dengan perangkat non-pengembang menjadi apa pun> gen ke-3. Perangkat iOS yang mengunduh aplikasi dari server kami, bukan langsung dari komputer dengan aplikasi & xcode diinstal.

_{Perhatikan ada pertanyaan lain yang berbunyi serupa, tetapi sebenarnya berbeda, karena pertanyaan lain itu menanyakan tentang simulator, dan saya mengerti bahwa ada perbedaan besar antara menggunakan simulator dan perangkat yang sebenarnya.}

ios development

— Katamaritaco
sumber

7

@gnat - Posting ini bukan duplikat dari Mengapa perlu untuk menguji aplikasi iPhone saya . Saya mengerti bahwa ada perbedaan besar antara menggunakan simulator dan perangkat yang sebenarnya ...

— Katamaritaco

8

Lingkungan pengembangan (untuk apa pun - baik itu aplikasi java yang berdiri sendiri, atau lingkungan mobile, atau perangkat yang disematkan) biasanya memiliki kemampuan untuk melakukan debugging jarak jauh, peningkatan logging dan jenis introspeksi lingkungan lainnya (yang biasanya tidak diinginkan untuk menambahkan semua pengait untuk penganalisis logika pada perangkat embeded produksi).

Hal-hal tambahan ini membutuhkan sumber daya tambahan. Membuka debugger jarak jauh terhadap vm atau lingkungan jarak jauh lainnya membutuhkan beberapa sumber daya di ujung yang lain. Di ranah ponsel yang sangat terbatas, ada kemungkinan bahwa sumber daya tambahan ini akan melampaui batas yang diberikan untuk aplikasi standar. Dengan demikian, lebih banyak sumber daya diberikan ke lingkungan pengembangan sehingga tidak mencapai batas sumber daya ketika mulai melakukan tambahan logging atau debugging.

Ini semakin jauh ke titik bahwa Anda selalu perlu menguji sesuatu di cermin lingkungan produksi. Memercayai bahwa itu bekerja pada mesin pengembang dengan semua tweak mereka dan variabel yang berbeda tidak cukup untuk memverifikasi itu berfungsi dengan benar dalam produksi.

1

Ya, QA selalu perlu diuji di lingkungan pengguna akhir dan bukan lingkungan pengembangan.

— 17 dari 26

Beberapa tahun yang lalu, saya terlibat dengan proyek yang harus mengembangkan dua papan CPU yang sama sekali berbeda. Insinyur perangkat keras yang mengerjakan papan saya sangat terlibat dengan meletakkan sekelompok konektor uji di papannya, mengambil asuransi untuk tahap debug, untuk memastikan kami bisa menyelidiki apa pun. Dia mengambil banyak statis karena menyia-nyiakan real estat dan uang. Orang lain tidak menyia-nyiakan uang dan real estat seperti itu. Lucunya: Kami tidak pernah membutuhkan konektor di papan kami. Mengintegrasikan dewan lainnya dilaporkan merupakan mimpi buruk absolut, karena TIDAK ADA YANG DAPAT DILAKUKAN. Pikirkan "asuransi".

— John R. Strohm

@ JohnR.Strohm Untuk pengembangan, menyelidik itu baik. Semua yang saya coba katakan bahwa jika dirancang untuk memiliki papan produksi yang berbeda dari papan pengembangan, maka orang juga perlu menguji lagi dengan papan produksi setelah berhasil dengan papan pengembangan (dan memeriksa jika perlu).

Ini masuk akal untuk 'dev kit' yang khas. Karena penasaran, dalam kasus iOS, iDevice dapat digunakan sebagai 'perangkat pengembang'. Bagaimana bisa ada perbedaan dengan dua buah perangkat keras yang sama?

— Katamaritaco

1

@ Kasamaraco hanya karena itu adalah perangkat fisik yang sama tidak berarti bahwa aplikasi memiliki izin yang sama di dalam iOS. Kemampuan untuk melakukan hal-hal seperti debugging jarak jauh dapat mengubah sumber daya apa yang memiliki akses aplikasi.

5

Hal ini memungkinkan Anda untuk membuat bukti konsep sumber daya yang serakah yang nantinya dapat Anda optimalkan.

Tidak masuk akal dalam men-crash aplikasi karena 5 byte melebihi batas memori (yang dapat diselesaikan dengan mengatur pengoptimal untuk menghemat ruang dalam rilis tetapi Anda menjalankan versi debug),

memiliki peringatan muncul di log ketika Anda melampaui batas konsumen saat pengujian akan menyenangkan di sini.

— aneh ratchet
sumber

1

Ini sebagian masalah "kepercayaan." Pengembang diasumsikan tahu apa yang mereka lakukan, dan karenanya diberi akses tanpa batas ke perangkat dan semua sumber dayanya. Ini bisa menjadi bantuan besar bagi perusahaan kecil dan tim pengembangan, di mana sumber daya yang tidak digunakan adalah sumber daya yang terbuang.

Dalam lingkungan perusahaan yang lebih besar, atau terutama masyarakat umum, akses semacam ini menjadi tanggung jawab, karena masalah keamanan dan kebutuhan untuk bermain baik dengan aplikasi lain yang juga membutuhkan sumber daya.

Ini sebenarnya bukan ide baru. Saya memiliki dua mesin di tempat kerja. Pada mesin pengembang saya, saya memiliki akses administratif, tetapi diisolasi dari internet. Mesin saya yang lain, yang saya gunakan untuk email, Office dan akses Internet, bahkan tidak memberi saya kemampuan untuk menginstal program.

Inilah sebabnya mengapa Anda harus menguji aplikasi Anda pada perangkat non-pengembang sebelum Anda menyebarkannya, untuk memastikan bahwa itu berperilaku baik. :)

— Robert Harvey
sumber

0

Dengan iOS, perangkat yang diaktifkan untuk Pengembangan memungkinkan Anda menjalankan Debug build secara langsung, yang mungkin mengandung set bug penyusun yang berbeda dari build Release, serta menjalankan aplikasi di bawah debug debug, yang secara halus dapat mengubah timing thread dan penggunaan memori, yang juga dapat menampilkan / menyembunyikan berbagai bug memori threading dan bocor.

Perangkat pengembangan tidak akan banyak berguna tanpa kemampuan debug, dan perangkat pengguna dengan kemampuan debug akan menghadirkan masalah keamanan data aplikasi dan aplikasi yang lebih parah.

— hotpaw2
sumber